Navigation
This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.

Restore a Replica Set from a Backup

On this page

Overview

You can restore a replica set onto new hardware from the artifacts captured by On Prem MMS Backup.

You can restore from a stored snapshot or from a point in time in the last 24 hours. For point-in-time recovery, MMS applies the oplog to the snapshot that is previous to the selected point in order to create a custom snapshot. Point-in-time recovery takes longer than recovery from a stored snapshot.

MMS provides restore files as downloadable archives; MMS can also scp files directly to your system. The scp delivery method requires additional configuration but provides faster delivery.

Sequence

The sequence to restore a replica set is to:

  • download the restore file,
  • distribute the restore file to to each server,
  • start the mongod instances, and
  • initiate and configure the replica set.

For additional approaches to restoring replica sets, see the procedure from the MongoDB Manual to Restore a Replica Set from a Backup.

Consideration

You must ensure that the MongoDB deployment does not receive client requests during restoration. You must either:

  • restore to new systems with new hostnames and reconfigure your application code once the new deployment is running, or
  • ensure that the MongoDB deployment will not receive client requests while you restore data.

Procedures

Select and Download the Snapshot

When you select a snapshot to restore, MMS creates a link to download the snapshot as a tar file. The link is available for one download only and times out after an hour. Once you download the tar file, copy it to each server to restore.

1

Click the Backups tab and then Replica Set Status.

2

Click the name of the replica set to restore.

MMS displays your selection’s stored snapshots.

3

Select the snapshot from which to restore.

To select a stored snapshot, click the Restore this snapshot link next to the snapshot.

To select a custom snapshot, click the Restore button at the top of the page. In the resulting page, select a snapshot as the starting point. Then select the Use Custom Point In Time checkbox and enter the point in time in the Date and Time fields. MMS includes all operations up to but not including the point in time. For example, if you select 12:00, the last operation in the restore is 11:59:59 or earlier. Click Next.

4

Select HTTP as the delivery method for the snapshot.

In the Delivery Method field, select Pull via Secure HTTP (HTTPS).

Optionally, you can instead choose SCP as the delivery method. If you choose SCP, you must provide the hostname and port of the server to receive the files and provide access to the server through a username and password or though an SSH key. Follow the instructions on the MMS screen.

5

Finalize the request.

Click Finalize Request and confirm your identify via two-factor verification. Then click Finalize Request again.

6

Retrieve the snapshot.

MMS creates a one-time link to a tar file of the snapshot. The link is available for one download and times out after an hour.

To download the snapshot, select the MMS Backup tab and then select Restore Jobs. When the restore job completes, select the download link next to the snapshot.

If you optionally chose SCP as the delivery method, the files are copied to the server directory you specfied. To verify that the files are complete, see the section on how to validate an SCP restore.

Restore the Primary

You must have a copy of the snapshot on the server that provides the primary:

1

Shut down the entire replica set.

Connect to each member of the set and issue the following:

copy 
use admin
db.shutdownServer()

For version 2.4 or earlier, use db.shutdownServer({force:true}).

2

Restore the snapshot data files to the primary.

Extract the data files to the location where the mongod instance will access them, as specified in the dbpath setting. For example:

copy 
tar -xvf <backup-restore-name>.tar.gz
mv <backup-restore-name> /data
3

Start the primary with the new dbpath.

For example:

copy 
mongod --dbpath /<path-to-data> --replSet <replica-set-name>
4

Connect to the primary and initiate the replica set.

For example, first issue the following to connect:

copy 
mongo

And then issue rs.initiate():

copy 
rs.initiate()
5

Restart the primary as a standalone, without the --replSet option.

For example, first issue the following to shut down. (For version 2.4 or earlier, use db.shutdownServer({force:true})):

copy 
use admin
db.shutdownServer()

And then restart as a standalone:

copy 
mongod --dbpath /<path-to-data>
6

Connect to the primary and drop the oplog.

For example, first issue the following to connect:

copy 
mongo

And then issue rs.drop() to drop the oplog.

copy 
use local
db.oplog.rs.drop()
7

Run the seedSecondary.sh script on the primary.

The seedSecondary.sh script re-creates the oplog collection and seeds it with correct timestamp. The file is included in the backup restore file, except in certain circumstances.

To run the script, issue the following command at the system prompt:

copy 
./seedSecondary.sh <oplog-size-in-gigabytes>
8

Restart the primary as part of a replica set.

For example, first issue the following to shut down. (For version 2.4 or earlier, use db.shutdownServer({force:true})):

copy 
use admin
db.shutdownServer()

And then restart as part of a replica set:

copy 
mongod --dbpath /<path-to-data> --replSet <replica-set-name>

Restore Each Secondary

After you have restored the primary you can restore all secondaries. You must have a copy of the snapshot on all servers that provide the secondaries:

1

Connect to the server where you will create the new secondary.

2

Restore the snapshot data files to the secondary.

Extract the data files to the location where the mongod instance will access them, as specified in the dbpath setting. For example:

copy 
tar -xvf <backup-restore-name>.tar.gz
mv <backup-restore-name> /data
3

Start the secondary with the new dbpath.

For example:

copy 
mongod --dbpath /<path-to-data> --replSet <replica-set-name>
4

Restart the secondary as a standalone, without the --replSet option.

For example, first issue the following to shut down. (For version 2.4 or earlier, use db.shutdownServer({force:true})):

copy 
use admin
db.shutdownServer()

And then restart as a standalone:

copy 
mongod --dbpath /<path-to-data>
5

Connect to the secondary and drop the oplog.

For example, first issue the following to connect:

copy 
mongo

And then issue rs.drop() to drop the oplog.

copy 
use local
db.oplog.rs.drop()
6

Run the seedSecondary.sh script on the secondary.

The seedSecondary.sh script re-creates the oplog collection and seeds it with correct timestamp. The file is included in the backup restore file, except in certain circumstances.

To run the script, issue the following command at the system prompt:

copy 
./seedSecondary.sh <oplog-size-in-gigabytes>
7

Restart the secondary as part of the replica set.

For example, first issue the following to shut down. (For version 2.4 or earlier, use db.shutdownServer({force:true})):

copy 
use admin
db.shutdownServer()

And then restart as part of a replica set:

copy 
mongod --dbpath /<path-to-data> --replSet <replica-set-name>
8

Connect to the primary and add the secondary to the replica set.

Connect to the primary and use rs.add() to add the secondary to the replica set.

copy 
rs.add("<host>:<port>")

Repeat this operation for each member of the set.

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.