The following procedure applies to standalone
instance version 5.3. For other MongoDB versions, refer to
the corresponding version of the manual.
Do not use this tutorial to recover a member of a replica set. Instead, you should either restore from a backup or resync from another member of the set, as described in Resync a Member of a Replica Set.
If you are running with journaling enabled, there is almost never any need to run repair since the server can use the journal files to restore the data files to a clean state automatically. However, you may need to run repair in cases where you need to recover from a disk-level data corruption.
Disk-level data corruption or missing data files can prevent
mongod instance from starting, and journal files may be
insufficient to recover automatically:
2018-10-24T18:05:18.248-04:00 W STORAGE [initandlisten] Detected unclean shutdown - mongod.lock is not empty. ... 2018-10-24T17:24:53.122-04:00 E STORAGE [initandlisten] Failed to get the cursor for uri: table:collection-2-6854866147293273505 2018-10-24T17:24:53.122-04:00 E STORAGE [initandlisten] This may be due to missing data files. ... ... ***aborting after fassert() failure
In such cases, your
dbPath contains a non-empty
The following procedure uses
mongod --repair to recover from
mongod --repair if you have no other options.
The operation removes and does not save any corrupt data during the
Starting in MongoDB 4.4, for the WiredTiger storage engine,
Rebuilds all indexes for collections with one or more inconsistent indexes.
Discards corrupt data.
Creates empty/stub files for missing data/metadata files.
Run the repair operation as the same user that normally runs the
mongod process to avoid changing the permissions of the
MongoDB data files.
Create a backup copy of the data files in the
If the repair fails to complete for any reason, you
must restart the instance with the
--repair option to complete the repair.
| Generally, you should not manually remove the
Instead, use the above procedure to recover the database. In dire
situations, you can remove the file, start the database using the
possibly corrupt files, and attempt to recover data from the
database. However, it is impossible to predict the state of the
database in these situations.