Recuperar datos SQL: cómo restaurar bases de datos y archivos borrados paso a paso

1. Situaciones típicas en las que necesitas SQL Data Recovery

Has eliminado una tabla o registros por error --- Una sentencia DELETE, una UPDATE incorrecta o la eliminación de una tabla pueden hacer desaparecer datos que necesitas.

Los archivos MDF, NDF o LDF se han eliminado o movido --- Si los archivos de base de datos de SQL Server desaparecen de su ubicación original, el servicio puede no cargar la base de datos correctamente.

Se ha perdido la copia de seguridad BAK o el volcado SQL --- Si el archivo de copia de seguridad necesario para la recuperación se elimina de un disco externo o del disco local, primero tendrás que recuperar ese mismo archivo.

El archivo de base de datos está dañado o hay errores de almacenamiento --- Un apagado repentino, un fallo del disco o daños en el sistema de archivos pueden dejar la base de datos en estado SUSPECT o impedir que se abra.

Los datos han desaparecido tras un ransomware, un formateo o un problema de particiones --- En estos casos, puede que antes que la recuperación lógica dentro del motor de base de datos haya que recuperar los archivos originales del dispositivo de almacenamiento.

2. Cuatro pasos obligatorios antes de recuperar

• Reduce al mínimo las nuevas operaciones de escritura en la base de datos donde estaban los datos eliminados. Si se sobrescriben las zonas del registro o del disco, la probabilidad de recuperación puede disminuir.

• Conserva el estado actual en una copia aparte. Si los archivos MDF/LDF están dañados, es más seguro trabajar sobre una copia que modificar el original.

• Comprueba la ubicación de las copias de seguridad y la política de retención. Busca primero si existe una copia completa reciente, una copia diferencial, un registro de transacciones o un archivo de volcado.

• Si los archivos se han eliminado, no instales programas nuevos ni guardes archivos en esa unidad. Si es posible, ejecuta la herramienta de recuperación desde otra unidad.

3. Método 1: restaurar la base de datos SQL desde la copia de seguridad más reciente

El método más seguro y prioritario es restaurar desde una copia de seguridad verificada. Si la copia está en buen estado, el resultado es más predecible que modificar directamente la base de datos dañada, y el procedimiento para volver al entorno de producción resulta más claro.

En SQL Server

• Abre SQL Server Management Studio (SSMS) y conéctate al servidor de destino.

• Haz clic con el botón derecho en Databases y selecciona Restore Database.

• En Device, indica el archivo de copia de seguridad .bak y comprueba la base de datos de destino y la ruta.

• Si es necesario, revisa con cuidado en Options si se va a sobrescribir la base de datos existente y después ejecuta la restauración.

• Tras la restauración, verifica que la conexión de la aplicación y los datos de las tablas principales sean correctos.

En MySQL / PostgreSQL

MySQL permite importar un volcado SQL generado con mysqldump mediante el cliente mysql, y PostgreSQL permite restaurar una copia creada con pg_dump usando pg_restore o psql. Lo importante es utilizar la herramienta adecuada al formato de la copia de seguridad.

4. Método 2: volver atrás con el registro de transacciones o Point-in-Time Recovery

Si los datos se eliminaron por error en un momento concreto posterior a la copia de seguridad, puedes plantearte restaurar al «instante inmediatamente anterior al borrado». Este enfoque resulta útil para recuperar parte de los datos tras un error ocurrido en producción, pero exige que el modo de recuperación del motor de base de datos y la retención de registros estén configurados de antemano.

SQL Server: Si en el modelo de recuperación Full o Bulk-Logged se mantiene la cadena de copias completas o diferenciales y de copias del registro de transacciones, puedes valorar una recuperación a un punto concreto mediante la opción STOPAT.

MySQL: Si el Binary Log está activado y los registros se conservan, puedes restaurar la copia completa y después reaplicar los cambios hasta un punto concreto con mysqlbinlog.

PostgreSQL: Si dispones de archivado WAL y de una copia base, puedes recuperar hasta el punto deseado mediante PITR (Point-in-Time Recovery).

Atención

• En la recuperación a un punto concreto, es más seguro restaurar primero en una instancia de prueba en lugar de sobrescribir directamente la base de datos en producción, y comprobar allí los datos necesarios.
• Si la cadena de copias del registro se ha roto o los registros necesarios ya se han eliminado, puede que no sea posible volver al punto deseado.

5. Método 3: comprobar y reparar una base de datos de SQL Server dañada

Si la base de datos está en estado SUSPECT o aparecen errores de lectura, conserva primero los archivos originales y una copia de seguridad, y después comprueba la integridad con DBCC CHECKDB. Ten en cuenta que REPAIR_ALLOW_DATA_LOSS puede eliminar realmente algunas páginas o registros, así que debe usarse solo como último recurso.

• Si es posible, copia los archivos MDF/LDF dañados y la copia de seguridad más reciente a otra ubicación.

• Ejecuta DBCC CHECKDB para identificar el alcance de los errores.

• Si puedes restaurar desde una copia de seguridad, da prioridad a la restauración.

• Solo si no hay copia de seguridad y no existe otra alternativa, usa con prudencia las opciones de reparación basándote en la documentación de Microsoft y en la revisión de un DBA.

• Después de la reparación, verifica siempre la integridad de los datos y las tablas principales.

6. Método 4: recuperar archivos MDF, LDF, BAK y SQL eliminados con 4DDiG Data Recovery

Si lo que se ha eliminado no son los registros internos de la base de datos, sino los propios archivos MDF, NDF, LDF, BAK o el volcado SQL, es difícil resolverlo solo con comandos de base de datos. En ese caso hay que recuperar primero los archivos originales del dispositivo de almacenamiento y después seguir el procedimiento de restauración de SQL Server, MySQL o PostgreSQL.

4DDiG Data Recovery sirve para escanear el dispositivo de almacenamiento y recuperar archivos que han desaparecido por eliminación, formateo o problemas de particiones. No es una herramienta que «repare» directamente la estructura de la base de datos, sino que encaja en la fase de recuperar los archivos de base de datos o de copia de seguridad necesarios.

Pasos para recuperar archivos SQL con 4DDiG

• Ejecuta 4DDiG Data Recovery y selecciona la unidad o partición donde se guardaban originalmente los archivos SQL eliminados.

  

• Inicia el análisis y busca los archivos .mdf, .ndf, .ldf, .bak y .sql por nombre, ruta o extensión.

  

• Revisa los archivos que necesitas y ejecuta la recuperación. Conviene guardar los archivos recuperados en un dispositivo distinto de la unidad original.

  

• No sobrescribas directamente el entorno de producción con los archivos recuperados: comprueba primero su integridad en un entorno de prueba aparte.

• Si los archivos están en buen estado, reconstruye la base de datos con el procedimiento Restore, Attach, Import o restauración del volcado propio de ese motor de base de datos.

Cuándo resulta especialmente útil este método

• Has eliminado por error un archivo de copia de seguridad .bak o .sql

• Los archivos .mdf/.ldf de SQL Server han desaparecido tras un formateo o un error de partición

• Has perdido una copia de seguridad de base de datos guardada en un SSD externo, HDD, memoria USB

• Necesitas conseguir los archivos originales antes de restaurar la base de datos

7. Método 5: volver a adjuntar o importar los archivos SQL recuperados de forma segura

Que la recuperación de archivos haya terminado no significa que la base de datos esté ya en buen estado. Hay que comprobar que los archivos recuperados están completos y después adjuntarlos o restaurarlos del modo que exige el motor de base de datos.

SQL Server .BAK: Restaura primero con la función Restore Database de SSMS usando un nombre de base de datos distinto.

SQL Server .MDF/.LDF: Si los archivos se separaron en un estado coherente o se copiaron correctamente, puedes valorar Attach. Si están dañados, da prioridad a restaurar desde la copia de seguridad y a la comprobación de integridad antes que a repetir Attach.

Volcado .SQL de MySQL: Crea una base de datos nueva e importa el volcado con el cliente mysql o desde una herramienta de administración.

Volcado de PostgreSQL: Lo habitual es usar psql para el formato SQL plano y pg_restore para el formato custom/tar.

8. Errores que debes evitar en SQL Data Recovery

• Sobrescribir directamente la base de datos en producción con la copia recuperada --- Verifica primero los archivos recuperados en una instancia o un servidor de pruebas aparte.
• Seguir guardando datos en la unidad donde estaban los archivos eliminados --- Los datos nuevos pueden sobrescribir la zona de los archivos borrados.
• Intentar PITR sin comprobar los registros y la cadena de copias --- Si faltan los registros necesarios para el punto de recuperación, la restauración puede detenerse.
• Usar REPAIR_ALLOW_DATA_LOSS como primera opción --- Como su propio nombre indica, esta opción puede provocar pérdida de datos.
• Omitir las pruebas de la aplicación después de la recuperación --- Aunque las tablas se abran, hay que comprobar que los índices, las relaciones, los permisos y las dependencias de la aplicación estén correctos.

9. Consejos prácticos para aumentar la tasa de éxito de la recuperación

• Separa la base de datos en producción de la ubicación de las copias de seguridad y mantén al menos una copia en almacenamiento offline o en un dispositivo distinto.

• En SQL Server, ajusta el modelo de recuperación y la frecuencia de las copias del registro a los objetivos reales de RPO/RTO.

• En MySQL, no te limites a activar el Binary Log, y en PostgreSQL, el archivado WAL: realiza pruebas de recuperación de forma periódica.

• Si tienes que recuperar archivos de base de datos, comprueba en los resultados del análisis el tamaño y la ruta original del archivo para decidir si es el correcto.

• En las bases de datos más importantes, ejecuta «pruebas de restauración» periódicas para verificar que los archivos de copia de seguridad son realmente utilizables.

10. Preguntas frecuentes sobre SQL Data Recovery

P1. ¿Se pueden recuperar datos SQL eliminados sin una copia de seguridad?

Depende de la situación. Si se han eliminado registros dentro de la base de datos, puede que necesites el registro de transacciones o las funciones de recuperación del motor. Si lo que se ha eliminado son los propios archivos MDF/BAK/SQL, puedes recuperar los archivos del dispositivo de almacenamiento y después intentar restaurar la base de datos.

P2. ¿Basta con recuperar el archivo MDF para poder abrir la base de datos de SQL Server?

No siempre. El resultado depende del estado del MDF y del archivo de registro, de si la base de datos se cerró correctamente y de si los archivos están dañados. En entornos críticos, es más seguro restaurar desde una copia de seguridad o consultar a un DBA que repetir Attach.

P3. ¿4DDiG Data Recovery repara directamente una base de datos SQL dañada?

4DDiG Data Recovery se centra en localizar y recuperar archivos de base de datos y de copia de seguridad eliminados o perdidos en el dispositivo de almacenamiento. La recuperación lógica de la estructura interna de la base de datos debe hacerse con las herramientas de cada motor: SQL Server, MySQL, PostgreSQL, etc.

P4. He eliminado por error un archivo BAK de SQL Server, ¿qué debo hacer?

Reduce al mínimo el uso de esa unidad e intenta primero recuperar el archivo. Si consigues recuperar el BAK, lo mejor es restaurarlo en SSMS como una base de datos aparte y comprobar la integridad y los datos.

P5. ¿Qué es lo primero que hay que comprobar después de recuperar una base de datos?

Comprueba el número de filas y los datos clave de las tablas principales, los índices y las restricciones, los permisos de usuario y la conexión de la aplicación. Si es posible, verifícalo en un entorno de pruebas antes de aplicarlo en producción.

P6. ¿Qué puedo hacer para que la recuperación de datos SQL sea más fácil en el futuro?

Lo más eficaz es combinar copias de seguridad periódicas, copias del registro o retención de WAL/Binary Log, copias en un almacenamiento aparte y pruebas de restauración reales.

Conclusión

La clave del SQL data recovery es identificar primero con precisión el tipo de pérdida. Si se han eliminado registros, revisa las copias de seguridad y el registro de transacciones; si la base de datos está dañada, revisa primero las funciones de comprobación de integridad y restauración del motor. En cambio, si lo que se ha eliminado son los propios archivos, como MDF, LDF, BAK o el volcado SQL, lo importante es dejar de usar el dispositivo de almacenamiento y recuperar primero los archivos.

4DDiG Data Recovery puede ayudarte a recuperar los archivos de base de datos o de copia de seguridad en esas situaciones en las que «el propio archivo ha desaparecido». Después de la recuperación, verifica siempre en un entorno aparte la integridad de los archivos y el estado de la base de datos antes de aplicarlo en producción.