MySQL Data Recovery

MySQL recovery starts with the physical drive. When the disk holding your InnoDB tablespace has failed, mysqld cannot start and innodb_force_recovery cannot read what the OS cannot deliver. We image the failed drive using PC-3000, extract ibdata1 and the per-table .ibd files, reconstruct the data dictionary, and export your tables. MySQL 5.0 through 8.x, MariaDB 10.x. No data, no fee.

Start a Recovery All Database Services

No Data = No Charge

InnoDB + MyISAM Recovery

PC-3000 + Tablespace Repair

Nationwide Mail-In

Written by

Louis Rossmann

Founder & Chief Technician

Updated March 2026

InnoDB Tablespace Architecture and What Breaks

A MySQL InnoDB installation stores data across several file types. The shared system tablespace (ibdata1) holds the data dictionary, undo logs, the change buffer, and the doublewrite buffer. When innodb_file_per_table is enabled (the default since MySQL 5.6), each table also gets its own .ibd file containing the table's clustered index and secondary indexes. The redo logs (ib_logfile0, ib_logfile1) record every write operation for crash recovery.

InnoDB organizes all data into 16KB pages (twice the size of SQL Server's 8KB pages). Each page has a 38-byte FIL header containing the page type, tablespace ID, page number, and FIL_PAGE_LSN (log sequence number). The page footer stores a checksum calculated using one of three algorithms: crc32 (default in 5.7+), innodb (legacy), or none. MySQL verifies this checksum on every read. A single corrupt byte in the FIL header causes InnoDB to reject the entire 16KB page.

Common corruption patterns from drive failures:

Torn pages: The drive lost power during a 16KB write. The page contains a mix of old and new data. InnoDB's doublewrite buffer exists to detect this, but if the doublewrite buffer itself is damaged (it lives in ibdata1), the torn page goes undetected until a read triggers a checksum failure.
ibdata1 data dictionary corruption: The data dictionary maps every table name to its tablespace ID and .ibd file. When ibdata1 is damaged in the dictionary region, MySQL reports "Table doesn't exist in engine" for tables whose .ibd files are physically intact on disk. Dropping and recreating the table destroys the .ibd file.
Redo log corruption: InnoDB refuses to start with "log sequence number is in the future" or "log sequence number X is not in the future." The redo logs (ib_logfile0/1) contain write records that InnoDB replays on startup. Damaged redo logs prevent crash recovery from completing.
.frm file loss (MySQL 5.7 and earlier): Table definitions lived in individual .frm files in the filesystem. If the directory was on the same failing drive, the .frm files may be unrecoverable even when the .ibd data files are intact. Without the .frm, MySQL cannot open the table.

MySQL Error Codes We Handle

Error	Meaning	Typical Cause
InnoDB assertion failure	Internal consistency check failed. mysqld crashes and writes a stack trace to the error log.	Corrupted page header, invalid pointer in B-tree node, damaged undo log segment. Often caused by bad sectors in the ibdata1 region.
Error 1146 with existing .ibd	"Table 'db.table' doesn't exist" even though the .ibd file is present on disk.	Data dictionary entry in ibdata1 is damaged or missing. The tablespace ID in the .ibd header no longer matches what the dictionary expects.
Tablespace N not found	"InnoDB: Tablespace N was not found at expected path." MySQL knows the table exists but cannot locate its file.	.ibd file was moved, deleted, or the filesystem is too damaged for the OS to resolve the path. Also occurs after failed `ALTER TABLE ... DISCARD TABLESPACE` operations.
Log sequence number in the future	InnoDB's redo log contains an LSN that exceeds the data file's recorded LSN. Startup aborts.	Redo log files (ib_logfile0/1) are from a newer state than the data files. Caused by restoring data files without matching redo logs, or partial drive recovery that retrieved old data pages but current logs.
Page checksum mismatch	InnoDB reads a 16KB page and the stored checksum does not match the computed value. The page is flagged as corrupt.	Bad sectors on the platter returned incorrect bytes. SSD firmware bug caused a silent bit flip. Power loss during a write (torn page) without doublewrite protection.

innodb_force_recovery: What Each Level Does

MySQL's innodb_force_recovery setting tells InnoDB to skip certain startup operations. Levels 1 through 3 are read-side adjustments. Levels 4 through 6 skip write operations that protect data integrity.

Level	What It Skips	Risk
1 (SRV_FORCE_IGNORE_CORRUPT)	Ignores corrupt pages during reads instead of crashing.	Low. Queries return partial results if pages are damaged, but no data is modified.
2 (SRV_FORCE_NO_BACKGROUND)	Prevents the master thread and purge threads from running.	Low. Stops background cleanup. No data loss.
3 (SRV_FORCE_NO_TRX_UNDO)	Skips transaction rollback after crash recovery.	Medium. Uncommitted transactions remain in the data. Tables may contain partial writes.
4 (SRV_FORCE_NO_IBUF_MERGE)	Skips change buffer (insert buffer) merge operations.	High. Secondary indexes may be stale or missing entries. Data reads from the clustered index are unaffected.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)	Skips undo log processing entirely.	High. InnoDB treats all transactions as committed. Ghost rows from aborted transactions may appear in query results.
6 (SRV_FORCE_NO_LOG_REDO)	Skips redo log replay. InnoDB opens data files as-is.	Critical. Any writes that were in the redo log but not yet flushed to data pages are lost. The database state is whatever the data files contained at the last checkpoint.

Before setting innodb_force_recovery: If the drive is making abnormal sounds (clicking, grinding, beeping) or the OS reports I/O errors, the problem is physical. Running mysqld on a failing drive writes redo log entries to the same degrading media. Each write cycle risks overwriting recoverable data. Power down the server and contact us for a free drive evaluation.

Our MySQL Recovery Workflow

Drive assessment and forensic imaging

Evaluate the drive using PC-3000 diagnostics. If mechanically sound, image with write-blocking hardware. If heads are failed, perform a donor head swap in the 0.02µm ULPA-filtered clean bench before imaging. The goal is a complete sector-level clone on a healthy drive.

Tablespace extraction from the image

Mount the cloned image and locate the MySQL data directory. Extract ibdata1, all .ibd files, redo logs (ib_logfile0/1), and .frm files (MySQL 5.7 and earlier). If the filesystem (ext4, XFS) is damaged, parse the filesystem journal and inode tables directly to locate file extents on disk.

Data dictionary and page integrity scan

Scan every 16KB page in ibdata1 and each .ibd file. Validate FIL headers, checksums (crc32/innodb), and LSN chains. Check the data dictionary pages in ibdata1 to verify that every table definition maps to a valid .ibd file. Build a map of healthy pages, repairable pages, and unrecoverable pages.

Data dictionary repair and redo log stub creation

Rebuild damaged data dictionary entries by cross-referencing .ibd file headers (which contain tablespace IDs and SDI records in MySQL 8.0+). Recalculate page checksums. If redo logs are corrupt or mismatched, create minimal redo log stubs so InnoDB can start without replaying invalid log entries.

Per-table export and validation

Start MySQL with the repaired tablespace in a sandboxed instance. Export each table using mysqldump or SELECT INTO OUTFILE to produce clean SQL dump files. Run CHECK TABLE against each recovered table. Deliver the dump files, the raw .ibd files, or both, depending on your deployment target.

Delivery and import verification

Provide recovery results on an encrypted external drive or secure download. Include row counts per table so you can verify completeness against your last known backup. For RAID arrays, we rebuild the virtual disk from member drives before extracting the MySQL data directory.

MyISAM vs. InnoDB Recovery

Most MySQL databases deployed after 2010 use InnoDB as the default storage engine. Legacy applications, some WordPress installations, and older custom systems still use MyISAM tables. The two engines store data differently, and the recovery approach for each is distinct.

Property	InnoDB	MyISAM
Files per table	.ibd (data + indexes) + shared ibdata1	.frm (definition) + .MYD (data) + .MYI (indexes)
Page size	16KB (configurable: 4K-64K)	No page structure; variable-length rows in a flat file
Transaction log	Redo logs (ib_logfile0/1) + undo logs in ibdata1	None
Crash recovery	Automatic via redo/undo replay	None; requires `myisamchk`
Recovery complexity	High: data dictionary, B-tree traversal, checksum repair	Lower: sequential row parsing, index rebuild from .MYD

For MyISAM tables on a failed hard drive, we image the drive, extract the .MYD data files, and parse rows directly. The .MYI index file can be rebuilt from the data using myisamchk -r. If .frm files are lost, we reconstruct table definitions from the .MYD row format and any available application schema files (Django models.py, Rails schema.rb, etc.).

MySQL 5.7 vs. 8.0: Recovery Differences

MySQL 8.0 introduced a transactional data dictionary stored inside InnoDB itself (the mysql.ibd tablespace), replacing the filesystem- based .frm, .par, .TRG, and .TRN files used in 5.7 and earlier. This architectural change has direct implications for recovery.

MySQL 5.7 and earlier: Table definitions are stored in .frm files on the filesystem, separate from InnoDB data files. If the .frm files are lost but the .ibd files survive, we can still extract raw row data by parsing the InnoDB page format and reconstructing the column layout from the data pages. This is slower than having the .frm, but the data is recoverable.

MySQL 8.0+: All table metadata lives in mysql.ibd and ibdata1. There are no .frm files to lose, but corruption in mysql.ibd can destroy table definitions for the entire server. The SDI (Serialized Dictionary Information) records stored in each .ibd file provide a fallback; we extract SDI from individual .ibd headers to rebuild the data dictionary when mysql.ibd is unrecoverable.

MariaDB 10.x: MariaDB retained the .frm-based data dictionary and did not adopt MySQL 8.0's InnoDB data dictionary. Recovery of MariaDB 10.x follows the MySQL 5.7 approach. The Aria storage engine (.MAI/.MAD files), used for internal temporary tables and optionally for user tables, uses a page-based format with crash-safe write-ahead logging. We parse Aria files using the same page-scanning techniques as InnoDB.

Pricing

MySQL recovery pricing is based on the physical condition of the drive. InnoDB tablespace repair, data dictionary reconstruction, and redo log rebuilding are included at no additional charge. For RAID arrays, each member drive is priced separately.

Service Tier	Price	Description
Simple CopyLow complexity	$100	Your drive works, you just need the data moved off it Functional drive; data transfer to new media Rush available: +$100
File System RecoveryLow complexity	From $250	Your drive isn't recognized by your computer, but it's not making unusual sounds File system corruption. Accessible with professional recovery software but not by the OS Starting price; final depends on complexity
Firmware RepairMedium complexity – PC-3000 required	$600–$900	Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access Standard drives at lower end; high-density drives at higher end
Head SwapHigh complexity – clean bench surgery50% deposit	$1,200–$1,500	Your drive is clicking, beeping, or won't spin. The internal read/write heads have failed Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench 50% deposit required. Donor parts are consumed in the repair
Surface / Platter DamageHigh complexity – clean bench surgery50% deposit	$2,000	Your drive was dropped, has visible damage, or a head crash scraped the platters Platter scoring or contamination. Requires platter cleaning and head swap 50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.

Hardware Repair vs. Software Locks

Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.

All tiers: Free evaluation and firm quote before any paid work. No data, no fee on simple copy, file system, and firmware tiers. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.

Target drive: The destination drive we copy recovered data onto. You can supply your own or we provide one at cost. For ultra-high-capacity drives (20TB and above), the target drive costs approximately $400+ due to the large media required. All prices are plus applicable tax.

No Data, No Fee

Guarantee

2.49M+

Subscribers

4.9

1,837+ Google Reviews

Since 2008

Established

Repairs on Video

Full Transparency

As Featured In

Data Recovery Standards & Verification

Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to make sure your hard drive is handled safely and properly. This approach allows us to serve clients nationwide with consistent technical standards.

Validated Clean Zone

Open-drive work is performed in a ULPA-filtered laminar-flow bench, validated to 0.02 µm particle count, verified using TSI P-Trak instrumentation.

Transparent History

Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.

Media Coverage

Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.

Aligned Incentives

Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.

Technical Oversight

Louis Rossmann

Louis Rossmann's well trained staff review our lab protocols to ensure technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.

We believe in proving standards rather than just stating them. We use TSI P-Trak instrumentation to verify that clean-air benchmarks are met before any drive is opened.

See our clean bench validation data and particle test video

MySQL Recovery FAQ

Can you recover data when ibdata1 is corrupted but .ibd files are intact?

Yes. The ibdata1 shared tablespace contains the InnoDB data dictionary, which maps table definitions to individual .ibd files. When ibdata1 is damaged, MySQL cannot read any table even if the per-table .ibd files are physically intact. We reconstruct the data dictionary entries from the .ibd file headers and internal SDI records, then rebuild a minimal ibdata1 that allows MySQL to recognize the tables.

Should I use innodb_force_recovery to bring my database back online?

Levels 1 through 3 are diagnostic modes that prevent background operations without modifying data. Level 4 and above skip undo log processing, purge threads, and change buffer merges. These levels discard uncommitted transaction rollbacks and can leave tables in an inconsistent state. If the underlying drive is failing, running MySQL at any force_recovery level writes to redo logs and potentially corrupts additional pages. Power down the server and image the drive first.

Is MyISAM recovery different from InnoDB?

MyISAM stores each table as three files: .frm (definition), .MYD (data), and .MYI (indexes). The .MYD file is a flat row store with no page structure or transaction log. This makes raw data extraction simpler than InnoDB, but MyISAM has no crash recovery mechanism. If the drive failed mid-write, partial rows may be present. We parse the .MYD directly and rebuild the .MYI index from the recovered data.

Do you recover MariaDB databases as well?

Yes. MariaDB 10.x uses InnoDB with a compatible on-disk format through the 10.x series. The Aria storage engine (.MAI/.MAD files), which is MariaDB-specific, uses a page structure similar to MyISAM with added crash safety. We handle both engines. MariaDB 11.x introduced format changes that we evaluate on a case-by-case basis.

Do you support MySQL 5.7, 8.0, and older versions?

We recover MySQL databases from version 5.0 through 8.x. The key difference affecting recovery is that MySQL 8.0 moved the data dictionary from external .frm files into InnoDB internal tables (the mysql.ibd tablespace). For 5.7 and earlier, we need the .frm files to reconstruct table definitions. For 8.0+, the definitions live inside InnoDB itself, so ibdata1/mysql.ibd integrity is more critical.

How is MySQL recovery priced?

Pricing is based on the physical condition of the drive. File system corruption: from $250. Firmware repair: $600-$900. Head swap: $1,200-$1,500. InnoDB tablespace repair and data dictionary reconstruction are included at no additional cost. No data, no fee.