Recover a Corrupted MySQL, PostgreSQL or MongoDB Database in 2026: Step-by-Step Procedures

Database recovery is one of the hardest parts of data recovery. With a single file, the stake is binary: you get it back or you do not. A database is different. A corrupted database can look fine at startup, yet hide silent flaws - out-of-sync indexes, broken constraints, half-applied transactions. These flaws often surface weeks later as app errors or wrong financial accounts. This article covers the full MySQL, PostgreSQL, and MongoDB recovery steps. It lists native tools, third-party tools, what to expect, and when to send the job to a professional lab.

Three DBMSs lead the consumer and SMB open-source space in 2026. They are MySQL/MariaDB, PostgreSQL (still growing), and MongoDB (the top NoSQL document store). Each uses a very different storage design. InnoDB has its .ibd files. PostgreSQL has its base/ with separate WALs. MongoDB has its WiredTiger engine with .wt collections. So each one needs its own recovery steps. No general file recovery tool (EaseUS, PhotoRec, Recuva) is enough here.

Transparent affiliation. Save My Disk earns a commission if you purchase a license through the EaseUS links in this article. EaseUS only intervenes at the filesystem level - for the recovery of .ibd, base/, .wt files hosting the database. For transactional recovery itself (innodb_force_recovery, pg_resetwal, mongod --repair), we cite exclusively native DBMS tools or Stellar Repair per our public methodology.

MySQL and MariaDB: innodb_force_recovery and forensic mysqldump

The InnoDB storage engine of MySQL 8.0.x and MariaDB 11.x stores data in .ibd files, one per table. This file-per-table layout is the default since MySQL 5.6. The data can also sit in a shared ibdata1 tablespace. Indexes, foreign key constraints, and triggers live in .frm (up to MySQL 5.7) or in the InnoDB dictionary (since MySQL 8.0). The binary log (binlog) tracks all changes for replication and point-in-time recovery.

Typical InnoDB corruption shows up as a startup crash. The error.log holds a message like InnoDB: Database page corruption on disk, or a failed file read of page X. The standard fix uses the innodb_force_recovery parameter. It takes whole-number values from 0 (normal mode) to 6 (full forensic mode). Each step up turns off one protection:

• 1 disables corrupted page checks (minimal loss)
• 2 disables purge thread (may leave zombie transactions)
• 3 disables transaction rollback (partial changes persist)
• 4 disables insert buffer merge (index inconsistencies)
• 5 disables redo log (loss of non-checkpoint transactions)
• 6 disables crash recovery at startup (severe corruption ignored)

Levels 1 to 3 fix the large majority of cases. Level 1 alone covers many. Beyond level 3, export at once via mysqldump --all-databases --routines --triggers --single-transaction. That is the only safe path - any further write risks permanent corruption.

The tool Stellar Repair for MySQL 7 (released March 2026, $299) does offline forensic analysis of .ibd files. It backs up innodb_force_recovery for cases where the server no longer starts at all. It gets back a large share of rows on corrupted .ibd files when the page header is intact.

PostgreSQL: pg_resetwal, point-in-time recovery, and standby

PostgreSQL 16.x released September 2023 stores its data in a data/base/<dbOID>/ tree, with one file per table named by OID. Write-Ahead Logs (WAL) in pg_wal/ track each change before commit and enable point-in-time recovery (PITR). A regular checkpoint empties old WALs and syncs data files.

PostgreSQL corruption takes three main forms. First scenario: a crash during a write that leaves an incomplete WAL. At restart, PostgreSQL replays the WAL and finds a clean state. In most cases you do not need to act by hand - PostgreSQL's automatic WAL replay handles it.

Second scenario: corruption of a table page, shown by the message PANIC: corrupted item pointer. Set zero_damaged_pages = on in postgresql.conf at startup. This marks corrupted pages as empty rather than stopping. Data on these pages is lost - the option only lets you start up to export the rest.

Third scenario: the server cannot start even with zero_damaged_pages. This is where pg_resetwal comes in. The postgresql.org docs are clear: pg_resetwal is a last-resort step. It may cause loss of non-checkpoint data and broken state. Run it on a COPY of the data directory, never on production.

Some PostgreSQL setups run a streaming replication standby. This setup is advised in production since PostgreSQL 12. With it, recovery is easy: promote the standby to primary via pg_ctl promote, then rebuild a new standby from the new primary. No pg_resetwal needed, no data loss. This is why most PostgreSQL incidents in well-built production setups resolve without any forensic recovery.

MongoDB WiredTiger: --repair, replica set, and collection dumping

MongoDB 7.0 released August 2023 uses only the WiredTiger storage engine. The old MMAPv1 engine was removed since MongoDB 4.2. Collections are stored in .wt files, one per collection, with a separate WiredTiger journal for durability. Replica sets copy data on at least 3 nodes, with an oplog to keep them in sync.

WiredTiger corruption usually shows up as a mongod startup crash. The message reads WT_PANIC: WiredTiger library panic or Detected unclean shutdown - this should only occur if the storage volume was corrupted. The --repair step runs three jobs: it checks each WiredTiger page, rebuilds indexes, and purges corrupted documents.

mongod --repair --dbpath /var/lib/mongodb

This step can take from 20 minutes for a 50 GB base to several hours for a multi-TB base. The MongoDB Manual Repair docs state that --repair can permanently delete documents. So the full dbpath copy is a must before launch.

For replica sets, the plan changes a lot. First, remove the corrupted primary from the set (rs.remove("primary:27017")). Then promote a healthy secondary; rs.stepDown() on the bad primary forces an election. Last, rebuild the corrupted node via initial sync. This way avoids --repair and keeps the ACID transactional state of the replica set.

Third-party tool comparison for corrupted databases

When native tools (innodb_force_recovery, pg_resetwal, --repair) are not enough, several third-party tools step in. Here are the four main ones.

For PostgreSQL, no paid third-party tool matches the native tools (pg_resetwal, pg_filedump, pg_dirtyread). Skilled PostgreSQL admins work only with these tools plus a solid streaming replication plan.

Professional lab: orientation thresholds and 2026 costs

Four cases call for a specialized database lab rather than a do-it-yourself try. First: Transparent Data Encryption (TDE) MS SQL Server with lost OEM keys. Second: Oracle Database with corrupted ASM, which needs a certified Oracle DBA. Third: a Cassandra or ScyllaDB multi-region cluster with Merkle tree corruption. Fourth: a failed physical volume that blocks software cloning of the data directory. In that last case, send it to a hardware lab for SSD/HDD/NVMe recovery before any DBMS step.

Specialized database labs in 2026 include Ontrack Database Recovery Services (USA, UK, Germany), DriveSavers Database Specialist Team (USA), Stellar Data Recovery Database Services (India, global presence), Recoveo Database (Poland), and Kroll Ontrack Forensics Database (legal forensic). Public prices seen in May 2026:

• MySQL or PostgreSQL consumer / SMB: 1,200 to 3,500 € (flat-rate diagnosis + recovery + restoration)
• MongoDB WiredTiger replica set: 3,500 to 9,000 € (depending on volume and number of shards)
• MS SQL Server enterprise: 5,500 to 16,000 € (corrupted MDF/LDF, TDE active)
• Oracle Database enterprise: 9,000 to 28,000 € (ASM, RAC, RMAN forensic)
• Cassandra / ScyllaDB cluster: 8,000 to 22,000 € (Merkle tree reconstruction, multi-region)

See our BitLocker guide for Microsoft OEM key encryption specifics. For NAS hosting corrupted dockerized databases, consult our RAID recovery guide.

2026 prevention strategy: the only real line of defense

The large majority of database recovery cases would have been avoided, or solved in under 30 minutes, with three practices in place. First: a daily logical backup (mysqldump, pg_dump, mongodump) on remote storage, tested by a monthly restore. Second: an hourly physical backup (Percona XtraBackup, pg_basebackup, MongoDB Cloud Backup) with a ZFS or Btrfs snapshot of the data directory. Third: streaming replication or a replica set with at least 2 secondary nodes on separate storage.

On a tight budget, the bare minimum is still a daily mysqldump/pg_dump/mongodump to encrypted S3 storage, plus a monthly restore test on a staging instance. This plan is enough to turn a major incident into a simple 2-hour delay.

FAQ - Frequently asked questions on database recovery

MySQL InnoDB won't start: which innodb_force_recovery to use?

Always innodb_force_recovery=1 first. Levels 1 to 3 suffice in the large majority of cases. Beyond 4, export immediately via mysqldump --all-databases without writing.

PostgreSQL won't start after crash: is pg_resetwal the solution?

Not as a first resort. pg_resetwal may cause loss of committed data. First, test pg_basebackup from a standby, check WAL archives, and explore physical backups. If you cannot avoid it, run it on a COPY, never on prod.

Does MongoDB --repair work on WiredTiger 7.0.x?

Yes, but with limits. It can permanently delete collections it cannot reach, so back up dbpath fully first. For replica sets, it is safer to stop the corrupted primary and restore from a healthy secondary via initial sync.

Database recovery vs classic filesystem recovery difference?

Three differences: (1) internal indexes, constraints, triggers that only DBMS tools reconstruct; (2) versioned proprietary binary formats (.ibd, .wt, base/); (3) ACID transactions requiring intact binlog, WAL, oplog.

How much does pro database recovery cost in 2026?

MySQL/PostgreSQL consumer: 1,200-3,500 €. MongoDB WiredTiger: 3,500-9,000 €. MS SQL Server: 5,500-16,000 €. Oracle enterprise: 9,000-28,000 €. Cassandra cluster: 8,000-22,000 €. Third-party tools: Stellar $299-599, EaseUS MS SQL $299.

Verdict: transactional prevention, forensic recovery second

Database recovery in 2026 stays lopsided. Prevention (tested backups + replication standby + active monitoring) costs a small slice of DBA time and solves the vast majority of incidents in minutes. Forensic recovery with no prevention costs between 1,200 € and 28,000 €, based on DBMS and how hard the case is.

For MySQL and MariaDB, one combo covers the vast majority of cases: Percona XtraBackup daily + binlog on + mysqldump --single-transaction weekly. For PostgreSQL, the 2026 gold standard is streaming replication with 1 synchronous standby and 1 asynchronous standby + weekly pg_basebackup. For MongoDB, you must run a replica set with at least 3 nodes, daily mongodump backups, and monthly MongoDB Cloud Backup.

When recovery cannot be avoided, the rule is one line: always work on a copy of the data directory, never on source production. This simple step is what splits a clean recovery from total loss. A correct clone keeps the data safe. Running the steps right on corrupted prod risks losing it all.

Related guides

• Recover files on Linux (ext4, Btrfs, XFS, ZFS)
• Enterprise data recovery with SOC 2 compliance