Docs Menu

Docs HomeDevelop ApplicationsMongoDB Manual

Restore a Replica Set from MongoDB Backups

On this page

  • Restore Database into a Single Node Replica Set
  • Add Members to the Replica Set

This procedure outlines the process for taking MongoDB data and restoring that data into a new replica set. Use this approach for seeding test deployments from production backups or as part of disaster recovery.


You can also use mongorestore to restore database files using data created with mongodump. See Back Up and Restore with MongoDB Tools for more information.


The backup files may come from a file system snapshot. The MongoDB Cloud Manager produces MongoDB database files for stored snapshots and point in time snapshots. For Ops Manager, an on-premise solution available in MongoDB Enterprise Advanced, see also the Ops Manager Backup overview.

Considerations for Encrypted Storage Engines
For encrypted storage engines that use AES256-GCM encryption mode, AES256-GCM requires that every process use a unique counter block value with the key.For encrypted storage engine configured with AES256-GCM cipher:
  • Restoring from Hot Backup
    Starting in 4.2, if you restore from files taken via "hot" backup (i.e. the mongod is running), MongoDB can detect "dirty" keys on startup and automatically rollover the database key to avoid IV (Initialization Vector) reuse.
  • Restoring from Cold Backup

    However, if you restore from files taken via "cold" backup (i.e. the mongod is not running), MongoDB cannot detect "dirty" keys on startup, and reuse of IV voids confidentiality and integrity guarantees.

    Starting in 4.2, to avoid the reuse of the keys after restoring from a cold filesystem snapshot, MongoDB adds a new command-line option --eseDatabaseKeyRollover. When started with the --eseDatabaseKeyRollover option, the mongod instance rolls over the database keys configured with AES256-GCM cipher and exits.


  • In general, if using filesystem based backups for MongoDB Enterprise 4.2+, use the "hot" backup feature, if possible.

  • For MongoDB Enterprise versions 4.0 and earlier, if you use AES256-GCM encryption mode, do not make copies of your data files or restore from filesystem snapshots ("hot" or "cold").


If you are restoring from a filesystem backup (or any backup with the local database), drop the local database.

mongod --dbpath /data/db

Connect mongosh to the mongod instance and drop the local database.

use local

Shut down the standalone.


Start a mongod instance as a new single-node replica set. Specify the path to the backup data files with --dbpath option and the replica set name with the --replSet option. For config server replica set (CSRS), include the --configsvr option. Include any other options as appropriate for your deployment.


Starting in MongoDB 3.6, if your replica set members are run on different hosts or if you wish remote clients to connect to your instance, you must specify the net.bindIp setting (or --bind_ip).


Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.

mongod --dbpath /data/db --replSet <replName>


New in version 3.6:

All MongoDB collections have UUIDs by default. When MongoDB restores collections, the restored collections retain their original UUIDs. When restoring a collection where no UUID was present, MongoDB generates a UUID for the restored collection.

For more information on collection UUIDs, see Collections.


From the same machine where one of the mongod is running (in this tutorial,, start mongosh. To connect to the mongod listening to localhost on the default port of 27017, simply issue:


Depending on your path, you may need to specify the path to the mongosh binary.


Use rs.initiate() on one and only one member of the replica set:

rs.initiate( {
_id : <replName>,
members: [ { _id : 0, host : <host:port> } ]

MongoDB initiates a set that consists of the current member and that uses the default replica set configuration.

MongoDB provides two options for restoring secondary members of a replica set:


If your database is large, initial sync can take a long time to complete. For large databases, it might be preferable to copy the database files onto each host.

Use the following sequence of operations to "seed" additional members of the replica set with the restored data by copying MongoDB data files directly.


Use --shutdown or db.shutdownServer() to ensure a clean shut down.


Copy the primary's data directory into the dbPath of the other members of the replica set.


In a mongosh session that is connected to the primary, add the secondaries to the replica set using the rs.add() method. See Deploy a Replica Set for more information about deploying a replica set.

Use the following sequence of operations to "seed" additional members of the replica set with the restored data using the default initial sync operation.


For example, if the replica set member has a storage.dbPath or --dbpath of /data/db, you must ensure that directory exists and is empty.


Connect to the primary using the mongo shell and add each secondary to the replica set using rs.add().

When you add a member to the replica set, Initial Sync copies the data from the primary to the new member.

←  Back Up and Restore with MongoDB ToolsBackup and Restore Sharded Clusters →