Recover MySQL Database from FRM and IBD Files: A DBA’s 2026 Guide (Every Version, Every Scenario)

What these files actually contain

Two engines, four extensions.

Engine	Schema	Data	Indexes
InnoDB (default since MySQL 5.5)	.frm (up to MySQL 5.7)	.ibd for file-per-table setups, or a shared ibdata1 file for the old system tablespace	.ibd
MyISAM	.frm	.myd	.myi

The version cliff that breaks most guides

In MySQL 8.0, Oracle removed .frm files. Table metadata now lives in a data dictionary inside InnoDB tablespaces, plus a Serialized Dictionary Information (SDI) block written directly inside every .ibd file. Per the MySQL 8.4 Reference Manual, .frm, .par, .TRG, .TRN, and .opt files no longer exist.

What that means in practice:

• If your dead server ran MySQL 5.7 or earlier (or any MariaDB), you have .frm files and you can use the classic DISCARD TABLESPACE / IMPORT TABLESPACE route below.
• If it ran MySQL 8.0 or later, there are no .frm files at all. You have .ibd files that contain their own schema (SDI) baked in, and you need ibd2sdi – not mysqlfrm.
• The mysqlfrm utility everyone links to is discontinued. It was part of MySQL Utilities, which Oracle abandoned. It still works on old .frm files if you can find it, but there’s a better tool: dbsake.

Check your version on any surviving files before you touch them: wrong tool, wrong version, dead data.

Before you touch anything: back up the corpse

Copy the entire data directory to a second location. Every recovery step below will fail on some tables, and you cannot go back if you’ve already overwritten the originals. Preserve file ownership (mysql:mysql) and permissions (660) when you copy — losing those will make MySQL refuse to read the files later.

Method 1: Manual recovery from FRM and IBD (MySQL 5.7 and MariaDB)

This is the classic five-stage flow. It works when the files are intact but the server no longer starts, or you’re transplanting tables from a dead instance.

Stage 1: Spin up a clean MySQL instance

Same major version as the source. Do not skip this. An .ibd file from 5.6 imported into 8.0 will corrupt on first read. Create an empty database on the fresh instance:

CREATE DATABASE recovered_db;

Stage 2: Extract the schema from the FRM file

You have two working options in 2026.

Option A: dbsake (recommended): It’s a single Python binary, actively used by the community, and works on Linux, macOS, and Windows via WSL:

curl -s http://get.dbsake.net > dbsake chmod u+x dbsake ./dbsake frmdump /path/to/table.frm

That prints the exact CREATE TABLE statement. For a whole directory:

for tbl in `ls -1 /path/to/*.frm`; do ./dbsake frmdump $tbl | mysql -u root -p recovered_db done

Option B: mysqlfrm (legacy): If you already have MySQL Utilities installed on an old machine:

mysqlfrm – – server=root:password@127.0.0.1 – – port=3307 /path/to/table.frm

The – – diagnostic flag reads the file byte-by-byte without needing a running server, but the output is less clean and misses collations on some column types.

Stage 3: Recreate each table on the new server

Run the CREATE TABLE statements from Stage 2 against recovered_db. This creates fresh .frm and .ibd files in the new data directory.

Stage 4: Discard the new tablespace

For each table:

ALTER TABLE table_name DISCARD TABLESPACE;

This deletes the empty .ibd file MySQL just created, leaving the table schema pointing at nothing.

Stage 5: Copy your original IBD file into place, then import

Copy the original .ibd from your backup into the new data directory:

cp /backup/table_name.ibd /var/lib/mysql/recovered_db/

chown mysql:mysql /var/lib/mysql/recovered_db/table_name.ibd chmod 660 /var/lib/mysql/recovered_db/table_name.ibd

Then import:

ALTER TABLE table_name IMPORT TABLESPACE;

If the schema matches exactly, the table becomes queryable. If MySQL throws Schema mismatch (Table has ROW_TYPE_DYNAMIC row format, … ) or a similar error, your CREATE TABLE doesn’t match what the .ibd was built with — go back to Stage 2 and look for ROW_FORMAT, character sets, or index differences.

Method 2: Recovery when there are no FRM files (MySQL 8.0+)

The .ibd file itself has the schema baked in as SDI. Extract it with ibd2sdi, which ships with MySQL 8.0:

ibd2sdi /path/to/table.ibd > table.json

The output is a JSON blob describing every column, index, foreign key, and property. It’s not a CREATE TABLE statement — you have to reconstruct one from the JSON. For a table with a few columns this takes minutes. For a table with 200 columns and 30 indexes, this is a full workday.

Once you have the CREATE TABLE, the rest of the flow is identical: recreate the table, DISCARD TABLESPACE, drop the original .ibd in place, IMPORT TABLESPACE.

Two catches worth knowing:

Catch	Why it Kills the Method
.ibd was created by a newer MySQL 8.x version than your recovery server	Import fails with tablespace version mismatch — no way around it
Source server used encrypted tablespaces	Import fails without the original keyring master key — no way to recover the key from just the files

Method 3: Recovery from MyISAM files (.myd and .myi)

MyISAM is dead but still shows up in legacy systems, older WordPress installs, and forum databases. Recovery is easier than InnoDB because there’s no tablespace binding.

Copy the .frm, .myd, and .myi files into /var/lib/mysql/dbname/, fix ownership to mysql:mysql, and start the server. If MySQL detects them, you’re done. If it complains that the table is marked as crashed, run:

myisamchk – – recover /var/lib/mysql/dbname/table.MYI

Or from inside MySQL:

REPAIR TABLE table_name;

If myisamchk returns errors about a corrupted index, add –safe-recover. If that fails too, the .myd file itself has damaged pages, and you’re at the same wall as a corrupted .ibd.

When manual recovery fails

The manual methods above assume the files are intact and only the server or its metadata is broken. Real disasters aren’t that clean. Every DBA has seen this list:

• .ibd file is truncated because the disk filled during a write.
• Server crashed mid-transaction, and pages in the .ibd are torn.
• Ransomware encrypted half the data directory before you killed it.
• The mysql system schema is gone, so grants and users are lost.
• You have .ibd files but no .frm files, and no idea what the tables were called.
• MySQL says InnoDB: Database page corruption on disk or a failed file read of page.
• The tables show up in SHOW TABLES, but SELECT returns Table ‘x’ doesn’t exist in engine.

At this point, IMPORT TABLESPACE will not work. ibd2sdi will refuse to open the file. dbsake will dump garbage. The files need forensic-level page reconstruction — reading the raw InnoDB page format, salvaging what rows are readable, rebuilding indexes from primary keys, stitching tables back together from clustered index leaves.
That is what Cigati MySQL Database Repair Tool does.

What Cigati MySQL Database Repair Tool handles

The tool is a Windows utility that reads corrupted MySQL files at the storage engine level, not through the MySQL server. It covers the cases where the manual flow above dies:

Problem Area	How Cigati Addresses It
Corrupted .ibd files (IMPORT TABLESPACE fails)	Scans page-by-page, extracts readable rows, reconstructs the table
Missing/damaged .frm files (MySQL 5.7 and below)	Infers schema from .ibd pages and primary key structure
MyISAM corruption (myisamchk – -safe-recover fails)	Recovers directly from .myd/.myi files
“Table doesn’t exist in engine” errors	Recovers tables despite this mismatch, common after abrupt shutdowns
Full data directory recovery	Single-pass recovery instead of repeating the manual flow per table
Restoring to a live server	Restores directly into MySQL without an intermediate SQL dump
Verifying recovered data before production	Can export to a SQL script for inspection first
Version/engine support	MySQL 5.5–8.4 and MariaDB; InnoDB and MyISAM

Limitations

It does not recover data from files the disk itself lost. If the underlying storage returned zeros or bad sectors ate the pages, no software can restore what isn’t there.

The Trial-First Workflow

The free demo does one thing: scans your files and shows you exactly what is recoverable, before you pay a rupee. If the preview shows all your tables, the paid version will save them. If the preview shows garbage, no license would have helped and you know it in ten minutes instead of three days.

Download the trial • Buy the full version

Errors this covers, indexed for search

Error String	Cause	Manual Fix	Cigati Tool?
Table ‘xxx’ is marked as crashed and should be repaired	MyISAM index corruption	REPAIR TABLE or myisamchk – – recover	Yes, when myisamchk – – safe-recover fails
InnoDB: Database page corruption on disk or a failed file read of page	Torn page in the .ibd	None reliable	Yes — page-level extraction
ERROR 1017 (HY000): Can’t find file: ‘table.frm’	File missing or wrong permissions	Restore file, chown mysql:mysql, chmod 660	Yes, when file is corrupt not missing
Incorrect information in file: ‘./dbname/table.frm’	.frm corrupted or wrong version	Try dbsake frmdump; if garbage, tool	Yes
Table ‘x’ doesn’t exist in engine	InnoDB dictionary and .ibd out of sync	Restore whole data directory to fresh install	Yes — reads files directly
Tablespace has been discarded for table ‘x’	You ran DISCARD but haven’t imported yet	Copy .ibd into place, IMPORT TABLESPACE	Not needed
Schema mismatch (Table has ROW_TYPE_DYNAMIC …)	Your CREATE TABLE doesn’t match the .ibd	Fix ROW_FORMAT, character set, indexes	Yes, when schema is unknown

What people actually go through a few recoveries in the wild

The manual method has saved a lot of people, and it has left a lot of people stuck. Some real cases from public forums:

Source	Scenario	Outcome
DBA Stack Exchange — Buttered_Toast (Rick James 81K rep, Bill Karwin 17K rep)	Lost every database and rebuilt from .frm and .ibd files using mysqlfrm	Tool discontinued. Both experts confirmed: on MySQL 8.0, the .frm route is dead. Backups are the only answer.
Microsoft Learn Q&A — Mehran Mahouti, 2021	Data center migration; raw .MYD/.MYI/.frm/.ibd files, no SQL dumps	Manual recovery worked — barely. Hours lost. His words: “I would love to have found this solution from the beginning.”
GitHub Gist — luqmansungkar (top reference since 2020)	Dozens of real recoveries across platforms and years	“Worked first try.” “Works on Windows.” “Works on Mac.” Also: “Three days of trying — you’re the only one who saved me.”

The pattern is consistent. The manual method works when the files are clean, and the version is right. It fails silently when they aren’t, and you don’t find out until three days of trying.

What Cigati customers report

Signal	Value
Rating	4.8 / 5
Reviews	1,256
Paid customers	10,000+
Third-party review platforms	Trustpilot, G2
Version	22.0
Size	1.8 MB

Named users on the product page:

• Robert Mitchell, Enterprise Database Consultant — recovered a corrupted database in one pass, no
  server performance impact.
• Kevin Brooks, Senior DBA — recovered damaged files, restored to a live SQL script with all schema
  elements intact.
• Marco Rossi, IT Operations Lead — repaired multiple enterprise client databases with tables,
  indexes, and triggers preserved.

Related

• MySQL Shutdown Unexpectedly
• MySQL is Marked as Crashed and Should be Repaired
• Quick Ways to Repair SQL Database Corruption

Related Post