Docs Menu
Docs Home
/
MongoDB Atlas
/ /

Restore from a Scheduled or On-Demand Snapshot

On this page

  • Restore Considerations
  • Recommendations to Optimize Restore Times
  • Fallback Snapshots
  • Required Access
  • Procedure

Atlas lets you restore data from a scheduled or on-demand Cloud Backup, including snapshots from different projects or organizations. 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.

Note

You can only perform cross-organization restores through the Atlas UI.

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

  • If the DefaultRWConcern value on the source snapshot differs from the DefaultRWConcern value on the target cluster, Atlas overrides the value on the source snapshot with the value on the target cluster. If there is no value configured for the DefaultRWConcern on the target cluster, Atlas keeps the value of DefaultRWConcern from the snapshot without explicit configuration. This may differ from the default value for that MongoDB version.

  • This feature is not available for M0 clusters.

  • For M10+ dedicated clusters running MongoDB 4.2 or higher, Atlas restores Atlas Search index definitions from a Cloud Backup snapshot. Atlas doesn't restore search index data, so the mongot processes perform initial syncs for all restored search index definitions. If you've defined large search indexes on your cluster, you might experience delays during snapshot restorations.

    Note

    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.

If your cluster has been migrated from an M2 or M5 cluster to a Flex cluster, you have access to the last 8 backup snapshots since the date of the migration.

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

    Example

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

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.

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.

Atlas deletes all existing data on the target cluster prior to the restore. The target cluster is unavailable for the duration of the restore. As part of the restore, Atlas also restores any indexes.

To start a restore job for your project and cluster using the Atlas CLI, run the following command:

atlas backups restores start <automated|download|pointInTime> [options]

To watch for a specific restore job to complete using the Atlas CLI, run the following command:

atlas backups restores watch <restoreJobId> [options]

To learn more about the syntax and parameters for the previous commands, see the Atlas CLI documentation for atlas backups restores start and atlas backups restores watch.

Tip

See: Related Links

To start a restore job for your serverless instance using the Atlas CLI, run the following command:

atlas serverless backups restores create [options]

To watch the specified backup restore job until it completes using the Atlas CLI, run the following command:

atlas serverless backups restores watch [options]

To learn more about the syntax and parameters for the previous commands, see the Atlas CLI documentation for atlas serverless backups restores create and atlas serverless backups restores watch.

The Atlas Administration API provides different endpoints for restoring M10+ clusters, M2/M5 clusters and Serverless instances.

Restore One Snapshot of One Cluster Create One Restore Job from One M2 or M5 Cluster Restore One Snapshot of One Serverless Instance

1
  1. If it's not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

  2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

  3. If it's not already displayed, click Clusters in the sidebar.

    The Clusters page displays.

2
  1. Click your cluster's name.

  2. Click the Backup tab.

    If the cluster has no Backup tab, then Atlas backups are disabled for that cluster and no snapshots are available. You can enable backups when you scale the cluster.

    The Backup page displays.

3

Select the snapshot to restore and click Restore.

In the Actions column, expand the Actions menu, and click Restore for the snapshot that you want to restore.

4

In the modal window, select the target project and the target cluster from the dropdown menu. If the target cluster is part of a different project or organization than your source cluster, you can enter the name of and select the target project from the dropdown menu.

5

Follow the prompt and click Restore.

6

Restart your application and ensure it uses the new target cluster.

Back

Restore Sources