Restore Overview

Restorable Time Ranges and Oplog Gaps

When you request a point-in-time restore, the restore dialog shows the restorable time ranges for the selected deployment. These ranges represent the periods for which Cloud Manager has a complete and continuous oplog history. You can only choose a restore time that falls within one of these ranges.

Oplog gaps can occur in the following situations:

• The oplog tailing stops because of an issue with a backup job tailing the oplog, and the oplog rolls over before MongoDB Agent tails it again.

• A topology change occurs, until Cloud Manager completes a new snapshot.

• A FCV change occurs, until Cloud Manager completes a new snapshot. You cannot apply a point-in-time restore across MongoDB version changes.

• A restore completes, until Cloud Manager completes a new snapshot.

If the restore time you need is not available in the dialog, investigate recent topology or FCV changes and review backup job history to understand why that period is not restorable.

For example, the restore dialog might show these restorable time ranges:

• June 8th 13:45:03 to June 8th 17:45:03

• June 8th 19:45:03 to June 9th 07:45:03

In this case, you cannot restore to any time between June 8th 17:45:03 and June 8th 19:45:03 because an oplog gap exists for that period.

Limitations

If you are restoring a sharded cluster, you must restore all shards. The restore process fails if you try to restore a single shard in a sharded cluster.

Prerequisites

To perform automated restores:

• Install an MongoDB Agent installed on the source and all target hosts, and check that an MongoDB Agent on the target deployment can connect to all hosts in the target deployment.

• Configure Backup Admin and Automation Admin roles in Cloud Manager.

• For sharded clusters running FCV 4.0 or earlier, enable checkpoints.

• Check that the target cluster's featureCompatibilityVersion is greater than or equal to the source cluster's featureCompatibilityVersion.

  Example

  Run the following command to retrieve the featureCompatibilityVersion of a given host:

  db.adminCommand( {
    getParameter: 1,
    featureCompatibilityVersion: 1
  } )

  To learn more, see setFeatureCompatibilityVersion.

• Review the following compatibility matrix for the supported source cluster FCV of each MongoDB version. The MongoDB version of each host in the target cluster must support the FCV of the snapshot of the source cluster.

Restore to Different Project

You can choose to restore to a cluster of a different project:

• To restore to another Cloud Manager project, you must have Automation Admin or Backup Admin roles for the target project.

• To restore to another MongoDB Atlas project, you must have Project Owner role for the target project.

Potential Causes for Automated Restore Failure

An automated restore can fail when certain storage settings of the backup's database and target database do not match:

• storage.engine
• storage.directoryPerDB

• storage.mmapv1.nsSize

• storage.mmapv1.smallFiles

• storage.wiredTiger.collectionConfig.blockCompressor
• storage.wiredTiger.engineConfig.directoryForIndexes

No method exists to check for mismatches before attempting a restore. If a restore attempt fails, Cloud Manager displays any mismatched settings. If you still want to restore the backup's database, fix the settings in the target database that do not match backup's database, then retry the restore process for the backup's database.

An automated restore fails when you attempt to restore a single shard in a sharded cluster. If you are restoring a sharded cluster, you must restore all shards.

Restore Procedures

To perform an automated restore, see the procedure for the deployment you want to restore:

• Replica Set
• Sharded Cluster

Prerequisites

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

Restore File Format

Cloud Manager provides each snapshot as an uncompressed (.tar) archive containing a complete copy of the data directory.

• For a replica set, Cloud Manager provides one snapshot that you copy to each replica set member.

• For a sharded cluster, Cloud Manager provides one snapshot for the config servers and one snapshot for each shard.

Manual Restore Procedures

To perform a manual restore, see:

• Restore a Single Database or Collection using Queryable Backup
• Restore a Replica Set
• Restore a Sharded Cluster

Restore Process Flows

You can restore from a completed snapshot or from a specific point in time. Use the following pages to learn about the manual restore process flows.