Innodump recovers rows from offline relational database files
Innodump can extract rows and table definitions directly from offline data files belonging to open-source relational database systems used by many web applications, without starting a database server. Introduced in a Percona article dated October 28, 2026, the experimental open-source tool supports InnoDB, MyISAM and MyRocks, also known as RocksDB, and is intended for recovery, inspection and selective extraction rather than as a replacement for proper backups.
The tool can process an entire data directory, a database folder, an individual file, or tables held in shared, general and per-table tablespaces. A tablespace is a file or storage area in which a database engine keeps tables and indexes. Innodump reads the stored table schema and rows, then exports them as SQL or as tab-separated values, called TSV. Its TSV output is compatible with database shell dump utilities, allowing the extracted data to be loaded efficiently into another instance.
Potential uses include salvaging healthy rows after corruption, checking which data in a backup remains readable, extracting selected tables from a full backup, preparing staging or quality-assurance systems, recovering recently deleted rows, searching across old backups for forensic work and migrating data from legacy database versions. It can inspect ordinary data directories as well as binary backups such as storage-volume snapshots and XtraBackup copies.
This is not another backup method. Modern engines use ACID rules, which protect transaction reliability, and MVCC, or multiversion concurrency control, which lets transactions see appropriate versions of changing data. Reading files directly does not reproduce all the work required to establish a consistent database state. Dedicated backup software can follow the redo log, the record of changes needed during recovery, and use backup locks to coordinate file copying. A raw extraction may therefore contain data that never represented one consistent point in time. Point-in-time recovery, or PITR, remains important because it allows a database to be restored to a selected moment using backups and recorded changes.
Offline extraction becomes particularly relevant when corruption prevents the database server from remaining online. A server may shut down deliberately after detecting severe damage to avoid making matters worse. Corruption in a secondary index can sometimes be addressed by rebuilding that index, but damage to the clustered index, which holds table rows in primary-key order, can crash the engine whenever it reaches the affected page. Conventional recovery then becomes slow because each attempt to read a damaged page may force another server restart.
Innodump's skip-corrupted option reports a damaged data page and continues with the next one. In Percona's example using innodump 0.8.1, a 130,023,424-byte InnoDB file contained 7,936 pages of 16,384 bytes and metadata written by the open-source database, version 8.0.33. The tool detected a mismatch in the log sequence number bytes on page 100 of the primary index. It skipped that page and wrote 100,680 rows, showing how an offline pass can recover readable records without repeatedly crashing a running server.
The examine mode reads and decodes rows without creating an export. It reports the tables and rows found, along with corruption that prevents records from being decoded. One demonstrated scan covered six InnoDB tables containing 29 rows and one MyRocks table containing 1,000,000 rows, for 1,000,029 rows in total. It also found 129 legacy table-definition files without matching per-table files or entries in the shared InnoDB dictionary; these could have represented non-InnoDB tables, views or tables in a general tablespace, so they were not examined. The mode reads only the clustered index and cannot identify corruption confined to secondary indexes. Percona advises beginning an InnoDB corruption scan with the official checksum utility; innodump's narrower purpose is to establish what can actually be read and restored.
Selective extraction can avoid restoring a complete backup when only a few databases are required. In one example, innodump exported five tables containing 1,359,877 rows in total from a single database directory. The output included compressed TSV files and supporting files compatible with the database shell's dump-loading function. This can reduce the work involved in creating a non-production copy when exact point-in-time consistency is not required.
Reading a live data directory carries substantial consistency risks. Dirty pages, meaning changes still held in memory, may not yet be on disk; a page may be captured in the middle of a write; rows can be missing, stale or incorrectly marked; and recently created tables in a shared space may be absent. Those limitations may be acceptable for a disposable staging copy, but not for authoritative recovery or a production migration.
To reduce impact on a live system, innodump offers an input and output limit to cap disk throughput and a direct input and output option to bypass the operating system's page cache. That avoids filling the cache with one-time reads and reduces the risk that the operating system will move less recently used application memory to swap. The article also recommends lowering CPU priority with nice. In a test exporting 1,500,000 rows from a 228 MB table with zstd compression, an unrestricted run took 1.726 seconds and left 192.1 MB in the page cache. A run limited to 30 MB per second with direct input and output took 9.241 seconds but left none of the file cached.
InnoDB may also leave deleted records recoverable for a short time. Deletion initially marks a row rather than immediately overwriting its space. If subsequent writes have not reclaimed that space, the record may still be decoded. The deleted-only option exported 2,100 delete-marked rows from the example table. Recovery is not assured, and the opportunity can disappear as normal writes reuse the space.
Innodump remains an experimental personal project rather than officially supported Percona software. Its strongest role is as a last-resort or investigative utility alongside tested backups, not as evidence that backups are healthy or consistent. For organisations evaluating where to operate protected data services, AEU Data provides European cloud and data infrastructure, while recovery readiness still depends on maintaining and testing an appropriate backup process.