> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Restore from a Scheduled or On-Demand Snapshot 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.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-ear.md#std-label-restore-from-ear) **Note:** This page applies to Atlas Core only. To learn about Atlas Infinite restores, see [Restore an Atlas Infinite Cluster.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/atlas-infinite-restore.md#std-label-atlas-infinite-restore) You can restore [selected databases or collections](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-db-coll.md#std-label-restore-from-db-coll) from a snapshot. To learn more, see [Restore from Selected Databases and Collections.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-db-coll.md#std-label-restore-from-db-coll) **Note:** You can only perform cross-organization restores through the Atlas UI. ## Restore Considerations In addition to the [prerequisites](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-overview.md#std-label-restore-prereq), 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 Free clusters (formerly known as `M0`). * For `M10+` dedicated clusters, Atlas restores MongoDB Search [index definitions](https://www.mongodb.com/docs/search/indexes/index-definitions.md#std-label-ref-index-definitions) from a Cloud Backup snapshot. Atlas doesn't restore search index data, so the `mongot` processes perform [initial syncs](https://www.mongodb.com/docs/manual/core/replica-set-sync.md#std-label-replica-set-initial-sync) 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 MongoDB Search index definitions from the snapshot replace any existing MongoDB 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. - The source and target clusters must use the same type of [config server](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-sharding-config-server). Config servers can be either [config shards](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-sharded-cluster-config-server-config-shards) or dedicated config servers. - Atlas can't restore a sharded cluster snapshot to a replica set, or restore a replica set snapshot to a sharded cluster. ### Flex Clusters - Atlas can't restore snapshots from Flex clusters, dedicated clusters, or Cloud Manager to a Flex cluster. - A Flex cluster allows you to have only two snapshots. If you require having more snapshots, upgrade your cluster to a dedicated cluster. ## Requirements for Using Faster Cross-Project Restores To take advantage of faster cross-project restores and to optimize performance and reduce the amount of time it takes to restore, you must follow all of these principles where they are applicable: - Select a target cluster that isn't global or multi-cloud. - Select a multi-region target 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 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 (Amazon Web Services) with configured IOPS (Input/Output Operations per Second), select the configured IOPS (Input/Output Operations per Second) to fall within the configured range. - Select a target cluster that is not configured to use NVMe (non-volatile memory express) storage. NVMe (non-volatile memory express) storage degrades restore performance. - For AWS (Amazon Web Services) source clusters created before March 27, 2024, click the Faster Restore button in the cluster's [Backup](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fbackup%2Fclusters) details in Atlas UI to enable faster cross-project restores using the direct attach restore method. The target cluster must meet all conditions listed in this section to use this feature. When you activate Faster Restore, Atlas replaces each node in the source cluster one at a time during your next [maintenance window](https://www.mongodb.com/docs/atlas/tutorial/cluster-maintenance-window.md#std-label-configure-maintenance-window). If the maintenance window ends before all nodes are replaced, Atlas finishes replacing the current node, then waits for the next maintenance window to start replacing the next node. Secondary reads and analytic nodes are unavailable during the rolling replacement. Faster cross-project restores are automatically enabled for AWS (Amazon Web Services) clusters created after March 27, 2024, all Google Cloud and Microsoft Azure clusters, and all clusters in MongoDB Atlas for Government. If this feature is enabled for your cluster, the Faster Restore button doesn't appear. ## 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 monitor a backup restore job until it completes, you must have [`Project Read Only`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Read-Only) access or higher to the specific project. To start a restore job, you must have [`Project Backup Recovery Operator`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Backup-Recovery-Operator), [`Project Backup Manager`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Backup-Manager), or [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) access to the project. For cross-organization or cross-project restores, the required permissions apply to both the source and target projects. You must have the necessary permissions: [`Project Backup Manager`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Backup-Manager) or [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) in both projects to initiate or manage such restore operations. ## Procedure When you perform a cluster-level restore, Atlas deletes all existing data on the target cluster before the restore. The target cluster is unavailable for the duration of the restore. As part of the restore, Atlas also restores any indexes. This does *not* apply to collection- and database-level restore. To start a restore job for your project and cluster using the Atlas CLI, run the following command: ```sh atlas backups restores start [options] ``` To watch for a specific restore job to complete using the Atlas CLI, run the following command: ```sh atlas backups restores watch [options] ``` To learn more about the syntax and parameters for the previous commands, see the Atlas CLI documentation for [atlas backups restores start](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-backups-restores-start/) and [atlas backups restores watch.](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-backups-restores-watch/) **See also: Related Links** - [Install the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/install-atlas-cli/) - [Connect to the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/connect-atlas-cli/) The Atlas Administration API provides different endpoints for restoring `M10+` clusters and Flex clusters. [Restore One Snapshot of One Cluster](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-creategroupclusterbackuprestorejob) [Flex Clusters Restore Jobs](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/group/endpoint-flex-restore-jobs) 1. In Atlas, go to the Backup details for your project. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar. If it's not already displayed, select your project from the Projects menu in the navigation bar. In the sidebar, click Backup under the Database heading. The [Backup](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fbackup%2Fclusters) details display. Click the cluster link. 2. 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. 3. Select cluster-level restore. In the Source Details pane, select Restore entire snapshot. Click Continue. 4. Specify the restore target. In the Destination pane, select the project that hosts the restore target cluster from the Destination Project dropdown. Select the restore target cluster from the Destination Cluster dropdown. The source project and cluster of the snapshot appears with the Source label. Click Continue. 5. Review restore job details and initiate the restore. Verify that the details of the restore job are correct. Type the destination cluster name to confirm the action where prompted. Click Start Restore. 6. Restart your application and ensure it uses the new target cluster.