This version will reach end of life on Feb 2018. To upgrade, go to the Learn more about upgrading your version of MongoDB.

Recover a Standalone after an Unexpected Shutdown

When a standalone mongod instance has journaling disabled [1], an unclean shutdown may leave the data in an inconsistent state. Following an unclean shutdown, if a non-empty mongod.lock file exists, mongod instance logs the following message upon restart:

Detected unclean shutdown - mongod.lock is not empty.

If your dbPath contains a non-empty mongod.lock file, you must repair the database. This tutorial outlines the procedure to repair your database for a standalone mongod.


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.

[1]By default, MongoDB runs with journaling enabled to prevent data inconsistency in the event of an unclean shutdown. To shut down cleanly, see Stop mongod Processes.



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 of the data files.

Create a backup copy of the data files in the --dbpath.


Start mongod with --repair.

To repair the data files, start the mongod instance with the --repair option. By default, during the repair operation, MongoDB uses a _tmp directory in the --dbpath.

If the mongod instance uses MMAPv1 Storage Engine, you can include the --repairpath option to specify an alternate temporary directory. For details, see --repairpath.

Issue a command similar to the following:

mongod --dbpath /data/db --repair

Upon completion, the dbpath should contain the repaired data files and an empty mongod.lock file. [2]

[2](1, 2) Generally, you should not manually remove the mongod.lock file. 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.