Restore a Replica Set from MongoDB Backups

This procedure outlines the process for taking MongoDB data andrestoring that data into a new replica set. Use this approachfor seeding test deployments from production backups or as partof disaster recovery.

Important

You cannot restore a single data set to three new mongodinstances and then create a replica set. If you copy the data setto each mongod instance and then create the replica set,MongoDB will force the secondaries to perform an initialsync. The procedures in this document describe the correct andefficient ways to deploy a restored replica set.

You can also use mongorestore to restore database filesusing data created with mongodump. SeeBack Up and Restore with MongoDB Tools for more information.

Restore Database into a Single Node Replica Set

Obtain backup MongoDB Database files.

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

  • Considerations for Encrypted Storage Engines
  • For encrypted storage engines thatuse AES256-GCM encryption mode, AES256-GCM requires that everyprocess use a unique counter block value with the key.

For encrypted storage engineconfigured 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), MongoDBcan detect “dirty” keys on startup and automatically rolloverthe 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), MongoDBcannot detect “dirty” keys on startup, and reuse of IV voidsconfidentiality and integrity guarantees.

Starting in 4.2, to avoid the reuse of the keys afterrestoring from a cold filesystem snapshot, MongoDB adds a newcommand-line option —eseDatabaseKeyRollover. When started with the—eseDatabaseKeyRollover option, the mongodinstance rolls over the database keys configured withAES256-GCM cipher and exits.

Tip

  • In general, if using filesystem based backups for MongoDBEnterprise 4.2+, use the “hot” backup feature, if possible.
  • For MongoDB Enterprise versions 4.0 and earlier, if you useAES256-GCM encryption mode, do not make copies ofyour data files or restore from filesystem snapshots (“hot” or“cold”).

Drop the local database if it exists in the backup.

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

Start a standalone mongod using the data files from the backup as the data path.

  1. mongod --dbpath /data/db

Drop the local database.

Connect mongo shell to the mongodinstance and drop the local database.

  1. use local
  2. db.dropDatabase()

Shut down the standalone.

Start a new single-node replica set.

Start a mongod instance as a new single-node replica set.Specify the path to the backup data files with —dbpath optionand 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.

Note

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

Warning

Before binding to a non-localhost (e.g. publicly accessible)IP address, ensure you have secured your cluster from unauthorizedaccess. For a complete list of security recommendations, seeSecurity Checklist. At minimum, considerenabling authentication andhardening network infrastructure.

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

Note

New in version 3.6:

All MongoDB collections haveUUIDs by default. WhenMongoDB restores collections, the restored collections retain theiroriginal UUIDs. When restoring a collection where no UUID waspresent, MongoDB generates a UUID for the restored collection.

For more information on collection UUIDs, seeCollections.

Connect a mongo shell to the mongod instance.

From the same machine where one of the mongod is running(in this tutorial, mongodb0.example.net), start the mongoshell. To connect to the mongod listening to localhost onthe default port of 27017, simply issue:

  1. mongo

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

Initiate the new replica set.

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

  1. rs.initiate( {
  2.    _id : <replName>,
  3.    members: [ { _id : 0, host : <host:port> } ]
  4. })

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

Add Members to the Replica Set

MongoDB provides two options for restoring secondary members of areplica set:

Note

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

Copy Database Files and Restart mongod Instance

Use the following sequence of operations to “seed” additional membersof the replica set with the restored data by copying MongoDB datafiles directly.

Shut down the mongod instance that you restored.

Use —shutdown ordb.shutdownServer() to ensure a clean shut down.

Copy the primary’s data directory to each secondary.

Copy the primary’s data directory into thedbPath of the other members of the replica set. ThedbPath is /data/db by default.

Start the mongod instance that you restored.

Add the secondaries to the replica set.

In a mongo shell connected to the primary, add thesecondaries to the replica set usingrs.add(). See Deploy a Replica Set for moreinformation about deploying a replica set.

Update Secondaries using Initial Sync

Use the following sequence of operations to “seed” additional membersof the replica set with the restored data using the default initialsync operation.

Empty the data directory for each prospective replica set member.

For example, if the replica set member has astorage.dbPath or —dbpathof /data/db, you must ensure that directory exists _and_is empty.

Start each replica set member.

Add each prospective member to the replica set.

Connect to the primary using the mongoshell and add each secondary to the replica set usingrs.add().

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