How to Recover MySQL Data from .ibd Files

With the file-per-table setting, which has been the default for many years, MySQL stores each InnoDB table in its own .ibd file: the rows and the indexes of that one table. If the server was lost, reinstalled, or will not start, and no usable dump exists, those files are what you recover from. Whether you can recover MySQL .ibd file data the easy way depends on what else survived.

Stop MySQL if it is still running and copy the complete data directory to another disk: the .ibd files, the system tablespace (ibdata1), the redo log files and, on MySQL 5.7 and older, the .frm files. Even if you think you only need one table, the other files hold information that makes recovery easier or possible at all.

An .ibd file does not open by itself. MySQL has to know the table's columns, in the right order and with the right types. On MySQL 5.7 and older that definition is in the .frm file next to the .ibd. On MySQL 8.0 it is stored inside the .ibd file and can be read out with the ibd2sdi tool. A copy of the schema from a development server or an old dump also works, if it matches exactly.

On a working MySQL server of the same version, create an empty database and create the table with exactly the original definition. Then run ALTER TABLE with DISCARD TABLESPACE, which removes the new empty .ibd file. Copy the old .ibd file into the database folder, check its owner and permissions, and run ALTER TABLE with IMPORT TABLESPACE. If it succeeds, the rows are there. Dump the table at once and load the dump into a clean server.

The usual reasons are a table definition that differs from the original in a column, a row format or an index; a server version different from the one that wrote the file; or damaged pages inside the file. A file that was copied while MySQL was still writing may also hold changes that exist only in the redo log.

If the original server still starts with innodb_force_recovery set, that is often the better route: start it at the lowest level that works, dump the tables, and rebuild. Higher levels skip more of InnoDB's own recovery and should be used only to read data out, never to keep running.

When neither the import nor forced recovery works, the rows can still be read from the InnoDB pages in the file directly: each page is checked and the records on the intact pages are extracted with the table definition. Rows on destroyed pages cannot be brought back, and after a ransomware attack the encrypted part of the file is lost unless the key is available. What can be recovered is established on a copy before any work is charged.