Restore Overview
On this page
- OAuth 2.0 authentication for programmatic access to Cloud Manager is available as a Preview feature.
- The feature and the corresponding documentation might change at any time during the Preview period. To use OAuth 2.0 authentication, create a service account to use in your requests to the Cloud Manager Public API.
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 all shards in a sharded cluster.
You can restore a deployment from an existing snapshot or a specific point in time. For the point in time, you can specify a date and time, an oplog timestamp, or a checkpoint for a sharded cluster.
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 choose.
To restore your backup, use one of these options:
Cancel a Restore
To cancel a restore:
Navigate to the Backup > Restore History tab.
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.
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'sfeatureCompatibilityVersion
.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.
Source Cluster FCV | MongoDB 4.0 | MongoDB 4.2 | MongoDB 4.4 | MongoDB 5.0 | MongoDB 6.0 |
---|---|---|---|---|---|
4.2 | |||||
4.4 | |||||
5.0 | |||||
6.0 |
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.mmapv1.nsSize
storage.mmapv1.smallFiles
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.
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.
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:
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:
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.