MongoDB Documentation, Release 3.0.4 Step 7: Restore the config server data. For each config server, use mongorestore to restore the data dump to each config server’s data directory. Include the --drop option to drop the collections before restoring and, be- cause the backup procedure (page 258) included the --oplog option, include the --oplogReplay option for mongorestore . mongorestore --drop --oplogReplay /data/dump/configData Step 8: Start one mongos instance. Start one mongos instance. For the --configdb , specify the hostnames (and port numbers) of the config servers started in the step Deploy three new config servers. (page ?? ) Step 9: If shard hostnames have changed, update the config database. If shard hostnames have changed , update the shards (page 742) collection in the Config Database (page 737) to reflect the new hostnames. Step 10: Restart all the shard mongod instances. Step 11: Restart the other mongos instances. Restart the remaining two mongos instances. For the --configdb , specify the hostnames (and port numbers) of the config servers started in the step Deploy three new config servers. (page ?? ) Step 12: Verify that the cluster is operational. Connect to a mongos instance from a mongo shell and use the db.printShardingStatus() method to ensure that the cluster is operational, as follows: db.printShardingStatus() show collections MongoDB Backup Methods (page 184), Backup and Restore Sharded Clusters (page 254) See also: Recover Data after an Unexpected Shutdown If MongoDB does not shutdown cleanly 105 the on-disk representation of the data files will likely reflect an inconsistent state which could lead to data corruption. 106 To prevent data inconsistency and corruption, always shut down the database cleanly and use the durability journaling . MongoDB writes data to the journal, by default, every 100 milliseconds, such that MongoDB can always recover to a consistent state even in the case of an unclean shutdown due to power loss or other system failure. If you are not running as part of a replica set and do not have journaling enabled, use the following procedure to recover data that may be in an inconsistent state. If you are running as part of a replica set, you should always restore from a backup or restart the mongod instance with an empty dbPath and allow MongoDB to perform an initial sync to restore the data. The Administration (page 183) documents, including Replica Set Syncing (page 593), and the documentation on the --repair repairPath and storage.journal.enabled settings. See also: 105 To ensure a clean shut down, use the db.shutdownServer() from the mongo shell, your control script, the mongod --shutdown option on Linux systems, “Control-C” when running mongod in interactive mode, or kill $(pidof mongod) or kill -2 $(pidof mongod) . 106 You can also use the db.collection.validate() method to test the integrity of a single collection. However, this process is time consuming, and without journaling you can safely assume that the data is in an invalid state and you should either run the repair operation or resync from an intact member of the replica set. 263 5.2. Administration Tutorials