• Back Up and Restore Deployments >
• Restore MongoDB Deployments >
• Restore Overview

Restore Overview

To restore a deployment from a backup, select a snapshot or point in time from which you want to restore your database. Cloud Manager provides you with the files from which you can restore your database.

You can restore a single MongoDB database, a replica set, or a sharded cluster. You may select to restore from:

• An existing snapshot,
• A specific point in time by selecting:
  • A specific date and time,
  • A specific oplog timestamp, or
  • A specific sharded cluster checkpoint.

If you are restoring from a point in time, you must download the MongoDB Backup Restore Utility to your target host. The MBRU requests and applies oplog entries between the latest complete snapshot and the point in time you chose.

Note

For sharded clusters running FCV 4.0 or earlier, enable checkpoints before restoring to a point between snapshots.

You can restore your backup in one of the following ways:

• Cloud Manager can restore the files to another cluster if you use Cloud Manager automation.
• You can copy restored files manually to the hosts you choose.
• You can restore from a queryable backup.

To cancel a restore:

1. Navigate to the Backup > Restore History tab.
2. Click Cancel.

Automated Restore

If you choose to have Cloud Manager automation restore your backup, the Automation removes all existing data from the target hosts and replaces that data with new backup data from your snapshot.

Prerequisites

To perform automated restores, you must have:

• An MongoDB Agent installed on the source and all target hosts.

• A MongoDB Agent on the target deployment that can connect to all hosts in the target deployment.

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

• A target cluster whose 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:

  copy

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

  The featureCompatibilityVersion of each host in the target cluster must be greater than or equal to the featureCompatibilityVersion of any host in the source cluster.

  To learn more about changing the featureCompatibilityVersion flag, see setFeatureCompatibilityVersion.

• The following compatibility matrix lists 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.

Source Cluster FCV	MongoDB 3.4	MongoDB 3.6	MongoDB 4.0	MongoDB 4.2	MongoDB 4.4
3.4	check circle icon	check circle icon
3.6		check circle icon	check circle icon
4.0			check circle icon	check circle icon
4.2				check circle icon	check circle icon
4.4					check circle icon

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 restoring the backup’s database.

Important

MongoDB removed support for the MMAPv1 storage engine in MongoDB 4.2. If you edit your deployment’s configuration to change your storage engine to WiredTiger Storage Engine, Cloud Manager restarts the MongoDB processes.

Restore Procedures

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

• Replica Set
• Sharded Cluster

Manual Restore

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 the procedure for the deployment you want to restore:

• 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 shapshot or from a specific point in time. Use the following pages to learn about the manual restore process flows.

←   Restore MongoDB Deployments Restore a Sharded Cluster from a Snapshot  →

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