On this page


db.repairDatabase() provides a wrapper around the database command repairDatabase, and has the same effect as the run-time option mongod --repair option, limited to only the current database. See repairDatabase for full documentation.



  • Before using repairDatabase, make a backup copy of the dbpath directory.
  • Avoid running repairDatabase against a replica set. If you are trying to repair a replica set member, and you have access to an intact copy of your data (e.g. a recent backup or an intact member of the replica set), you should restore from that intact copy (see Resync a Member of a Replica Set), and not use repairDatabase.
  • Only use the repairDatabase command and associated wrappers, including db.repairDatabase() and mongod --repair, if you have no other options. These operations remove and do not save any corrupt data during the repair process.

If you are running with journaling enabled, there is almost never any need to run repairDatabase unless you need to recover from a disk-level data corruption. In the event of an unclean shutdown, the server will be able to restore the data files to a clean state automatically.

Changed in version 2.6: The db.repairDatabase() is now available for secondary as well as primary members of replica sets.