Docs Menu

Docs HomeMongoDB Atlas

Restore from a Scheduled or On-Demand Snapshot

On this page

  • Restore Considerations
  • Sharded Clusters
  • M2/M5 Clusters
  • Serverless Instances
  • Recommendations to Optimize Restore Times
  • Fallback Snapshots
  • Procedure
  • Restore a Cluster
  • Restore a Serverless Instance
  • Click the Backup tab.

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.

In addition to the prerequisites, consider the following requirements and limitations when restoring from a scheduled or on-demand Cloud Backup.

  • This feature is not available for M0 clusters.

  • For M10+ dedicated clusters running MongoDB 4.2 or higher, Atlas can restore Atlas Search indexes from a Cloud Backup snapshot.


    When you restore the data from the snapshot, the Atlas Search index definitions from the snapshot replace any existing Atlas Search index definitions.

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

  • Starting with MongoDB 5.0, you can restore snapshots of clusters that run only the two most recent major versions of MongoDB to M2 and M5 clusters.


    • You can restore snapshots taken from clusters that run MongoDB 4.2 to an M2 or M5 cluster that runs MongoDB 5.0.

    • You can't restore snapshots taken from clusters that run MongoDB 4.0 to an M2 or M5 cluster that runs MongoDB 5.0.

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

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.

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.


Restoring your cluster from a fallback snapshot may result in inconsistent data across your cluster, and should be considered an option of last resort.


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.

←  Restore Your Database DeploymentRestore from Continuous Cloud Backup →
Share Feedback
© 2023 MongoDB, Inc.


  • Careers
  • Investor Relations
  • Legal Notices
  • Privacy Notices
  • Security Information
  • Trust Center
© 2023 MongoDB, Inc.