Restore a Replica Set from MongoDB Backups¶
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 cannot restore a single data set to three new
instances and then create a replica set. If you copy the data set
mongod instance and then create the replica set,
MongoDB will force the secondaries to perform an initial sync. The procedures in this document describe the correct and
efficient ways to deploy a restored replica set.
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 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
AES256-GCMrequires that every process use a unique counter block value with the key.For encrypted storage engine configured with
- Restoring from Hot Backup
- Starting in 4.2, if you restore from files taken via "hot"
backup (i.e. the
mongodis 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
mongodis 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
mongodinstance rolls over the database keys configured with
AES256-GCMcipher 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-GCMencryption mode, do not make copies of your data files or restore from filesystem snapshots ("hot" or "cold").
local database if it exists in the backup.¶
If you are restoring from a filesystem backup (or any backup with
local database), drop the
mongod --dbpath /data/db
use local db.dropDatabase()
Shut down the standalone.
Start a new single-node replica set.¶
mongod instance as a new single-node replica set.
Specify the path to the backup data files with
and the replica set name with the
For config server replica set (CSRS),
Include any other options as appropriate for your deployment.
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,
mongosh. To connect to the
listening to localhost on the default port of
27017, simply issue:
Depending on your path, you may need to specify the path to the
Add Members to the Replica Set¶
MongoDB provides two options for restoring secondary members of a replica set:
- Manually copy the database files to each data directory.
- Allow initial sync to distribute data automatically.
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.
Update Secondaries using Initial Sync¶
Use the following sequence of operations to "seed" additional members of the replica set with the restored data using the default initial sync operation.