Restore from a Scheduled or On-Demand Snapshot
On this page
Atlas lets you restore data from a scheduled or on-demand Cloud Backup. The following sections describe restoring from a snapshot without Encryption at Rest using Customer Key Management. To restore from a snapshot using Encryption at Rest using Customer Key Management, see Restore from a Snapshot Using Encryption at Rest.
Restore Considerations
In addition to the prerequisites, consider the following requirements and limitations when restoring from a scheduled or on-demand Cloud Backup.
If the
DefaultRWConcernvalue on the source snapshot differs from theDefaultRWConcernvalue on the target database deployment, Atlas overrides the value on the source snapshot with the value on the target database deployment. If there is no value configured for theDefaultRWConcernon the target database deployment, Atlas keeps the value ofDefaultRWConcernfrom the snapshot without explicit configuration. This may differ from the default value for that MongoDB version.
This feature is not available for
M0clusters.For
M10+dedicated clusters running MongoDB 4.2 or higher, Atlas can restore Atlas Search indexes from a Cloud Backup snapshot.Note
When you restore the data from the snapshot, the Atlas Search index definitions from the snapshot replace any existing Atlas Search index definitions.
Sharded Clusters
If you are restoring from a sharded cluster, the source and target clusters must have the same number of shards.
Atlas can't restore a sharded cluster snapshot to a replica set.
M2/M5 Clusters
Starting with MongoDB 5.0, you can restore snapshots of clusters that run only the two most recent major versions of MongoDB to
M2andM5clusters.Example
You can restore snapshots taken from clusters that run MongoDB 4.2 to an
M2orM5cluster that runs MongoDB 5.0.You can't restore snapshots taken from clusters that run MongoDB 4.0 to an
M2orM5cluster that runs MongoDB 5.0.
Serverless Instances
Atlas can't restore snapshots from shared clusters, dedicated clusters, or Cloud Manager to a serverless instance.
If you are restoring from a serverless instance, you can only restore the two most recent snapshots.
Recommendations to Optimize Restore Times
To optimize performance and reduce the amount of time it takes to restore, follow these principles where applicable:
Select a target cluster that isn't global or multi-cloud.
Select a multi-region cluster only if copies of the snapshot you plan to restore exist in every region of that cluster.
Select a target cluster that belongs to the same Atlas project and the same cloud provider region as the snapshot.
Select a cluster tier with the same storage capacity as the capacity of the original volume used by the source cluster.
If the target cluster runs on AWS with configured IOPS, select the configured IOPS to fall within the configured range.
Select a cluster that is not configured to use NVMe storage. NVMe storage degrades restore performance.
Fallback Snapshots
If a scheduled snapshot fails for any reason, Atlas attempts to repeat the snapshot process. If necessary, you may use the resulting fallback snapshot to restore the cluster. This isn't recommended: fallback snapshots use a different process from regular snapshots. They may contain inconsistent data.
Fallback snapshots are marked in the UI with a warning icon, and a warning message appears in the restore modal window if the restore uses a fallback snapshot.
Warning
Restoring your cluster from a fallback snapshot may result in inconsistent data across your cluster, and should be considered an option of last resort.
Required Access
To start a restore job, you must have Project Owner
access or higher to the project.
To watch a backup restore job until it completes, you must have
Project Read Only access or higher to the project.
Procedure
Important
Atlas deletes all existing data on the target database deployment prior to the restore. Depending on the type of restore taking place, the target cluster may be unavailable for the duration of the restore.