Cómo recuperar un tablespace InnoDB corrupto en MySQL sin pérdida de datos

Por · Publicado el · 8 min de lectura

Troncos apilados con textura de corte y anillos visibles
Metáfora visual de organización, integridad y recuperación de datos Foto: R L / Pexels

¿Necesitas recuperar un tablespace InnoDB corrupto en MySQL sin perder datos? Detén las escrituras, realiza una copia segura y sigue un plan predecible. Abajo encontrarás señales, causas, estrategias y procedimientos prácticos (innodb_force_recovery, volcado lógico y IMPORT TABLESPACE) para maximizar las probabilidades de recuperar todo con integridad.

Señales de corrupción y cuándo detener el servidor

El primer paso es reconocer el problema y dejar de agravar el daño. En cuanto detectes corrupción, detén las escrituras inmediatamente y planifica la recuperación en un clon/snapshot.

Busca en el log de errores mensajes típicos y confirma el alcance de la falla (una tabla aislada o el tablespace del sistema).

  • InnoDB: Page corruption: space id and page no stored in the page, read in file
  • InnoDB: Space id in the header is wrong
  • [ERROR] InnoDB: Corruption of an index tree
  • InnoDB: Missing or invalid ibd file (table is missing)
  • InnoDB: Log sequence number is in the future
  • Got error -1 from storage engine ao abrir tabela

Causas probables y cómo evaluar el impacto

Las corrupciones suelen estar relacionadas con fallos de disco/RAID, cortes de energía, caché de escritura sin batería, parámetros de durabilidad relajados o bugs en versiones antiguas. Evalúa la extensión: si el error ocurre solo al acceder a una tabla, probablemente sea su .ibd; si el servidor no arranca o se queja del diccionario, el objetivo puede ser el tablespace del sistema (ibdata1).

Antes de cualquier intento: crea una copia física fría del datadir, redo/undo (ib_logfile* y undo_00*), temporarios (ibtmp1) y del my.cnf. Si usas LVM, un snapshot ayuda a congelar el estado sin downtime adicional. Consulta una forma automatizada de snapshots con upload incremental a S3 en este artículo: Instantáneas LVM + Restic en S3.

Plan de recuperación sin pérdida (visión general)

El objetivo es extraer datos lógicamente íntegros y reconstruir InnoDB en un entorno limpio. En la práctica, la mínima pérdida ocurre cuando el servidor aún arranca en modo de recuperación y permite SELECTs consistentes.

  • Congelar el estado: copia fría o snapshot del volumen.
  • Arrancar con innodb_force_recovery (niveles crecientes) solo para lectura y extraer volcados lógicos.
  • Priorizar volcado por base/tabla con --single-transaction para minimizar locks.
  • Si la corrupción está aislada en una tabla, intentar volcar solo esa tabla o IMPORT TABLESPACE desde un backup consistente.
  • Reconstruir el diccionario de InnoDB en un entorno limpio y restaurar los volcados.
  • Validar integridad y conteos antes de volver a producción.

Estrategias por escenario (mapa rápido)

Usa este esquema para decidir el camino inicial. Sé conservador: no ejecutes escrituras mientras tengas innodb_force_recovery activo.

Escenario Riesgo de pérdida Acción sugerida
Una tabla específica falla al abrir Bajo a moderado Intentar SELECT/volcado solo de esa tabla; si tienes backup con .cfg, usar DISCARD/IMPORT TABLESPACE.
Servidor no arranca; errores en el diccionario (ibdata1) Alto Arrancar con innodb_force_recovery y extraer volcado lógico completo; luego reconstruir InnoDB y restaurar.
Redo/undo inconsistentes tras corte de energía Moderado Intentar iniciar con niveles bajos de innodb_force_recovery para permitir un volcado consistente; validar todas las tablas.

Procedimiento A: el servidor arranca con innodb_force_recovery

Define innodb_force_recovery en my.cnf empezando por 1 y subiendo gradualmente hasta el nivel mínimo que permita el arranque. Los niveles superiores a 3 son agresivos y deshabilitan partes críticas de InnoDB. Nunca escribas en la base de datos en este modo; úsalo solo para SELECT/volcado.

Con el servidor en pie, extrae volcados por esquema y de objetos dependientes (routines, events, triggers) con transacción consistente. Desactiva el binlog en la sesión de volcado si es necesario.

  • Orden: usuarios/privilegios, esquemas, tablas, datos, routines, events, triggers, views.
  • Aislar tablas problemáticas para tratarlas en el Procedimiento B.
  • Guardar el log de errores junto con los volcados para auditoría.
mysqldump \
  --single-transaction --routines --events --triggers \
  --hex-blob --default-character-set=utf8mb4 \
  --databases suabase > dump_suabase.sql

# Dica: para casos difíceis, dumpe tabela a tabela
# mysqldump --single-transaction suabase tabela > suabase_tabela.sql

Procedimiento B: corrupción limitada a una tabla (.ibd)

Si solo una tabla falla y el resto está íntegro, intenta primero extraer un volcado lógico de esa tabla (SELECT/mysqldump). Si tienes un backup consistente de la tabla con el par .ibd/.cfg (generado por FLUSH TABLES ... FOR EXPORT), es posible reconstruirla en una instancia limpia usando DISCARD/IMPORT TABLESPACE.

El esquema de la tabla debe ser idéntico. Haz esto en una copia aislada, valida y solo entonces reemplaza en producción.

  • Asegurar innodb_file_per_table=ON.
  • Esquema idéntico (mismo charset/collation/índices).
  • Usar .cfg correspondiente al .ibd del backup para evitar mismatch de space_id.
-- Na instância de recuperação
CREATE TABLE suabase.minhatabela (...definição idêntica...);
ALTER TABLE suabase.minhatabela DISCARD TABLESPACE;
-- Copiar o .ibd e o .cfg do backup consistente para o datadir da tabela
ALTER TABLE suabase.minhatabela IMPORT TABLESPACE;

Procedimiento C: tablespace del sistema (ibdata1) corrupto

Cuando el diccionario de InnoDB está comprometido, la ruta más segura es salvar los datos lógicamente con innodb_force_recovery y luego reconstruir InnoDB desde cero en una nueva instancia, restaurando desde los volcados.

El flujo típico es: extraer todos los esquemas y objetos, inicializar un datadir nuevo, recrear usuarios/privilegios, restaurar los volcados y validar la integridad referencial.

  • Inicializar nuevo datadir y redo/undo limpios.
  • Restaurar en orden que respete claves foráneas (o desactivar temporalmente FOREIGN_KEY_CHECKS y revalidar al final).
  • Ejecutar CHECK TABLE y contar filas para comparar con el entorno original.
  • Antes de volver al tráfico, ejecutar pruebas de aplicación y reports críticos.

Validación post‑recuperación y prevención

Antes de retomar la producción, valida datos y comportamiento. Después, aborda las causas para evitar repetir el incidente. Si necesitas un plan de backups y restauración confiable, consulta esta implementación con políticas y pruebas: Backups incrementales y cifrados en S3.

  • Comparar conteos por tabla con SELECT COUNT(*) y muestreos de sumas críticas.
  • CHECK TABLE en las principales tablas InnoDB (entender que es limitado, pero útil para detectar problemas evidentes).
  • Reprocesar reportes/foreign keys y observar el log de errores por un periodo.
  • Infraestructura: usar UPS, storage fiable, fsync, monitorización SMART/RAID.
  • Configuración: innodb_flush_log_at_trx_commit=1 y sync_binlog=1 para durabilidad.
  • Backups: rutina con snapshots + almacenamiento externo; pruebas de restauración documentadas. Ver también recuperación por PITR en otro SGBD para inspiración: Recuperar tabla en PostgreSQL con point‑in‑time.
  • Higiene del servidor: prácticas de hardening y monitorización reducen riesgos colaterales. Consulta el checklist de seguridad para VPS Linux.

Preguntas frecuentes

¿Puedo usar REPAIR TABLE en InnoDB?

No. REPAIR TABLE está destinado a MyISAM. Para InnoDB, el enfoque correcto es iniciar con innodb_force_recovery, extraer volcados lógicos y, si es necesario, reconstruir el tablespace o importar la tabla desde un backup consistente.

¿Qué nivel de innodb_force_recovery debo usar?

Comienza en 1 y aumenta gradualmente hasta el menor nivel que permita arrancar el servidor. Los niveles superiores a 3 son agresivos y sirven solo para lectura y extracción. Nunca escribas datos en este modo para evitar agravar la corrupción.

¿Es posible recuperar sin el archivo .cfg de la tabla?

Sin el .cfg creado por FLUSH TABLES ... FOR EXPORT, IMPORT TABLESPACE puede fallar por incompatibilidades de metadata. En general, la alternativa más segura es recuperar vía volcado lógico o restaurar la tabla desde un backup consistente que incluya el par .ibd/.cfg.

¿Cuándo debo preferir volcado lógico a backup físico?

En presencia de corrupción, el volcado lógico suele ser más seguro porque reinterpreta páginas válidas a nivel SQL. Backups físicos copian bloques; si la fuente está corrupta, el problema persiste. Usa el físico para clonar el estado y probar enfoques off-line.

¿Cómo evitar que la corrupción vuelva a ocurrir?

Usa hardware fiable (UPS, discos y controladoras con protección de caché), monitoriza SMART/RAID, configura durabilidad (innodb_flush_log_at_trx_commit=1, sync_binlog=1), mantén el sistema actualizado e implementa rutina de backups con pruebas de restauración documentadas.

¿Caso crítico? Actúa con método y preserva evidencias

Congela el estado (snapshot/copia), registra errores y trabaja en una instancia de recuperación. Para estructurar backups y pruebas de restauración en el día a día, busca el apoyo de un DBA/consultor de confianza.

Ver opciones de backup y recuperación

Ver también