How to recover a corrupt InnoDB tablespace in MySQL without data loss

By Kevin Marcondes · Published on Oct 28, 2026 · 8 min read

Need to recover a corrupt InnoDB tablespace in MySQL without losing data? Stop writes, take a safe copy, and follow a predictable plan. Below you’ll find signs, causes, strategies and practical steps (innodb_force_recovery, logical dumps and IMPORT TABLESPACE) to maximize the chance of a full, consistent recovery.

Signs of corruption and when to stop the server

The first step is to recognize the problem and avoid making it worse. Once you detect corruption, stop all writes immediately and plan the recovery on a clone or snapshot.

Search the error log for typical messages and confirm the scope of the failure (a single table or the system tablespace).

• 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

Likely causes and how to assess impact

Corruption is often linked to disk/RAID failure, power loss, an unprotected write cache, relaxed durability settings or bugs in older MySQL versions. Assess the extent: if the error occurs only when accessing a table, it's likely that table's .ibd; if the server fails to start or reports dictionary errors, the target may be the system tablespace (ibdata1).

Before attempting anything: take a cold physical backup of the datadir, redo/undo logs (ib_logfile* , undo_00*), temporary files (ibtmp1) and my.cnf. If you use LVM, a snapshot helps freeze the state without extra downtime. See an automated snapshot and incremental S3 upload approach in: LVM snapshots + Restic to S3.

Non‑loss recovery plan (overview)

The goal is to extract logically consistent data and rebuild InnoDB in a clean environment. In practice, the least data loss happens when the server can still start in recovery mode and allows consistent SELECTs.

• Freeze the state: cold copy or snapshot of the volume.
• Start with innodb_force_recovery (increasing levels) for read-only access and extract logical dumps.
• Prioritize dumping per database/table with --single-transaction to minimize locks.
• If corruption is isolated to one table, try dumping only that table or use IMPORT TABLESPACE from a consistent backup.
• Rebuild the InnoDB data dictionary in a clean instance and restore the dumps.
• Validate integrity and row counts before returning traffic.

Strategies by scenario (quick map)

Use this table to pick an initial path. Be conservative: do NOT perform writes while innodb_force_recovery is active.

Procedure A: server starts with innodb_force_recovery

Set innodb_force_recovery in my.cnf starting at 1 and raise it gradually to the lowest level that allows the server to start. Levels above 3 are aggressive and disable important InnoDB features. Never write to the database in this mode; use it only for SELECTs and dumps.

With the server running, extract dumps by schema and include dependent objects (routines, events, triggers) in a consistent transaction. Disable binary logging in the dump session if needed.

• Order: users/privileges, schemas, tables, data, routines, events, triggers, views.
• Isolate problematic tables for handling with Procedure B.
• Keep the error log together with the dumps for auditing.

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

Procedure B: corruption limited to one table (.ibd)

If only one table fails and the rest appears intact, first try to extract a logical dump of that table (SELECT or mysqldump). If you have a consistent backup of the table with the .ibd/.cfg pair (created by FLUSH TABLES ... FOR EXPORT), you can reconstruct it on a clean instance using DISCARD/IMPORT TABLESPACE.

The table definition must be identical. Perform this on an isolated copy, validate it, and only then replace the production table.

• Ensure innodb_file_per_table=ON.
• Identical table schema (same charset/collation/indexes).
• Use the .cfg that matches the backup .ibd to avoid space_id mismatches.

-- 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;

Procedure C: system tablespace (ibdata1) corrupted

When the InnoDB dictionary is compromised, the safest route is to extract data logically with innodb_force_recovery and then rebuild InnoDB from scratch on a new instance, restoring from the dumps.

Typical flow: extract all schemas and objects, initialize a new datadir, recreate users/privileges, restore dumps and validate referential integrity.

• Initialize a new datadir and clean redo/undo logs.
• Restore in an order that respects foreign keys (or temporarily disable FOREIGN_KEY_CHECKS and revalidate at the end).
• Run CHECK TABLE and compare row counts with the original environment.
• Before returning traffic, run application tests and critical reports.

Post‑recovery validation and prevention

Before resuming production, validate data and behavior. Afterwards, address root causes to avoid recurrence. If you need a reliable backup and restore plan, see our deployment with policies and tests: Encrypted incremental S3 backups.

• Compare table counts with SELECT COUNT(*) and sample critical aggregates.
• Run CHECK TABLE on main InnoDB tables (it's limited but useful to catch obvious issues).
• Reprocess reports/foreign keys and monitor the error log for a period.
• Infrastructure: use a UPS, reliable storage, and fsync; monitor SMART/RAID health.
• Configuration: innodb_flush_log_at_trx_commit=1 and sync_binlog=1 for durability.
• Backups: scheduled snapshots plus external storage; documented restoration tests. Also see a recovery example on another database: recover a PostgreSQL table with point-in-time recovery.
• Server hygiene: hardening and monitoring practices reduce collateral risks. See the VPS Linux security checklist.

Frequently asked questions

Can I use REPAIR TABLE on InnoDB?

No. REPAIR TABLE is for MyISAM. For InnoDB, the correct approach is to start with innodb_force_recovery, extract logical dumps, and if necessary rebuild the tablespace or import the table from a consistent backup.

Which innodb_force_recovery level should I use?

Start at 1 and increase gradually to the lowest level that allows the server to start. Levels above 3 are aggressive and only intended for read-only extraction. Never write data in this mode to avoid worsening corruption.

Can I recover without the table's .cfg file?

Without the .cfg created by FLUSH TABLES ... FOR EXPORT, IMPORT TABLESPACE may fail due to metadata mismatches. Generally the safer alternative is logical recovery via dumps or restoring the table from a consistent backup that includes the .ibd/.cfg pair.

When should I prefer a logical dump over a physical backup?

In the presence of corruption, a logical dump is usually safer because it reinterprets valid pages at the SQL level. Physical backups copy blocks; if the source is corrupted, the problem remains. Use physical copies to clone the state and test offline approaches.

How do I prevent corruption from happening again?

Use reliable hardware (UPS, disks and controllers with protected cache), monitor SMART/RAID, set durability options (innodb_flush_log_at_trx_commit=1, sync_binlog=1), keep the system updated and implement a backup routine with documented restore tests.

See also

• Intermittent 502 Bad Gateway in Docker Compose with Nginx & PHP‑FPM: how to diagnose and fix timeouts and connection overloads
• How to diagnose and capture packets for intermittent network issues between Docker containers on Debian
• How to detect and fix duplicate SKU inconsistencies between WooCommerce and your ERP without losing orders
• How to reduce build time and avoid duplicate artifacts in CI for large PHP monoliths