Una base de datos MySQL, SQL Server, PostgreSQL u Oracle corrompida puede paralizar un negocio completo en cuestión de minutos. Los sistemas de base de datos tienen mecanismos internos de recuperación (InnoDB Crash Recovery, SQL Server DBCC), pero cuando estos fallan —por corrupción grave, disco dañado o borrado accidental— la única opción es recuperar los datos directamente de los ficheros binarios de la base de datos. Es un proceso especializado que requiere conocimiento profundo de cada motor.
Recuperación de bases de datos — Datos clave
MySQL/MariaDB, SQL Server, PostgreSQL, Oracle
ibdata1, .ibd, .MDF/.LDF, pg_data, datafiles Oracle
Desde 400€ (corrupción lógica)
1–5 días laborables según tamaño
Por qué se corrompen las bases de datos
Las bases de datos son sistemas complejos que mantienen múltiples archivos en estado consistente mediante transacciones. Cuando algo interrumpe ese proceso, el resultado es corrupción:
- Corte de luz durante una transacción activa: El mecanismo write-ahead log (WAL en PostgreSQL, InnoDB redo log en MySQL, transaction log en SQL Server) normalmente permite recuperarse, pero si el disco tiene sectores defectuosos donde está el log, la recuperación falla
- Disco con sectores defectuosos: Los errores de lectura en páginas de datos o en el tablespace producen corrupción que el motor de base de datos reporta como "table corrupted", "checksum mismatch" o "torn page"
- Actualización de motor interrumpida: Actualizar MySQL de 5.7 a 8.0 o SQL Server a una versión mayor puede fallar dejando el catálogo del sistema en estado inconsistente
- DROP TABLE / DROP DATABASE accidental: Uno de los casos más frecuentes — especialmente en entornos de desarrollo donde se ejecuta un script en producción por error
- Ransomware: Los archivos de base de datos son objetivo prioritario del ransomware por su alto valor
- RAID degradado con escritura continuada: Operar con un RAID 5 degradado durante mucho tiempo puede producir inconsistencias en los archivos de base de datos
MySQL / MariaDB: recuperación de InnoDB
Estructura de ficheros InnoDB
InnoDB (el motor por defecto de MySQL desde 5.5) almacena los datos en:
- ibdata1: El tablespace compartido. Contiene el diccionario de datos (información sobre tablas y columnas), el undo log y, opcionalmente, los datos de las tablas si no se usa
innodb_file_per_table - Archivos .ibd: Un archivo por tabla cuando está activo
innodb_file_per_table=ON(por defecto desde MySQL 5.6.6) - ib_logfile0, ib_logfile1: El redo log de InnoDB — esencial para la recuperación de transacciones incompletas
Opciones de recuperación nativa: innodb_force_recovery
MySQL tiene un modo de recuperación forzada controlado por innodb_force_recovery (valores 1-6 en my.cnf). Cada nivel desactiva más salvaguardas para permitir arrancar la base de datos y exportar los datos:
- Nivel 1 (
SRV_FORCE_IGNORE_CORRUPT): Ignora páginas corruptas - Nivel 2: No ejecuta threads en background de InnoDB al arrancar
- Nivel 3: No hace rollback de transacciones al arrancar
- Nivel 4: Previene operaciones de INSERT, UPDATE y DELETE
- Nivel 5: No mira el undo log al arrancar
- Nivel 6: No hace forward scan del redo log
Procedimiento: Empieza por el nivel 1 y ve aumentando hasta que MySQL arranque. Cuando lo haga, exporta los datos con mysqldump inmediatamente. No continúes operando en nivel de recuperación.
Recuperación de .ibd sin ibdata1
Si tienes los archivos .ibd pero el ibdata1 está corrupto o lo has perdido, la recuperación es más compleja: necesitas reconstruir el diccionario de datos. Herramientas como InnoDB Recovery Toolkit (Percona) o undrop-for-innodb permiten extraer datos directamente de las páginas InnoDB sin pasar por el motor MySQL.
SQL Server: recuperación de archivos MDF/LDF
Estructura de ficheros SQL Server
- .MDF (Master Data File): El archivo principal de datos
- .NDF: Archivos de datos secundarios (bases de datos grandes)
- .LDF (Log Data File): El transaction log — puede crecer indefinidamente si no se gestiona
Diagnóstico con DBCC CHECKDB
El primer paso ante sospecha de corrupción es ejecutar DBCC CHECKDB('nombre_bd') WITH NO_INFOMSGS. Si devuelve errores, el nivel de severidad indica la gravedad:
- Severity 16: Corrupción de datos en páginas — requiere restauración o reparación
- Severity 21-24: Corrupción grave — puede requerir intervención profesional
DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS
DBCC CHECKDB('nombre_bd', REPAIR_ALLOW_DATA_LOSS) intenta reparar la base de datos, pero como su nombre indica, puede perder datos. Úsalo solo como última opción y siempre sobre una copia, nunca sobre la base de datos de producción.
Cuando el LDF está corrupto o falta
Si el archivo LDF falta o está corrupto pero el MDF está intacto, SQL Server permite adjuntar la base de datos solo con el MDF y reconstruir el LDF. Esto crea un nuevo log vacío, pero implica que las transacciones no confirmadas se pierden.
PostgreSQL: corrupción de datos
PostgreSQL almacena los datos en directorios de PGDATA con archivos numerados (relfilenode). La corrupción se detecta con:
pg_dumpque falla con errores de checksum- Errores en el log de PostgreSQL: "invalid page in block", "could not read block"
La herramienta pg_filedump permite inspeccionar las páginas individuales de PostgreSQL y puede extraer datos de páginas parcialmente corruptas. Para corrupción grave, el proceso es similar al de MySQL: acceder directamente a los bloques de datos y reconstruir las filas.
Cuándo se necesita intervención profesional
La recuperación por software tiene sus límites. Se necesita laboratorio profesional cuando:
- El disco donde está la base de datos tiene fallos físicos (sectores defectuosos, cabezales dañados)
- Los mecanismos de recuperación nativos del motor no permiten siquiera arrancar
- La corrupción afecta al diccionario de datos o al catálogo del sistema
- Los datos se borraron y el servidor ha continuado en funcionamiento (sobreescritura)
- Servidor en producción que no puede detenerse para un proceso largo de recuperación
Proceso de recuperación de bases de datos en RecuperaTusDatos
- Imagen forense: Antes de cualquier acción, se hace una copia sector a sector del disco/servidor afectado
- Análisis del motor y versión: Cada versión de MySQL, SQL Server o PostgreSQL tiene diferencias en la estructura interna de sus archivos
- Extracción de páginas de datos: Con herramientas especializadas, se extraen directamente las páginas de datos del motor, omitiendo los mecanismos de recuperación que fallan
- Reconstrucción del esquema: Si el diccionario de datos está corrupto, se reconstruye el esquema a partir de la estructura interna de las páginas
- Exportación verificada: Los datos extraídos se exportan en formato SQL o CSV y se verifican antes de la entrega
Preguntas frecuentes sobre recuperación de bases de datos
.ibd no se sobreescriben inmediatamente tras un DROP TABLE/DATABASE — el espacio se marca como disponible pero los datos físicos permanecen temporalmente. La clave es detener el servidor de base de datos inmediatamente para evitar que el espacio liberado se reutilice con nuevas escrituras. Con el servidor detenido, la recuperación tiene altas probabilidades de éxito.
WhatsApp