Docs Menu
Docs Home
/
MongoDB Cloud Manager
/ /

Restore a Replica Set from a Snapshot

On this page

  • Considerations
  • Prerequisites
  • Restore a Snapshot

When you restore a replica set from backup, Cloud Manager provides you with a restore file for the selected restore point. To learn about the restore process, please see Restore Overview.

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 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.

Tip

See also:

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

The backup restore file includes a metadata file named 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)

  • Restore timestamp (as a BSON 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

All FCV databases must fulfill the appropriate backup considerations.

To perform manual restores, you must have the Backup Admin role in Cloud Manager.

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.

To have Cloud Manager automatically restore the snapshot:

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. Click Continuous Backup in the sidebar.

    The Continuous Backup page displays.

2
3
4
  1. 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. By default, the Oplog Store stores 24 hours of data.

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

    IMPORTANT: In FCV 4.0, you cannot perform a PIT restore that covers any time prior to the latest backup resync. For the conditions that cause a resync, see Resync a Backup. This note does not apply to FCV 4.2 or later.

    Select a Date and Time.
    Oplog Timestamp

    Creates a custom snapshot that includes all operations up to and including the entered Oplog timestamp. The Oplog Timestamp contains two fields:

    Timestamp

    Timestamp in the number of seconds that have elapsed since the UNIX epoch

    Increment
    Order of operation applied in that second as a 32-bit ordinal.

    Type an Oplog Timestamp and Increment.

    Run a query against local.oplog.rs on your replica set to find the desired timestamp.

  2. Click Next.

5
  1. Click Choose Cluster to Restore to.

  2. Complete the following fields:

    Field
    Action
    Project
    Select a project to which you want to restore the snapshot.
    Cluster to Restore to

    Select a cluster to which you want to restore the snapshot.

    Cloud Manager must manage the target replica set.

    WARNING: Automation removes all existing data from the cluster. It preserves all backup data and snapshots for the existing cluster.

  1. Click Restore.

    Cloud Manager notes how much storage space the restore requires.

6

Warning

Consider Automatic Restore

This procedure involves a large number steps. Some of these steps have severe security implications. If you don't need to restore to a deployment that Cloud Manager doesn't manage, consider an automated restore.

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. Click Continuous Backup in the sidebar.

    The Continuous Backup page displays.

2
3
4
  1. 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. By default, the Oplog Store stores 24 hours of data.

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

    IMPORTANT: In FCV 4.0, you cannot perform a PIT restore that covers any time prior to the latest backup resync. For the conditions that cause a resync, see Resync a Backup. This note does not apply to FCV 4.2 or later.

    Select a Date and Time.
    Oplog Timestamp

    Creates a custom snapshot that includes all operations up to and including the entered Oplog timestamp. The Oplog Timestamp contains two fields:

    Timestamp

    Timestamp in the number of seconds that have elapsed since the UNIX epoch

    Increment
    Order of operation applied in that second as a 32-bit ordinal.

    Type an Oplog Timestamp and Increment.

    Run a query against local.oplog.rs on your replica set to find the desired timestamp.

  2. Click Next.

5
6
  1. Configure the following download options:

    Pull Restore Usage Limit
    Select how many times the link can be used. 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. The default value is 1. The maximum value is the number of hours until the selected snapshot expires.
  2. Click Finalize Request.

  3. If you use 2FA, Cloud Manager prompts you for your 2FA code. Enter your 2FA code, then click Finalize Request.

7
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. Click Continuous Backup in the sidebar.

    The Continuous Backup page displays.

8

Cloud Manager creates links to the snapshot. By default, these links are available for an hour and you can use them just once.

To download the snapshots:

  1. Click Restore History.

  2. When the restore job completes, click (get link) for each replica set that appears.

  3. Click:

    • The copy button to the right of the link to copy the link to use it later, or

    • Download to download the snapshot immediately.

9

Before attempting to restore the data manually, remove the replica set from Automation.

Choose the Unmanage this item in Ops Managers but continue to monitor option.

10

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

mongosh --port <port> \
--eval "db.getSiblingDB('admin').shutdownServer()"
11
Storage Capacity
The target host's hardware needs to have sufficient free storage space for storing the restored data. If you want to keep any existing cluster data on this host, make sure the host has sufficient free space for the cluster data and the restored data.
MongoDB Version
The target host on which you are restoring and the source host from which you are restoring must run the same MongoDB Server version. To check the MongoDB version, run mongod --version from a terminal or shell.

To learn more, see installation.

12

Before you move the snapshot's data files to the target host, check whether the target host contains any existing files, and delete all the files except the automation-mongod.conf file.

Unpack the snapshot files and move them to the target host as follows:

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> </path/to/datafiles>
13

Start the mongod process in standalone mode as a temporary measure. This allows you to add new configuration parameters to the system.replset collection in subsequent steps.

Use the <ephemeralPort> for the temporary standalone mongod process in all steps in this procedure where it is mentioned. This port must differ from the source and target host ports.

Run the mongod process as follows. Depending on your path, you may need to specify the path to the mongod binary.

mongod --dbpath </path/to/datafiles> \
--port <ephemeralPort> \

If you are restoring from a namespace-filtered snapshot, use the --restore option.

mongod --dbpath </path/to/datafiles> \
--port <ephemeralPort> \
--restore

After the mongod process starts accepting connections, continue.

14

From the host running this mongod process, start mongosh. Depending on your path, you may need to specify the path to mongosh.

To connect to the mongod listening to localhost on the same <ephemeralPort> specified in the previous step, run:

mongosh --port <ephemeralPort>

After mongosh connects to mongod, continue.

15

To perform manual restores, you must have the Backup Admin role in Cloud Manager.

Run the following commands to remove the previous replica set configuration and other non-oplog, replication-related collections.

db.getSiblingDB("local").replset.minvalid.drop()
db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop()
db.getSiblingDB("local").replset.election.drop()
db.getSiblingDB("local").system.replset.remove({})

A successful response should look like this:

> db.getSiblingDB("local").replset.minvalid.drop()
true
> db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop()
true
> db.getSiblingDB("local").replset.election.drop()
true
> db.getSiblingDB("local").system.replset.remove({})
WriteResult({ "nRemoved" : 1 })
16

Insert the following document into the system.replset collection in the local database. Change the following variables:

  • <replaceMeWithTheReplicaSetName> to the name of your replica set. This name does not have to be the same as the old name.

  • <host> to the host serving this replica set member.

  • <ephemeralPortNewReplicaSet> to the ephemeral port for the new replica set. This must be a different port than the <ephemeralPort> that you specified in Step 11 of this procedure.

1db.getSiblingDB("local").system.replset.insertOne({
2 "_id" : "<replaceMeWithTheReplicaSetName>",
3 "version" : NumberInt(1),
4 "protocolVersion" : NumberInt(1),
5 "members" : [
6 {
7 "_id" : NumberInt(0),
8 "host" : "<host>:<ephemeralPortNewReplicaSet>"
9 }
10 ],
11 "settings" : {
12
13 }
14})

A successful response should look like this:

{ "acknowledged" : true, "insertedId" : "<yourReplicaSetName>" }
17

Issue the following command:

db.getSiblingDB("local").replset.minvalid.insertOne({
"_id" : ObjectId(),
"t" : NumberLong(-1),
"ts" : Timestamp(0,1)
})

A successful response should look like this:

{ "acknowledged" : true, "insertedId" : ObjectId("<yourObjectId>") }
18

Set the oplogTruncateAfterPoint document to the values provided in the Restore Timestamp field of the restoreInfo.txt file.

The Restore Timestamp field in that file contains two values. In the following example, the first value is the timestamp, and the second value is the increment.

1...
2Restore timestamp: (1609947369, 2)
3Last Oplog Applied: Wed Jan 06 15:36:09 GMT 2021 (1609947369, 1)
4MongoDB Version: 4.2.11
5...

The following example code uses the timestamp value and increment value from the previous example.

truncateAfterPoint = Timestamp(1609947369,2)
db.getSiblingDB("local").replset.oplogTruncateAfterPoint.insertOne({
"_id": "oplogTruncateAfterPoint",
"oplogTruncateAfterPoint": truncateAfterPoint
})

A successful response should look like this:

WriteResult({ "nInserted" : 1 })

Note

Restoring MongoDB 4.2 Snapshots using MongoDB 4.4

If you try to restore a MongoDB 4.2 snapshot with a mongod running MongoDB 4.4, your oplog may contain unneeded documents.

To resolve this issue, you can either:

  • Decrement the timestamp by 1.

  • Restore using MongoDB 4.2.

  • Have Cloud Manager run an automated restore.

This issue doesn't apply to MongoDB 4.4 or later snapshots.

19

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

mongosh --port <ephemeralPort> \
--eval "db.getSiblingDB('admin').shutdownServer()"
20

Start the mongod using the following command, specifying these parameters:

  • <bind_ip> to the host serving this replica set member that you specified in step 14 of this procedure.

  • <port> to the <ephemeralPort> that you specified in Step 11 of this procedure.

The mongod replays the oplog up to the Restore timestamp.

mongod --dbpath </path/to/datafiles> \
--port <ephemeralPort> \
--bind_ip <host-serving-this-replica-set-member> \
--replSet <replaceMeWithTheReplicaSetName>
21

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

mongosh --port <ephemeralPort> \
--eval "db.getSiblingDB('admin').shutdownServer()"
22

This step is optional. Run it if you need Point-in-Time Restore. If you need this step, complete it and then run steps 21 and 22. If you don't need this step, then proceed to step 23. In this step, you download and run the MongoDB Backup Restore Utility on the target instance for the replica set, and then stop the instance.

  1. Download the MongoDB Backup Restore Utility to your host.

    If you closed the restore panel, click Continuous Backup in Deployment, More, and then Download MongoDB Backup Restore Utility.

  2. Start a mongod instance without authentication enabled using the extracted snapshot directory as the data directory. Depending on your path, you may need to specify the path to the mongod binary.

    mongod --port <ephemeralPort> \
    --dbpath </path/to/datafiles> \
    --setParameter ttlMonitorEnabled=false

    Warning

    The MongoDB Backup Restore Utility doesn't support authentication, so you can't start this temporary database with authentication.

  3. Run the MongoDB Backup Restore Utility on your target host. Run it once for the replica set.

    Important

    Pre-configured mongodb-backup-restore-util command

    Cloud Manager provides the mongodb-backup-restore-util with the appropriate options for your restore on the restore panel under Run Binary with PIT Options.

    You should copy the mongodb-backup-restore-util command provided in the Cloud Manager.

    ./mongodb-backup-restore-util --https --host <targetHost> \
    --port <targetPort> \
    --opStart <opLogStartTimeStamp> \
    --opEnd <opLogEndTimeStamp> \
    --logFile <logPath> \
    --apiKey <apiKey> \
    --groupId <groupId> \
    --rsId <rsId> \
    --whitelist <database1.collection1, database2, etc.> \
    --blacklist <database1.collection1, database2, etc.> \
    --seedReplSetMember \
    --oplogSizeMB <size> \
    --seedTargetPort <port> \
    --ssl \
    --sslCAFile </path/to/ca.pem> \
    --sslPEMKeyFile </path/to/pemkey.pem>
    --sslClientCertificateSubject <distinguishedName> \
    --sslRequireValidServerCertificates <true|false> \
    --sslServerClientCertificate </path/to/client.pem> \
    --sslServerClientCertificatePassword <password> \
    --sslRequireValidMMSBackupServerCertificate <true|false> \
    --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \
    --httpProxy <proxyURL>

    The mongodb-backup-restore-util command uses the following options:

    Option
    Necessity
    Description
    --host
    Required
    Provide the hostname, FQDN, IPv4 address, or IPv6 address for the host that serves the mongod to which the oplog should be applied. If you copied the mongodb-backup-restore-util command provided in the Cloud Manager, this field is pre-configured.
    --port
    Required
    Provide the port for the host that serves the mongod to which the oplog should be applied.
    --opStart
    Required

    Provide the BSON timestamp for the first oplog entry you want to include in the restore. This information appears in the "Last Oplog Applied" entry in the restoreInfo.txt file provided with the downloaded snapshot.

    This value must be less than or equal to the --opEnd value.

    --opEnd
    Required

    Provide the BSON timestamp for the last oplog entry you want to include in the restore.

    This value cannot be greater than the end of the oplog.

    --logFile
    Optional
    Provide a path, including file name, where the MBRU log is written.
    --oplogSourceAddr
    Required
    Provide the URL to the Cloud Manager resource endpoint.
    --apiKey
    Required
    Provide your Cloud Manager Agent API Key.
    --groupId
    Required
    Provide the group ID.
    --rsId
    Required
    Provide the replica set ID.
    --whitelist
    Optional
    Provide a list of databases and/or collections to which you want to limit the restore.
    --blacklist
    Optional
    Provide a list of databases and/or collections to which you want to exclude from the restore.
    --seedReplSetMember
    Optional

    Use if you need a replica set member to re-create the oplog collection and seed it with the correct timestamp.

    Requires --oplogSizeMB and --seedTargetPort.

    --oplogSizeMB
    Conditional

    Provide the oplog size in MB.

    Required if --seedReplSetMember is set.

    --seedTargetPort
    Conditional

    Provide the port for the replica set's primary. This may be different from the ephemeral port used.

    Required if --seedReplSetMember is set.

    --ssl
    Conditional

    Use if you need TLS/SSL to apply the oplog to the mongod.

    Requires --sslCAFile and --sslPEMKeyFile.

    --sslCAFile
    Conditional

    Provide the path to the Certificate Authority file.

    Required if --ssl is set.

    --sslPEMKeyFile
    Conditional

    Provide the path to the PEM certificate file.

    Required if --ssl is set.

    --sslPEMKeyFilePwd
    Conditional

    Provide the password for the PEM certificate file specified in --sslPEMKeyFile.

    Required if --ssl is set and that PEM key file is encrypted.

    --sslClientCertificateSubject
    Provide the Client Certificate Subject or Distinguished Name (DN) for the target MongoDB process.
    --sslRequireValidServerCertificates
    Optional
    Set a flag indicating if the tool should validate certificates that the target MongoDB process presents.
    --sslServerClientCertificate
    Optional
    Provide the absolute path to Client Certificate file to use for connecting to the Cloud Manager host.
    --sslServerClientCertificatePassword
    Conditional

    Provide the absolute path to Client Certificate file password to use for connecting to the Cloud Manager host.

    Required if --sslServerClientCertificate is set and that certificate is encrypted.

    --sslRequireValidMMSBackupServerCertificate
    Optional
    Set a flag indicating if valid certificates are required when contacting the Cloud Manager host. Default value is true.
    --sslTrustedMMSBackupServerCertificate
    Optional
    Provide the absolute path to the trusted Certificate Authority certificates in PEM format for the Cloud Manager host. If this flag is not provided, the system Certificate Authority is used.
    --httpProxy
    Optional
    Provide the URL of an HTTP proxy server the tool can use.

    means that if you copied the mongodb-backup-restore-util command provided in Cloud Manager, this field is pre-configured.

  4. Stop the mongod on the instance. Depending on your path, you may need to specify the path to mongosh. Run:

    mongosh --port <ephemeralPort> \
    --eval "db.getSiblingDB('admin').shutdownServer()"
23

This step is needed only if you ran step 20. If you didn't need to run step 20, then proceed to step 23. Start the mongod using the following command. The mongod replays the oplog up to the Restore timestamp. Depending on your path, you may need to specify the path to the mongod binary.

mongod --dbpath </path/to/datafiles> \
--port <ephemeralPort> \
--replSet <replaceMeWithTheReplicaSetName>

After you complete this step, the actual restore process is completed. In the following steps, you restore the configuration of the replica set and reimport it.

24

This step is needed only if you ran step 20. If you didn't need to run step 20, then proceed to step 23.

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

mongosh--port <ephemeralPort> \
--eval "db.getSiblingDB('admin').shutdownServer()"
25

Start the mongod process as a standalone instance using the following command. For <port>, use the actual port on which this node in the replica set is intended to run. Depending on your path, you may need to specify the path to the mongod binary.

mongod --dbpath </path/to/datafiles> \
--port <port>

After the mongod process starts accepting connections, continue.

26

Run the following command:

mongosh --port <port> \
--eval db.getSiblingDB("local").system.replset.remove({})
27

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

mongosh --port <port> \
--eval "db.getSiblingDB('admin').shutdownServer()"
28
29

At this point, the data files in the replica set are in a consistent state, but the replica set configuration needs to be updated so that each node is aware of each other.

Run the following command:

sudo -u mongod <path/to/target_mongod_binary> -f /path/to/datafiles/automation-mongod.conf

The following example restarts all nodes with the version 4.4.12 enterprise with the data path /data6/node3:

sudo -u mongod /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.12-ent/bin/mongod -f /data6/node3/automation-mongod.conf
30

Log into one of the nodes and run the following commands:

rs.initiate()
rs.add( { host: "<host2>:<port>" } )
rs.add( { host: "<host3>:<port>" } )
31
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. If the Deployment page is not already displayed, click Deployment in the sidebar.

    The Deployment page displays.

32

To manage the replica set with automation again, import the replica set back into Cloud Manager.

Click Add, select Existing MongoDB Deployment, and proceed with adding Automation back to your cluster.

To have Cloud Manager automatically restore the snapshot:

1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. Click Continuous Backup in the sidebar.

    The Continuous Backup page displays.

2
3
4
  1. 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. By default, the Oplog Store stores 24 hours of data.

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

    IMPORTANT: In FCV 4.0, you cannot perform a PIT restore that covers any time prior to the latest backup resync. For the conditions that cause a resync, see Resync a Backup. This note does not apply to FCV 4.2 or later.

    Select a Date and Time.
    Oplog Timestamp

    Creates a custom snapshot that includes all operations up to and including the entered Oplog timestamp. The Oplog Timestamp contains two fields:

    Timestamp

    Timestamp in the number of seconds that have elapsed since the UNIX epoch

    Increment
    Order of operation applied in that second as a 32-bit ordinal.

    Type an Oplog Timestamp and Increment.

    Run a query against local.oplog.rs on your replica set to find the desired timestamp.

  2. Click Next.

To find the latest Oplog entry, run the following query in mongosh:

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

A successful result should look like this:

{
"ts": Timestamp(1537559320, 1),
"h": NumberLong("-2447431566377702740"),
"v": 2,
"op": "n",
"ns": "",
"wall": ISODate("2018-09-21T19:48:40.708Z"),
"o": {
"msg": "initiating set"
}
}

The parts of the ts value correspond to the values you need for the Timestamp and Increment boxes.

Note

To translate the epoch time into a human-readable timestamp, try using a tool like Epoch Converter

MongoDB does not endorse this service. Its reference is intended only as informational.

5
  1. Click Choose Cluster to Restore to.

  2. Complete the following fields:

    Field
    Action
    Project
    Select a project to which you want to restore the snapshot.
    Cluster to Restore to

    Select a cluster to which you want to restore the snapshot.

    Cloud Manager must manage the target replica set.

    WARNING: Automation removes all existing data from the cluster. It preserves all backup data and snapshots for the existing cluster.

  1. Click Restore.

    Cloud Manager notes how much storage space the restore requires.

6
1
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. Click Continuous Backup in the sidebar.

    The Continuous Backup page displays.

2
3
4
  1. 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. By default, the Oplog Store stores 24 hours of data.

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

    IMPORTANT: In FCV 4.0, you cannot perform a PIT restore that covers any time prior to the latest backup resync. For the conditions that cause a resync, see Resync a Backup. This note does not apply to FCV 4.2 or later.

    Select a Date and Time.
    Oplog Timestamp

    Creates a custom snapshot that includes all operations up to and including the entered Oplog timestamp. The Oplog Timestamp contains two fields:

    Timestamp

    Timestamp in the number of seconds that have elapsed since the UNIX epoch

    Increment
    Order of operation applied in that second as a 32-bit ordinal.

    Type an Oplog Timestamp and Increment.

    Run a query against local.oplog.rs on your replica set to find the desired timestamp.

  2. Click Next.

To find the latest Oplog entry, run the following query in mongosh:

db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()

A successful result should look like this:

{
"ts": Timestamp(1537559320, 1),
"h": NumberLong("-2447431566377702740"),
"v": 2,
"op": "n",
"ns": "",
"wall": ISODate("2018-09-21T19:48:40.708Z"),
"o": {
"msg": "initiating set"
}
}

The parts of the ts value correspond to the values you need for the Timestamp and Increment boxes.

Note

To translate the epoch time into a human-readable timestamp, try using a tool like Epoch Converter

MongoDB does not endorse this service. Its reference is intended only as informational.

5
6
  1. Configure the following download options:

    Pull Restore Usage Limit
    Select how many times the link can be used. 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. The default value is 1. The maximum value is the number of hours until the selected snapshot expires.
  2. Click Finalize Request.

  3. If you use 2FA, Cloud Manager prompts you for your 2FA code. Enter your 2FA code, then click Finalize Request.

7
  1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. Click Continuous Backup in the sidebar.

    The Continuous Backup page displays.

8

Cloud Manager creates links to the snapshot. By default, these links are available for an hour and can be used just once.

To download the snapshots:

  1. Click Restore History.

  2. When the restore job completes, click (get link) for each replica set appears.

  3. Click:

    • The copy button to the right of the link to copy the link to use it later, or

    • Download to download the snapshot immediately.

Important

Extra step for point-in-time restores

For point-in-time and oplog timestamp restores, additional instructions are shown. The final step shows the full command you must run using the MBRU. It includes all of the necessary options to ensure a full restore.

Select and copy the mongodb-backup-restore-util command provided under Run Binary with PIT Options.

9

Example

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> <temp-database-path>
10
  1. Download the MongoDB Backup Restore Utility to your host.

    Note

    If you closed the restore panel:

    1. In MongoDB Cloud Manager, go to the Continuous Backup page for your project.

      1. If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

      2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

      3. Click Continuous Backup in the sidebar.

      The Continuous Backup page displays.

    2. Click More and then Download MongoDB Backup Restore Utility.

  2. Start a mongod instance without authentication enabled using the extracted snapshot directory as the data directory.

    Example

    mongod --port <port number> \
    --dbpath <temp-database-path> \
    --setParameter ttlMonitorEnabled=false

    Warning

    The MongoDB Backup Restore Utility doesn't support authentication, so you can't start this temporary database with authentication.

  3. Run the MongoDB Backup Restore Utility on your destination host. Run it once for the replica set.

    Important

    Pre-configured mongodb-backup-restore-util command

    Cloud Manager provides the mongodb-backup-restore-util with the appropriate options for your restore on the restore panel under Run Binary with PIT Options.

    You should copy the mongodb-backup-restore-util command provided in the Cloud Manager.

    ./mongodb-backup-restore-util --https --host <targetHost> \
    --port <targetPort> \
    --opStart <opLogStartTimeStamp> \
    --opEnd <opLogEndTimeStamp> \
    --logFile <logPath> \
    --apiKey <apiKey> \
    --groupId <groupId> \
    --rsId <rsId> \
    --whitelist <database1.collection1, database2, etc.> \
    --blacklist <database1.collection1, database2, etc.> \
    --seedReplSetMember \
    --oplogSizeMB <size> \
    --seedTargetPort <port> \
    --ssl \
    --sslCAFile </path/to/ca.pem> \
    --sslPEMKeyFile </path/to/pemkey.pem>
    --sslClientCertificateSubject <distinguishedName> \
    --sslRequireValidServerCertificates <true|false> \
    --sslServerClientCertificate </path/to/client.pem> \
    --sslServerClientCertificatePassword <password> \
    --sslRequireValidMMSBackupServerCertificate <true|false> \
    --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \
    --httpProxy <proxyURL>

    The mongodb-backup-restore-util command uses the following options:

    Option
    Necessity
    Description
    --host
    Required
    Provide the hostname, FQDN, IPv4 address, or IPv6 address for the host that serves the mongod to which the oplog should be applied. If you copied the mongodb-backup-restore-util command provided in the Cloud Manager, this field is pre-configured.
    --port
    Required
    Provide the port for the host that serves the mongod to which the oplog should be applied.
    --opStart
    Required

    Provide the BSON timestamp for the first oplog entry you want to include in the restore. This information appears in the "Last Oplog Applied" entry in the restoreInfo.txt file provided with the downloaded snapshot.

    This value must be less than or equal to the --opEnd value.

    --opEnd
    Required

    Provide the BSON timestamp for the last oplog entry you want to include in the restore.

    This value cannot be greater than the end of the oplog.

    --logFile
    Optional
    Provide a path, including file name, where the MBRU log is written.
    --oplogSourceAddr
    Required
    Provide the URL to the Cloud Manager resource endpoint.
    --apiKey
    Required
    Provide your Cloud Manager Agent API Key.
    --groupId
    Required
    Provide the group ID.
    --rsId
    Required
    Provide the replica set ID.
    --whitelist
    Optional
    Provide a list of databases and/or collections to which you want to limit the restore.
    --blacklist
    Optional
    Provide a list of databases and/or collections to which you want to exclude from the restore.
    --seedReplSetMember
    Optional

    Use if you need a replica set member to re-create the oplog collection and seed it with the correct timestamp.

    Requires --oplogSizeMB and --seedTargetPort.

    --oplogSizeMB
    Conditional

    Provide the oplog size in MB.

    Required if --seedReplSetMember is set.

    --seedTargetPort
    Conditional

    Provide the port for the replica set's primary. This may be different from the ephemeral port used.

    Required if --seedReplSetMember is set.

    --ssl
    Conditional

    Use if you need TLS/SSL to apply the oplog to the mongod.

    Requires --sslCAFile and --sslPEMKeyFile.

    --sslCAFile
    Conditional

    Provide the path to the Certificate Authority file.

    Required if --ssl is set.

    --sslPEMKeyFile
    Conditional

    Provide the path to the PEM certificate file.

    Required if --ssl is set.

    --sslPEMKeyFilePwd
    Conditional

    Provide the password for the PEM certificate file specified in --sslPEMKeyFile.

    Required if --ssl is set and that PEM key file is encrypted.

    --sslClientCertificateSubject
    Provide the Client Certificate Subject or Distinguished Name (DN) for the target MongoDB process.
    --sslRequireValidServerCertificates
    Optional
    Set a flag indicating if the tool should validate certificates that the target MongoDB process presents.
    --sslServerClientCertificate
    Optional
    Provide the absolute path to Client Certificate file to use for connecting to the Cloud Manager host.
    --sslServerClientCertificatePassword
    Conditional

    Provide the absolute path to Client Certificate file password to use for connecting to the Cloud Manager host.

    Required if --sslServerClientCertificate is set and that certificate is encrypted.

    --sslRequireValidMMSBackupServerCertificate
    Optional
    Set a flag indicating if valid certificates are required when contacting the Cloud Manager host. Default value is true.
    --sslTrustedMMSBackupServerCertificate
    Optional
    Provide the absolute path to the trusted Certificate Authority certificates in PEM format for the Cloud Manager host. If this flag is not provided, the system Certificate Authority is used.
    --httpProxy
    Optional
    Provide the URL of an HTTP proxy server the tool can use.

    means that if you copied the mongodb-backup-restore-util command provided in Cloud Manager, this field is pre-configured.

11

Before attempting to restore the data manually, remove the replica set from Automation.

12

Follow the tutorial from the MongoDB Manual to restore the replica set.

13

To manage the replica set with automation again, import the replica set back into Cloud Manager.

Important

Rotate Master Key after Restoring Snapshots Encrypted with AES256-GCM

If you restore an encrypted snapshot that Cloud Manager encrypted with AES256-GCM, rotate your master key after completing the restore.

Back

Restore Sharded Cluster