MongoDB Data Recovery
MongoDB stores data in BSON documents across WiredTiger collection files. Disk-level corruption or missing data files can keep mongod from starting. We image the failed drive using PC-3000, extract the WiredTiger files, rebuild the catalog metadata, and recover your collections. Standalone instances, replica sets, and sharded clusters. No data, no fee.
How We Recover a Corrupted MongoDB Database
We image the failed drive with PC-3000, then extract the WiredTiger .wt collection files, journal, & metadata. We rebuild the _mdb_catalog.wt, WiredTiger.wt, & WiredTiger.turtle, & replay journal & oplog writes after the last checkpoint. Recovered collections export as BSON. No data, no fee.
How WiredTiger Stores Data on Disk
WiredTiger is the default storage engine. Each collection is stored in a separate file (e.g., collection-0-123456789.wt), and each index gets its own file.
The _mdb_catalog.wt file maps collection names to their on-disk filenames. The WiredTiger.wt metadata file and WiredTiger.turtle bootstrap file track the current checkpoint state.
WiredTiger uses multiversion concurrency control (MVCC) and writes through a journal before checkpointing to collection files. A checkpoint occurs approximately every 60 seconds. Every change you make between checkpoints gets saved in WiredTiger's journal.
This architecture creates specific failure modes:
- Metadata loss: If
_mdb_catalog.wtis unreadable, MongoDB does not know which .wt file belongs to which collection. The data files are intact but unnamed. - Journal gaps: The journal directory contains incomplete or corrupted journal files. MongoDB cannot replay recent writes, leaving collections in a state up to 60 seconds behind.
- Collection file corruption: Bad sectors on the platter hit a .wt file. Individual documents within the B-tree pages become unreadable, but surrounding pages remain intact.
Why mongod --repair Is Dangerous on a Failing Drive
Starting in MongoDB 5.0, mongod --repair checks every collection & fixes whatever inconsistencies it can. It removes corrupt data. It doesn't save it anywhere.
On a drive with physical damage, --repair has two problems. First, it reads every collection on the drive. On a failing drive, every bad sector it hits makes the firmware retry the read. Those retries wear out weak heads & can score the platters.
Second, --repair writes back to the same drive, overwriting data that a proper imaging process could have recovered using PC-3000's adaptive read parameters.
MongoDB's own documentation warns you: "Only use mongod --repair if you have no other options." If the corruption came from physical media failure, fixing the drive first gets you a more complete dataset than --repair can pull off degraded media.
Before running --repair or deleting journal files: Power down the server. Don't restart mongod. Ship the drives to us for forensic imaging first.
Should You Resync a Replica Set Member Instead of Running --repair?
Yes, if another member of the set still has the data. MongoDB's mongod reference says to avoid running --repair against a replica set member. It tells you to restore from an intact copy instead, either a recent backup or an intact member of the set.
Their guide to recovering data after an unexpected shutdown says the same thing. Don't use it on a replica set member. Restore from a backup or resync from another member.
A Healthy Member Still Holds the Data
MongoDB's manual gives two ways to resync the broken member. You can restart mongod with an empty data directory & let initial sync rebuild it, or you can restart the machine with a copy of a recent data directory from another member.
In a logical initial sync, MongoDB clones every database except local. It builds each collection's indexes while it copies the documents, then applies the oplog records that piled up during the copy.
It also empties the member's data directory. MongoDB's warning reads: "During initial sync, mongod removes the contents of the dbPath directory." If that drive holds anything the healthy members don't, get it imaged before you start the sync.
A stale member needs a full resync too. Once the primary overwrites oplog entries the member never replicated, it can't catch up. MongoDB says you have to remove its data & perform an initial sync.
No Data-Bearing Member Survived
An arbiter won't save you. It votes in elections for primary, but MongoDB says it doesn't have a copy of the data set & can't become a primary. A set that's down to an arbiter & dead data-bearing members has nothing left to sync from.
If there's no backup either, both routes in MongoDB's manual are gone & your data only exists on the failed drives. Power the server down. We image each drive with PC-3000, then extract the WiredTiger files from the clone. No data, no fee.
Our MongoDB Recovery Workflow
Drive assessment and forensic imaging
Evaluate the drive using PC-3000 diagnostics. If the drive is mechanically sound, we image it. If heads have failed, we perform a head swap in the 0.02µm ULPA-filtered clean bench before imaging. The result is a complete sector-level clone on healthy media.
File system reconstruction and dbpath extraction
Mount the cloned image and extract the MongoDB data directory. If the file system (ext4, XFS, ZFS) is damaged, we parse the filesystem metadata directly to locate the WiredTiger files on disk. We recover the .wt collection files, the journal directory, and the WiredTiger metadata files.
WiredTiger metadata rebuild
Reconstruct _mdb_catalog.wt, WiredTiger.wt, and WiredTiger.turtle if damaged. Rebuild the checkpoint metadata so WiredTiger recognizes the data directory.
Oplog replay and collection validation
If journal files are intact, replay writes that occurred after the last checkpoint. For replica set members, the oplog (local.oplog.rs) can recover additional transactions. Validate each collection to identify documents with corrupted BSON structures.
BSON export and delivery
Export recovered collections using mongodump to produce BSON/JSON files, or provide a complete mongodump archive that can be restored with mongorestore. For GridFS recoveries, we also deliver reassembled original files alongside the database dump.
Common MongoDB Failure Scenarios
| Scenario | Symptoms | Recovery Approach |
|---|---|---|
| WT_PANIC | mongod crashes with "WT_PANIC: WiredTiger library panic" in the logs. The server refuses to restart. | Image the drive. Rebuild WiredTiger.turtle and WiredTiger.wt checkpoint metadata from the last valid checkpoint in the collection files. |
| Replica set rollback | A primary with acknowledged writes lost network connectivity and a new primary was elected. When the old primary reconnects, it rolls back writes to match the new primary. | Rolled-back documents are saved in the rollback/ directory as BSON files. We recover and merge these with the current dataset if the rollback directory was on the failed drive. |
| RAID array failure | Multiple drives in a RAID array failed. The MongoDB data directory spans a logical volume that is no longer mountable. | Image each member drive. Reconstruct the RAID stripe geometry and rebuild the virtual disk. Extract the file system and MongoDB data directory from the reconstructed array. |
Sharded Cluster Recovery
A sharded MongoDB deployment distributes data across multiple shard servers, each containing a subset of the documents determined by the shard key. The config servers store the chunk-to-shard mapping and cluster metadata. Mongos routers direct queries to the correct shard based on this mapping.
Recovering a sharded cluster requires three components: the data from each shard, the config server metadata, and knowledge of the shard key for each collection. The config database stores chunk boundaries in the config.chunks collection and shard membership in config.shards.
Config servers intact
When config server data is recoverable, the chunk-to-shard mapping is preserved. We image the failed shard drives, recover their collections, and the existing config metadata tells us exactly which documents belong where. Reassembly is straightforward.
GridFS File Recovery
GridFS is MongoDB's spec for storing files bigger than the 16 MiB BSON document limit. By default it cuts each file into 255 KiB chunks & saves each chunk as its own document in the fs.chunks collection. The file's name, length, chunk size & upload date go in fs.files.
When a drive fails, both collections may sustain damage. Missing chunks in the middle of a file produce a file with gaps. Missing metadata in fs.files means the chunks exist but we do not know what file they belong to.
Our recovery process handles both scenarios. We extract all documents from both collections, match chunks to files using the files_id field, and reassemble files in chunk order (the n field). For orphaned chunks without matching metadata, we identify the file type from the binary content and reconstruct the file entry.
Pricing
MongoDB recovery pricing is based on the physical condition of the drive. WiredTiger reconstruction, oplog replay, and BSON extraction are included at no additional charge. For RAID arrays or sharded clusters, each member drive is priced separately.
- Low complexity
Simple Copy
Your drive works, you just need the data moved off it
Functional drive; data transfer to new media
Rush available: +$100
$100
3-5 business days
- Low complexity
File System Recovery
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
From $250
2-4 weeks
- Medium complexity
Firmware Repair
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
CMR drive: $600. SMR drive: $900.
$600–$900
3-6 weeks
- High complexity
Head Swap
Bench diagnosis found the read/write heads have to be replaced. Clicking can also come from firmware, the preamp, or the spindle
Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench
50% deposit required. CMR: $1,200-$1,500 + donor. SMR: $1,500 + donor.
50% deposit required
$1,200–$1,500
4-8 weeks
- High complexity
Surface / Platter Damage
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.
50% deposit required
$2,000
4-8 weeks
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.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.
- Rush fee
- +$100 rush fee to move to the front of the queue
- Donor drives
- Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
- Target drive
- The destination drive we copy recovered data onto. You can supply your own, or we'll provide one. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. All prices are plus applicable tax.
Sealed helium drives are on their own price list, $200–$5,000+. When a head swap or platter repair opens one, we refill it with helium. That adds $400–$800, and the donor has to be an exact match. Helium drive prices
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 maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.
Localized Clean Zone
Open-drive work is performed in a 0.02 micron ULPA-filtered laminar clean bench.
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
Our engineers review all lab protocols to maintain 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 showing the bench rather than just describing it. Open-drive work runs on a 0.02 micron ULPA-filtered laminar clean bench, and we filmed it.
See the particle counter test at the benchMongoDB Recovery FAQ
Can you recover a MongoDB database from a physically failed drive?
What happens if WiredTiger journal files are missing?
Can you recover GridFS files from a corrupted MongoDB instance?
Should I run mongod --repair on a failing drive?
How is MongoDB recovery priced?
Since 2008
Established
As Featured In
Related services
Related Recovery Services
All supported database engines
InnoDB tablespace, ibdata1, redo log reconstruction
WAL reconstruction, pg_control repair, TOAST recovery
RAID 0, 1, 5, 6, 10 arrays
Synology, QNAP, TrueNAS, ASUSTOR
Dell, HP, IBM enterprise servers
Recover Your MongoDB Database
Call Mon-Fri 10am-6pm CT or email for a free drive evaluation.