> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Dedicated Cluster Backups **Note:** This page applies to both Atlas Infinite and Atlas Core. To restore an Atlas Infinite cluster, see [Restore an Atlas Infinite Cluster.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/atlas-infinite-restore.md#std-label-atlas-infinite-restore) **Note:** The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see [Shared Responsibility Model.](https://www.mongodb.com/resources/products/fundamentals/shared-responsibility) ## Single-Region Cluster Backups Single-region cluster backups apply to both Atlas Core clusters and Atlas Infinite clusters. Atlas Infinite cluster backups don't use snapshot storage volumes. Atlas selects new snapshot storage volumes for Atlas Core clusters only. With single-region cluster backups, Atlas: - Determines the order of nodes to try to snapshot using the following algorithm: Snapshots on a secondary. 1 Then, Snapshots the node with the lowest priority if possible. 2 Then, Snapshots incrementally from one snapshot to the next if possible. 3 Then, Snapshots node lexically first by hostname. 1 If there is a tie, Atlas skips to the next step to determine the node to snapshot. 2 If there is a tie, Atlas then favors the node that can be snapshotted incrementally from the previous snapshot (i.e., node using the same disk). 3 If there is a tie, Atlas then favors the node with the lexicographically smallest hostname. - Once the node order is determined, tries to snapshot a node. If a selected node is unhealthy, Atlas tries to snapshot the next node that it favors. - Stores the snapshots in the same cloud region as the cluster. - Retains snapshots based on your [retention policy.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/scheduling.md#std-label-cloud-provider-retention-policy) ![Cloud Backup of the Primary](/images/cloud-provider-snapshot-single-region-primary.svg) ![A Cloud Backup of the Secondary](/images/cloud-provider-snapshot-single-region-secondary.svg) Atlas automatically creates a new snapshot storage volume if the existing snapshot storage volume becomes invalid. Atlas creates the new volume in the same region as the cluster's current primary. Atlas then takes a full-copy snapshot to maintain backup availability and continues using that member and its corresponding region for further incremental snapshots. Events that can cause an election to select a new node for the snapshot storage volume include: - Changing the Atlas cluster tier, - Decreasing the Atlas cluster's storage volume, - Changing the Atlas cluster's region, and - Maintenance performed by Atlas or the cluster's cloud provider. **See also:** To learn more about snapshot retention, see [Backup Scheduling, Retention, and On-Demand Snapshots.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/scheduling.md#std-label-cloud-provider-retention-policy) ## Multi-Region Cluster Backups This section applies to Atlas Core clusters. With multi-region cluster backups, Atlas: - Determines the order of nodes to snapshot using the following algorithm: Snapshots in the highest priority region if possible. 1 Then, Snapshots on a secondary. 2 Then, Snapshots the node with the lowest priority if possible. 3 Then, Snapshots incrementally from one snapshot to the next if possible. 4 Then, Snapshots node lexically first by hostname. 1 If there is a tie, Atlas then compares based on the descending order of priority. 2 If there is a tie, Atlas skips to the next step to determine the node to snapshot. 3 If there is a tie, Atlas then favors the node that can be snapshotted incrementally from the previous snapshot (i.e., node using the same disk). 4 If there is a tie, Atlas then favors the node with the lexicographically smallest hostname. - Tries to snapshot a node once the node order is determined. If a selected node is unhealthy, Atlas tries to snapshot the next node that it favors. - Retains snapshots based on your [retention policy.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/scheduling.md#std-label-cloud-provider-retention-policy) ![Cloud Backup of the Primary](/images/cloud-provider-snapshot-multi-region-primary.svg) ![A Cloud Backup of the Secondary](/images/cloud-provider-snapshot-multi-region-secondary.svg) Atlas automatically creates a new snapshot storage volume if the existing snapshot storage volume becomes invalid. Atlas creates the new volume in the same region as the cluster's current primary. Atlas then takes a full-copy snapshot to maintain backup availability and continues using that member and its corresponding region for further incremental snapshots. Events that can cause an election to select a new node for the snapshot storage volume include: - Changing the Atlas cluster tier, - Decreasing the Atlas cluster's storage volume, - Changing the Atlas cluster's highest priority region, and - Maintenance performed by Atlas or the cluster's cloud provider. **See also:** To learn more about snapshot retention, see [Backup Scheduling, Retention, and On-Demand Snapshots.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/scheduling.md#std-label-cloud-provider-retention-policy) ## Global Cluster Backups This section applies to Atlas Core clusters. Atlas can back up [Global Clusters](https://www.mongodb.com/docs/atlas/global-clusters.md#std-label-global-clusters) using Cloud Backups as their backup method. Atlas restores the shards in the source cluster to the corresponding shards in the target cluster using the same order as specified in the cluster configuration. **Example:** `shard0` in the source cluster is restored to `shard0` in the target cluster. **Note:** If you used the API (Application Programming Interface) to create your Global Cluster, the zones are defined in the `replicationSpecs` parameter in the [Create One Cluster](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-creategroupcluster) and [Modify One Cluster](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-updategroupcluster) API (Application Programming Interface) endpoints. If the cluster configurations of the source and target clusters do not match, shard data may migrate to a different cloud provider zone than where it resided in the source cluster. After Atlas completes the restore operation, the MongoDB [balancer](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-balancer) for the target cluster migrates the data back to the zone where it resided in the source cluster if your clusters meet the following requirements: - Both clusters have enabled a Global Cluster on the same collection - Both clusters use the same [shard key](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-shard-key) for the Global Writes-enabled collection **Note:** If the Global Writes-enabled collection on the target cluster does not contain any data, the MongoDB balancer for the cluster automatically distributes any data that you later add to the collection among the target cluster's shards. To enable global writes on the target cluster: 1. In Atlas, go to the Data Explorer page 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 Data Explorer under the Database heading. The [Data Explorer](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fmetrics%2FreplicaSet%2F%3Creplset%3E%2Fexplorer) displays. IMPORTANT: You can also click the name of a cluster to open the Cluster sidebar, and then click Data Explorer under the Shortcuts heading. 2. Enable global writes. Click Enable Global Writes. ## Continuous Cloud Backups Continuous Cloud Backups replay the [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) to restore a cluster from a particular point in time within a window specified in the Backup Policy. Atlas enables [Continuous Cloud Backup restores](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-create-cluster-backups) by default when you create a new cluster. Configure your continuous cloud backup window with the [Backup Policy Editor.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/scheduling.md#std-label-cps-backup-policies) **Note:** On Atlas Core clusters, enabling continuous cloud backups increases the monthly cost of your cluster. On Atlas Infinite clusters, continuous cloud backup within the default 24-hour window is included at no additional cost. Continuous Cloud Backup is always enabled on Atlas Infinite clusters, and you can't disable it. To learn more about the cost implications, see [billing.](https://www.mongodb.com/docs/atlas/billing/cluster-configuration-costs.md#std-label-billing-backup-cloud-provider-snapshots) Your cluster's snapshots stay within the cloud provider's storage service under the cluster or shard's [highest priority region](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-deploy-across-multiple-regions). Oplog data for Continuous Cloud Backup is stored in the same cloud provider region as your snapshots. Oplog backups on AWS (Amazon Web Services) clusters use standard AWS (Amazon Web Services) S3 (Simple Storage Service) encryption and Google Cloud clusters use standard [Google Cloud Storage](https://cloud.google.com/storage) encryption. In single-region and multi-region sharded clusters, Atlas creates a separate backup for each shard in the shard's primary region. **Note:** Clusters with continuous cloud backups enabled store [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) data in object storage according to your cloud provider: - S3 (Simple Storage Service) for AWS (Amazon Web Services) - Azure Blob Storage for Azure (Microsoft Azure) - Google Cloud Storage for Google Cloud The following actions cause all existing oplog backups to be deleted. All existing snapshots remain intact, but Atlas removes previously preserved oplog data when: - You disable continuous cloud backups for your cluster. - The cluster receives an excessive number of writes. The cluster processes a large number of writes that causes the oplog to roll over before backup collects it. **Example:** 1. You sized your oplog for one hour of its usual write traffic, say 1,000 operations. 2. Database activity results in a large number of writes to the oplog, say 2,000 operations. 3. The number of writes result in the oplog dropping older records. This example would lose 1,000 operations. 4. Backup should collect operation #1, but it collects #1,001 instead. If you [change](https://www.mongodb.com/docs/atlas/tutorial/move-cluster.md#std-label-move-cluster) your cluster's [highest priority region](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-deploy-across-multiple-regions) or if MongoDB migrates oplog data to a different region: - Atlas retains data in both the old and new regions until your continuous cloud backup window is represented in the new region. Once the continuous cloud backup window is represented in the new region, Atlas deletes the data in the old region. - You will be billed for storage in both the old and new regions for the days following the region change. You must disable continuous cloud backup and reenable it to prevent billing in both regions. **Note:** If you disable continuous cloud backup, Atlas will delete the continuous cloud backup history. When you use continuous cloud backups to restore a cluster from a previous point in time, Atlas retains the cluster's [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog). You can use continuous cloud backups repeatedly to restore the cluster to any point in its continuous cloud backup window **except** between when you initiated a restore and when Atlas completes a snapshot after the restore. ## Consistency and Snapshots On Atlas Core clusters, Atlas maintains [causal consistency](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency/#std-label-sessions) when it takes snapshots except for the size statistics that [collStats](https://www.mongodb.com/docs/manual/reference/command/collStats/#mongodb-dbcommand-dbcmd.collStats) and `db.[collection].count()` report. The size statistics that [collStats](https://www.mongodb.com/docs/manual/reference/command/collStats/#mongodb-dbcommand-dbcmd.collStats) and `db.[collection].count()` report might be inaccurate. Atlas coordinates the time across all shards for sharded clusters to ensure that snapshots include all documents written to every shard and node as of the scheduled snapshot time. ### View `M10+` Backup Snapshots ### Atlas CLI To list cloud backup snapshots for your project and cluster using the Atlas CLI, run the following command: ```sh atlas backups snapshots list [options] ``` To return the details for the snapshot you specify using the Atlas CLI, run the following command: ```sh atlas backups snapshots describe [options] ``` To learn more about the syntax and parameters for the previous commands, see the Atlas CLI documentation for [atlas backups snapshot list](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-backups-snapshots-list/) and [atlas backups snapshots describe.](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-backups-snapshots-describe/) **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/) **Note:** 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.