Recuperación de Datos de Base de Datos MySQL Corrupta

Una base de datos MySQL o MariaDB corrupta puede detener completamente el funcionamiento de una aplicación o sitio web. La buena noticia es que, en la mayoría de los casos, los datos siguen existiendo en los archivos del sistema; lo que falla son las estructuras que permiten acceder a ellos. Con las técnicas adecuadas es posible recuperar la información sin perder prácticamente nada.

InnoDB vs MyISAM: Diferencias Cruciales en Recuperación

El motor de almacenamiento que utilice la tabla corrupta determina completamente el proceso de recuperación. MySQL ofrece principalmente dos motores, con comportamientos muy distintos ante la corrupción:

MyISAM

MyISAM almacena cada tabla en tres archivos separados: .frm (definición de la tabla), .MYD (datos) y .MYI (índices). Sus características de recuperación son:

• Recuperación directa: Los datos en .MYD se almacenan en formato relativamente legible. Incluso con índices corruptos (.MYI), los datos originales suelen ser accesibles.
• myisamchk: La herramienta nativa de MySQL para reparar tablas MyISAM. Puede reconstruir índices sin tocar los datos.
• REPAIR TABLE: Comando SQL que intenta reparar la tabla directamente desde el servidor MySQL.
• Portabilidad: Las tablas MyISAM pueden copiarse simplemente copiando los tres archivos a otro servidor con la misma versión de MySQL.

InnoDB

InnoDB es el motor predeterminado desde MySQL 5.5 y ofrece transacciones ACID, pero su arquitectura hace la recuperación más compleja:

• Tablespace compartido (ibdata1): En configuraciones antiguas, todas las tablas InnoDB comparten un único archivo ibdata1. La corrupción de este archivo puede afectar a todas las tablas simultáneamente.
• File-per-table (.ibd): Con innodb_file_per_table=ON (predeterminado desde MySQL 5.6), cada tabla tiene su propio archivo .ibd. La corrupción queda más contenida.
• Redo log y undo log: InnoDB mantiene registros de transacciones para garantizar la consistencia. Si estos registros están corruptos, el servidor no puede arrancar.
• Diccionario de datos: InnoDB mantiene metadatos de las tablas tanto en ibdata1 como en los propios archivos .ibd.

El Archivo ibdata1: El Corazón de InnoDB

El archivo ibdata1 es el componente más crítico del motor InnoDB. Contiene:

• El diccionario de datos InnoDB (lista de tablas, columnas, índices)
• El undo log (registro de cambios para posibles rollbacks)
• El doublewrite buffer (protección contra escrituras parciales)
• En configuraciones antiguas sin innodb_file_per_table: los datos de todas las tablas

Cuando ibdata1 se corrompe, MySQL generalmente no puede iniciar. Los síntomas típicos incluyen mensajes como InnoDB: Corruption in the InnoDB tablespace o innodb: Page log sequence number is in the future en los logs de error.

innodb_force_recovery: Los 6 Niveles de Recuperación

MySQL ofrece el parámetro innodb_force_recovery para intentar arrancar el servidor con un motor InnoDB parcialmente corrupto. Se configura en my.cnf o my.ini y acepta valores del 1 al 6:

Advertencia importante: Con niveles 4, 5 y 6 el servidor puede arrancar pero los datos pueden estar en un estado inconsistente. Nunca escriba en la base de datos con estos modos activos; únicamente use SELECT para exportar los datos y luego restaure desde cero.

Recuperación mediante Binary Log (Binlog)

El binary log de MySQL registra todas las modificaciones de datos en formato binario. Es la herramienta más potente para la recuperación point-in-time (PITR):

1. Restaurar el último backup completo: Punto de partida necesario para la recuperación PITR.
2. Identificar los archivos binlog relevantes: Los archivos binlog posteriores al backup contienen todos los cambios que hay que reaplicar.
3. Usar mysqlbinlog para extraer y aplicar cambios: mysqlbinlog binlog.000001 | mysql -u root -p base_datos
4. Recuperación hasta un punto concreto: Si la corrupción ocurrió a las 14:30, se pueden aplicar solo los binlogs hasta las 14:29.

Para que el binlog sea útil, debe estar habilitado (log_bin=ON) ANTES del incidente. Si no estaba habilitado, no hay registros que reaplicar.

Archivos .frm en MySQL 5.x: Recuperación de Definiciones de Tabla

En MySQL 5.x, el archivo .frm contiene la definición de la tabla (estructura de columnas, tipos de datos). Si este archivo se corrompe o pierde, MySQL no puede abrir la tabla aunque los datos en .ibd estén intactos. Las soluciones incluyen:

• Recrear el .frm a partir del esquema conocido: Si se conoce la estructura original, se puede crear una tabla idéntica en otro servidor y copiar su .frm.
• mysqlfrm (MySQL Utilities): Herramienta que intenta extraer la definición de estructura desde un archivo .frm parcialmente corrupto.
• Exportar el .ibd después de recrear el .frm: Con ALTER TABLE ... DISCARD TABLESPACE y luego IMPORT TABLESPACE.

MySQL 8.0: El Nuevo Diccionario de Datos

MySQL 8.0 eliminó los archivos .frm e introdujo un diccionario de datos centralizado almacenado en un tablespace InnoDB especial (mysql.ibd). Esto tiene implicaciones importantes para la recuperación:

• Ya no es posible recuperar una tabla simplemente copiando sus archivos .ibd a otro servidor (el diccionario de datos debe coincidir).
• La corrupción del diccionario de datos en mysql.ibd puede hacer que MySQL 8.0 no reconozca ninguna tabla.
• La recuperación de archivos .ibd individuales en MySQL 8.0 requiere el uso del procedimiento innodb_tablespace_monitor y herramientas de terceros para extraer datos directamente del formato de páginas InnoDB.

Extracción Directa desde Archivos .ibd

Cuando el servidor MySQL no puede arrancar ni siquiera con innodb_force_recovery=6, la última opción es extraer datos directamente del archivo .ibd sin pasar por el servidor MySQL. Las herramientas especializadas para esto incluyen:

• innodb_space: Herramienta de código abierto que lee directamente las páginas InnoDB del archivo .ibd y puede extraer registros en formato CSV.
• undrop-for-innodb: Proyecto de recuperación forense que escanea el archivo .ibd buscando fragmentos de registros de datos, incluso en espacio marcado como libre.
• Herramientas comerciales de recuperación: Varias soluciones comerciales permiten recuperar datos de .ibd corruptos con interfaces gráficas.

Proceso Recomendado ante una MySQL Corrupta

1. No intente reparar en producción: Haga una copia de todos los archivos de datos MySQL (/var/lib/mysql/) antes de cualquier acción.
2. Revise los logs de error: /var/log/mysql/error.log o el path configurado en log_error. Los mensajes de error indican qué archivos están afectados.
3. Pruebe innodb_force_recovery comenzando por nivel 1 y subiendo progresivamente.
4. Exporte con mysqldump en cuanto el servidor arranque: mysqldump --all-databases > backup.sql
5. Aplique los binlogs disponibles para minimizar la pérdida de datos.
6. Si nada funciona, consulte a un especialista con los archivos .ibd e ibdata1 para recuperación forense.

Te puede interesar

• › Recuperación de Datos de Base de Datos PostgreSQL Corrupta
• › Recuperación de Datos de Base de Datos Oracle Corrupta
• › Recuperación de Datos de Base de Datos SQL Server Corrupta
• › Recuperar datos con contraseña de BIOS o HDD password: guía técnica