Navigation
You were redirected from a different version of the documentation. Click here to go back.

Restore a Replica Set from a Backup

Overview

When you restore a replica set from backup, Ops Manager provides you with a restore file for the selected restore point. For an overview of the restore process, please see Restore Overview.

Considerations

BinData

The BSON specification changed the default subtype for the BSON binary datatype (BinData) from 2 to 0. Some binary data stored in a snapshot may be BinData subtype 2. The Backup Agent automatically detects and converts snapshot data in BinData subtype 2 to BinData subtype 0. If your application code expects BinData subtype 2, you must update your application code to work with BinData subtype 0.

See also

The notes on the BSON specification explain the particular specifics of this change.

restoreInfo.txt

The backup restore file includes a metadata file, restoreInfo.txt. This file captures the options the database used when the snapshot was taken. The database must be run with the listed options after it has been restored.

This file contains:

  • Group name

  • Replica Set name

  • Cluster Id (if applicable)

  • Snapshot timestamp (as Timestamp at UTC)

  • Last Oplog applied (as a BSON Timestamp at UTC)

  • MongoDB version

  • Storage engine type

  • mongod startup options used on the database when the snapshot was taken

  • Encryption (Only appears if encryption is enabled on the snapshot)

  • Master Key UUID (Only appears if encryption is enabled on the snapshot)

    If restoring from an encrypted backup, you must have a certificate provisioned for this Master Key.

Prerequisites

Restoring from Encrypted Backup

To restore from an encrypted backup, you need the same master key used to encrypt the backup and either the same certificate as is on the Backup Daemon server or a new certificate provisioned with that key from the KMIP server.

If the snapshot is encrypted, the restore panel displays the KMIP master key id and the KMIP server information. You can also find the information when you view the snapshot itself as well as in the restoreInfo.txt file.

Oplog Size

To seed each replica set member, you will use the seedSecondary.sh or seedSecondary.bat script included in the backup restore file. When you run the script, you will provide the replica set’s oplog size, in gigabytes.

See also

See the Check the Size of the Oplog section of the Troubleshoot Replica Sets if you do not have the size.

Client Requests During Restoration

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.

Secure Copy (SCP) Delivery

Important

SCP requires you to generate a key pair before attempting to transfer files. SCP provides faster file delivery than HTTP.

Note

Microsoft Windows computers do not include SCP and require additional setup outside the scope of this manual.

Procedures

To have Ops Manager automatically restore the backup, perform the select the snapshot procedure.

To restore the backup manually, perform all the following procedures sequentially. If you restore to existing hardware, use a different data directory than used previously.

See also

See Restore a Replica Set from a Backup for alternative approaches to restoring replica sets.

Select the Snapshot

1

Click Backup, then the Overview tab.

2

Click the deployment’s ellipsis icon and select Restore.

3

Select the restore point.

Choose the point from which you want to restore your backup.

Restore Type Description Action
Snapshot Allows you to choose one stored snapshot. Select an existing snapshot to restore.
Point In Time

Creates a custom snapshot that includes all operations up to but not including the selected time.

Example

If you select 12:00, the last operation in the restore is 11:59:59 or earlier.

Select a Date and Time.
Oplog Timestamp

Creates a custom snapshot based on the timestamp of an oplog entry (its ts field). Ops Manager includes all operations up to and including the time of the timestamp.

The oplog entry’s ts field is a BSON timestamp and has two components: the timestamp and the increment.

Type the following:

Timestamp
The value in seconds since the Unix epoch.
Increment
An incrementing ordinal for operations within a given second.

Click Next.

4

Select whether to have Ops Manager restore the snapshot.

Yes

Ops Manager restores the snapshot for you. If you select this option, Ops Manager prompts to choose the replica set to which to restore. You can select an existing replica set or create a new one.

Follow the prompts in the wizard.

Important

You can skip the remainder of this page.

No, I’ll do it myself Ops Manager provides you with the restore files for you to perform the restore manually.
5

Choose how to receive the restore files.

Select the restore method, format and destination.

Pull Via Secure HTTP
  1. Type a direct download link.

  2. Select from the following options:

    Pull Restore Usage Limit

    Select whether the link can be re-used or used just once. If you select No Limit, the link is re-usable until it expires.

    Restore Link Expiration (in hours)

    Select the number of hours until the link expires.

Important

You can skip the remainder of this procedure.

Push Via Secure Copy

Direct Ops Manager to copy the restore files to your server via SCP.

Important

SCP requires you to generate a key pair before attempting to transfer files. SCP provides faster file delivery than HTTP.

Note

Microsoft Windows computers do not include SCP and require additional setup outside the scope of this manual.

Format

Select the format in which you want to receive the restore files:

Individual DB Files
Transmits MongoDB data files produced by Ops Manager directly to the target directory.
Archive

Delivers database files in a single archive (tar or tar.gz) that you must extract before restoring the databases to a working directory.

This option displays only if the archive size can be calculated.

With Archive delivery, you need sufficient space on the destination server for both the archive and the extracted files.

SCP Host Type the hostname of the server to receive the files.
SCP Port Type the port of the server to receive the files.
SCP User Type the username used to access to the server.
Auth Method Select whether to use a username and password or an SSH certificate to authenticate to the server.
Password Type the user password used to access to the server.
Passphrase Type the SSH passphrase used to access to the server.
Target Directory Type the absolute path to the directory on the server to which to copy the restore files.

If the snapshot is encrypted, the restore panel displays the KMIP master key id and the KMIP server information. You can also find the information when you view the snapshot itself as well as in the restoreInfo.txt file.

Click Finalize Request.

6

Retrieve the snapshot.

If you selected Pull Via Secure HTTP:

Ops Manager creates a link to the snapshot. By default, this link is available for an hour and can be used just once. To download the snapshot:

  1. Click Backup, then the Restore History tab.
  2. When the restore job completes, select the download link next to the snapshot.
If you selected Push Via Secure Copy:
The files are copied to the server directory you specified. To verify that the files are complete, see how to validate a secure copy restore.
7

Copy the snapshot to each replica set member to restore.

Restore the Primary

You must have a copy of the snapshot on the server that provides the primary. Use this procedure only for manual restores.

1

Shut down the entire replica set.

Shut down the replica set’s mongod processes using one of the following methods, depending on your configuration:

Automated Deployment

If you use Ops Manager Automation to manage the replica set, you must shut down through the Ops Manager console. See Shut Down a MongoDB Process.

Non-Automated Deployment on MongoDB 2.6 or Later

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

use admin
db.shutdownServer()
Non-Automated Deployment on MongoDB 2.4 or earlier

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

use admin
db.shutdownServer( { force: true } )
2

Restore the snapshot data files to the primary.

Extract the data files to the location where the mongod process will access them through the dbpath setting. If you are restoring to existing hardware, use a different data directory than used previously. The following are example commands:

mv <snapshot> /data
tar -xvf <snapshot>.tar.gz
3

Start the primary with the new dbpath.

For example:

mongod --dbpath <pathToData> --replSet <replicaSetName> --logpath <pathToData>/mongodb.log --fork

If the data files are encrypted, include the following mongod options set to appropriate values:

If the snapshot is encrypted, the restore panel displays the KMIP master key id and the KMIP server information. You can also find the information when you view the snapshot itself as well as in the restoreInfo.txt file.

4

Connect to the primary and initiate the replica set.

Connect using the mongo shell and issue the rs.initiate() command.

5

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

Shut down the process using one of the following methods:

Automated Deployment

Shut down through the Ops Manager console. See Shut Down a MongoDB Process.

Non-Automated Deployment on MongoDB 2.6 or Later
use admin
db.shutdownServer()
Non-Automated Deployment on MongoDB 2.4 or earlier
use admin
db.shutdownServer( { force: true } )

If the data files are encrypted, include the following mongod options set to appropriate values:

If the snapshot is encrypted, the restore panel displays the KMIP master key id and the KMIP server information. You can also find the information when you view the snapshot itself as well as in the restoreInfo.txt file.

6

Connect to the primary and drop the oplog.

For example, first issue the following to connect:

mongo

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

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

Run the seedSecondary script on the primary.

Use the appropriate script for your operating system:

UNIX-based seedSecondary.sh
Windows seedSecondary.bat

This script recreates the oplog collection and seeds it with the timestamp of the snapshot’s creation. This tells the secondary to recreate all operations to the current time without requiring a full initial sync. Ops Manager customizes this script for this particular snapshot and includes it in the snapshot archive.

To run the script, issue the following command, where:

<alternatePort> The port of the mongod process
<oplogSizeInGigabytes> The size of the replica set’s oplog
<replicaSetName> The name of the replica set
<primaryHost:primaryPort> The hostname:port combination for the replica set’s primary
For UNIX-based systems:
./seedSecondary.sh <alternatePort> <oplogSizeInGigabytes> <replicaSetName> <primaryHost:primaryPort>
./seedSecondary.sh 27018 2 rs-1 primaryHost.example.com:27017
For Windows-based systems:
.\seedSecondary.bat <alternatePort> <oplogSizeInGigabytes> <replicaSetName> <primaryHost:primaryPort>
.\seedSecondary.bat 27018 2 rs-1 primaryHost.example.com:27017
8

Restart the primary as part of a replica set.

Use the following sequence:

  1. Shut down the process using one of the following methods:

    • Automated Deployment:

      Shut down through the Ops Manager console. See Shut Down a MongoDB Process.

    • Non-Automated Deployment on MongoDB 2.6 or Later:

      use admin
      db.shutdownServer()
      
    • Non-Automated Deployment on MongoDB 2.4 or earlier:

      use admin
      db.shutdownServer( { force: true } )
      
  2. Restart the process as part of a replica set:

    mongod --dbpath /<pathToData> --replSet <replicaSetName>
    

If the data files are encrypted, include the following mongod options set to appropriate values:

If the snapshot is encrypted, the restore panel displays the KMIP master key id and the KMIP server information. You can also find the information when you view the snapshot itself as well as in the restoreInfo.txt file.

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. Use this procedure only for manual restores.

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 process will access them through the dbpath setting. If you are restoring to existing hardware, use a different data directory than used previously. The following are example commands:

mv <snapshot> /data
tar -xvf <snapshot>.tar.gz
3

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

Shut down the process using one of the following methods:

Automated Deployment

Shut down through the Ops Manager console. See Shut Down a MongoDB Process.

Non-Automated Deployment on MongoDB 2.6 or Later
use admin
db.shutdownServer()
Non-Automated Deployment on MongoDB 2.4 or earlier
use admin
db.shutdownServer( { force: true } )

If the data files are encrypted, include the following mongod options set to appropriate values:

If the snapshot is encrypted, the restore panel displays the KMIP master key id and the KMIP server information. You can also find the information when you view the snapshot itself as well as in the restoreInfo.txt file.

4

Run the seedSecondary.sh script on the secondary.

Use the appropriate script for your operating system:

UNIX-based seedSecondary.sh
Windows seedSecondary.bat

This script recreates the oplog collection and seeds it with the timestamp of the snapshot’s creation. This tells the secondary to recreate all operations to the current time without requiring a full initial sync. Ops Manager customizes this script for this particular snapshot and includes it in the snapshot archive.

To run the script, issue the following command, where:

<alternatePort> The port of the mongod process
<oplogSizeInGigabytes> The size of the replica set’s oplog
<replicaSetName> The name of the replica set
<primaryHost:primaryPort> The hostname:port combination for the replica set’s primary
For UNIX-based systems:
./seedSecondary.sh <alternatePort> <oplogSizeInGigabytes> <replicaSetName> <primaryHost:primaryPort>
./seedSecondary.sh 27018 2 rs-1 primaryHost.example.com:27017
For Windows-based systems:
.\seedSecondary.bat <alternatePort> <oplogSizeInGigabytes> <replicaSetName> <primaryHost:primaryPort>
.\seedSecondary.bat 27018 2 rs-1 primaryHost.example.com:27017
5

Restart the secondary as part of the replica set.

Use the following sequence:

  1. Shut down the process using one of the following methods:

    • Automated Deployment:

      Shut down through the Ops Manager console. See Shut Down a MongoDB Process.

    • Non-Automated Deployment on MongoDB 2.6 or Later:

      use admin
      db.shutdownServer()
      
    • Non-Automated Deployment on MongoDB 2.4 or earlier:

      use admin
      db.shutdownServer( { force: true } )
      
  2. Restart the process as part of a replica set:

    mongod --dbpath /<pathToData> --replSet <replicaSetName>
    

If the data files are encrypted, include the following mongod options set to appropriate values:

If the snapshot is encrypted, the restore panel displays the KMIP master key id and the KMIP server information. You can also find the information when you view the snapshot itself as well as in the restoreInfo.txt file.

6

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.

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

Repeat this operation for each member of the set.