Navigation

Cloud Provider Snapshots

Feature unavailable in Free and Shared Tier Clusters

This feature is not available for M0 (Free Tier), M2, and M5 clusters. To learn more about which features are unavailable, see Atlas M0 (Free Tier), M2, and M5 Limitations.

Atlas Cloud Provider Snapshots provide localized backup storage using the native snapshot functionality of the cluster’s cloud service provider.

Atlas supports cloud provider snapshots for Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP) backed clusters.

You can enable cloud provider snapshots during the cluster creation or during the modification of an existing cluster. From the cluster configuration modal, toggle Do you want to enable backup? to Yes and select the Cloud Provider Snapshots card.

Important

Atlas only allows one backup method per project. Once you select a backup method for a cluster in a project, Atlas locks the backup service to the chosen method for all subsequent clusters in that project.

For example, in a project where one or more clusters use cloud provider snapshots, you cannot enable continuous backups for any cluster in that project.

To change the backup method for the project, disable backups for all clusters in the project, then re-enable backups using your preferred backup methodology. Atlas deletes any stored snapshots when you disable backup for a cluster.

Consider creating a separate project for clusters where a different backup method is required.

Note

Atlas supports Cloud Provider Snapshots for sharded clusters running MongoDB version 3.4+ with the following limitations:

  • Atlas does not guarantee causal consistency of your data.
  • You cannot restore an existing snapshot to a cluster after you change that cluster’s topology by adding or removing a shard. However, you can restore an existing snapshot to another cluster with a matching topology.
  • You cannot manually migrate chunks in a cluster during a snapshot without the risk of creating an inconsistent snapshot.

Cloud Provider Snapshots with Encryption at Rest

Atlas encrypts all snapshot volumes, ensuring the security of cluster data at rest (Encryption at Rest). For projects and clusters using Encryption at Rest Using Your Key Management, Atlas applies an additional layer of encryption to your snapshot storage volumes using the Key Management Service (KMS) provider configured for the cluster.

For clusters using AWS IAM as their Key Management Service, Atlas uses the project’s customer master key (CMK) and AWS IAM user credentials at the time of the snapshot to automatically encrypt the snapshot data files. This is an additional layer of encryption on the existing encryption applied to all Atlas storage and snapshot volumes.

Atlas stores the unique ID of the CMK and the AWS IAM user credentials used to access the CMK. Atlas uses this information when restoring the snapshot. For complete documentation on restoring an encrypted snapshot, see Restore a Snapshot of a Cluster with Encryption at Rest.

To view the key used to encrypt a snapshot:

  1. From the Clusters view of the Atlas UI, click on the cluster name.
  2. Click the Backup tab, then click Snapshots.
  3. Note the Encryption Key ID for each snapshot in the cluster. Atlas lists the CMK used to encrypt the snapshot. Unencrypted snapshots display Not enabled.

Important

Atlas requires access to the encryption key associated to the snapshot’s Encryption Key ID to successfully restore that snapshot.

Before deleting an Encryption Key ID used with Atlas Encryption at Rest using your Key Management, check every backup-enabled cluster in the project for any snapshots still using that Encryption Key ID. Once you delete an encryption key, all snapshots encrypted with that key become inaccessible and unrecoverable.

Atlas automatically deletes backups in accordance to the Snapshot Scheduling and Retention Policy. Once Atlas deletes all snapshots depending on a given Encryption Key ID, you can delete the key safely.

If disabling a Encryption Key ID, you must re-enable the key before restoring a snapshot encrypted with that key.

For clusters using Azure Key Vault as their Key Management Service, Atlas uses the project’s Key Identifier, Key Vault Credentials, and Active Directory application account credentials at the time of the snapshot to automatically encrypt the snapshot data files. This is an additional layer of encryption on the existing encryption applied to all Atlas storage and snapshot volumes.

Atlas stores the unique ID of the Azure Key Identifier used the encrypt the snapshot. Atlas also stores the Azure Key Vault credentials and the Active Domain application account credentials used to access the Key Identifier. Atlas uses this information when restoring the snapshot. For complete documentation on restoring an encrypted snapshot, see Restore a Snapshot of a Cluster with Encryption at Rest.

To view the key used to encrypt a snapshot:

  1. From the Clusters view of the Atlas UI, click on the cluster name.
  2. Click the Backup tab, then click Snapshots.
  3. Note the Encryption Key ID for each snapshot in the cluster. Atlas lists the Key Identifier used to encrypt the snapshot. Unencrypted snapshots display Not enabled.

Important

Atlas requires access to the encryption key associated to the snapshot’s Encryption Key ID to successfully restore that snapshot.

Before deleting an Encryption Key ID used with Atlas Encryption at Rest using your Key Management, check every backup-enabled cluster in the project for any snapshots still using that Encryption Key ID. Once you delete an encryption key, all snapshots encrypted with that key become inaccessible and unrecoverable.

Atlas automatically deletes backups in accordance to the Snapshot Scheduling and Retention Policy. Once Atlas deletes all snapshots depending on a given Encryption Key ID, you can delete the key safely.

If disabling a Encryption Key ID, you must re-enable the key before restoring a snapshot encrypted with that key.

For complete documentation on configuring Encryption at Rest using your Key Management for an Atlas project, see Encryption at Rest Using Your Key Management. You can then either deploy a new cluster enable an existing cluster with Encryption at Rest using your Key Management.

Single Region Cluster Backups

Atlas selects the primary member of the cluster at the time you enable snapshots for the cluster. Atlas stores the snapshots in the same cloud region as the cluster. Atlas retains snapshots based on the retention policy.

Cloud Provider Snapshot of the Primary

Atlas continues to use that member and its corresponding region for snapshots and snapshot storage, even if that member is no longer the primary.

A Cloud Provider Snapshot of the Secondary

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 trigger storage invalidation include:

  • Changing the Atlas cluster instance size,
  • Modifying the Atlas cluster’s storage volume or speed,
  • Changing the Atlas cluster’s AWS region, and
  • Maintenance performed by Atlas or AWS.

To manually reset the snapshot target and storage, disable and re-enable backups for the cluster. Disabling Atlas backups removes all snapshots for the cluster. For more information on snapshot retention, see Snapshot Scheduling and Retention Policy.

Atlas always selects the primary member of the cluster for backup snapshots and stores the snapshots in the same cloud region as the cluster. Atlas retains snapshots based on the retention policy.

Cloud Provider Snapshot of the Primary

If that member steps down to a secondary, Atlas changes the snapshot target to the current primary.

A Cloud Provider Snapshot of the Former Primary

Multi-Region Cluster Backups

Atlas selects the primary member of the cluster at the time you enable snapshots for the cluster for backup snapshots. Atlas stores the snapshots in the same region as the primary member. Atlas retains snapshots based on the retention policy.

Cloud Provider Snapshot of the Primary

If the member steps down to a secondary, Atlas continues to use that member for snapshots. Atlas continues storing snapshots in the same region as that member, even if the primary is in a different region.

A Cloud Provider Snapshot of the Secondary

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 trigger storage invalidation include:

  • Changing the Atlas cluster instance size,
  • Modifying the Atlas cluster’s storage volume or speed,
  • Changing the Atlas cluster’s AWS region, and
  • Maintenance performed by Atlas or AWS.

To manually reset the snapshot target and storage, disable and re-enable backups for the cluster. Disabling Atlas backups removes all snapshots for the cluster. For more information on snapshot retention, see Snapshot Scheduling and Retention Policy.

Atlas always selects the primary member of the cluster for backup snapshots and stores the snapshots in the same region as the primary member. Atlas retains snapshots based on the retention policy.

Cloud Provider Snapshot of the Primary

If that member steps down to a secondary, Atlas changes the snapshot target to the current primary.

A Cloud Provider Snapshot of the Former Primary

Atlas stores subsequent snapshots in the region of the new primary member.

Global Cluster Backups

Atlas provides backups for Global Clusters using Cloud Provider Snapshots 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. For example, shard0 in the source cluster is restored to shard0 in the target cluster.

Note

If you used the API to create your Global Cluster, the zones are defined in the replicationSpecs parameter in the Create a Cluster and Modify a Cluster APIs.

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 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 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. Click Collections beneath the target cluster on the Clusters page.
  2. Click Enable Global Writes.

Snapshot Scheduling and Retention Policy

Use the Backup Policy Editor to configure a backup policy for Cloud Provider Snapshots.

  1. From the Clusters view, click the cluster name.
  2. Click the Backup tab.
  3. Click Backup Policy.

Each backup policy consists of a snapshot time and one or more policy items. The backup policy time specifies the time of day, in UTC, that Atlas takes snapshots for the backup policy. Snapshots taken for the hourly policy item may occur multiple times each day, depending on the frequency interval specified. Each backup policy item specifies a frequency unit and interval and a retention time.

For example, the default backup policy specifies a snapshot time of UTC 18:00 and the following four policy items:

  • Hourly snapshot with an interval of one hour and a retention of two days
  • Daily snapshot with a retention of seven days
  • Weekly snapshot with an interval of Saturday and a retention of four weeks
  • Monthly snapshot with an interval of the last day of the month and a retention of twelve months

For complete documentation on cloud provider snapshot billing, see Cloud Provider Snapshots.

Changing the Backup Policy Time

To modify the backup policy time:

  1. In the Backup Policy Editor, select the hour at which Atlas takes a snapshot each day from hr beneath Snapshot Time (UTC).
  2. Select the number of minutes after hr at which Atlas takes a snapshot from min beneath Snapshot Time (UTC).
  3. Click Save Changes.

Configuring the Backup Policy

Each row in the Backup Policy Frequency and Retention table represents a backup policy item. Configure the policy items and, optionally, add new policy items to configure a new backup policy.

Tip

Atlas displays an estimate of the total snapshot count associated with your changes below the Backup Policy Frequency and Retention table.

To specify a backup policy item:

  1. Select the frequency unit from Frequency Unit for a policy item.

    Alternatively, click Add Frequency Unit to add a new policy item to the backup policy.

    Note

    You cannot specify multiple Hourly and Daily backup policy items.

  2. Select the frequency for the frequency unit from Every.

  3. Specify the retention time for the policy item in Retention Time and the units for the retention time from the list to the right.

    Note

    Atlas requires that the value specified for Retention Time for less frequent policy items be equal to or larger than the value specified for more frequent policy items. For example, if the hourly policy item specifies a retention of two days or greater, the retention for the weekly snapshot must be two weeks or greater.

  4. (Optional) To apply the retention changes in the updated backup policy to snapshots that Atlas took previously, check Apply policy retention changes to existing snapshots.

    Note

    This option affects only snapshots created by the updated policy items and whose retention has not been updated individually with the Modify Cloud Provider Snapshot Schedule API.

  5. Click Save Changes.

Note

To take a snapshot sooner than the next scheduled snapshot, use the Take One On-Demand Snapshot API.

Note

If overlapping policy items generate the same snapshot, Atlas associates the snapshot with the policy item with the longest retention time. For example, if the policy specifies a daily snapshot with a retention of two days and a weekly snapshot every Saturday with a retention of three weeks, Atlas must choose which frequency unit to associate with the snapshot taken on Saturday, hourly or weekly. Since the frequency interval for the weekly policy item is larger than that specified for the hourly policy item, Atlas displays a frequency of Weekly in the Frequency column on the Snapshots page for the snapshot taken on Saturday.

Important

If you disable cloud provider snapshots for a cluster or terminate a cluster that had snapshots enabled, Atlas immediately deletes the backup snapshots for that cluster. For clusters not using Encryption at Rest Using Your Key Management you can download the latest snapshot to preserve any data stored in the cluster.

Viewing Snapshots

Atlas displays existing snapshots on the Snapshots page. To view snapshots that Atlas has already taken:

  1. From the Clusters view, click the cluster name.
  2. Click the Backup tab.
  3. Click Snapshots.

By default, Atlas displays both on-demand and policy-based snapshots. To view only policy-based snapshots:

  1. Click Policy under View Snapshots by.

    Alternatively, click On-demand to display only snapshots taken by clicking Take Snapshot Now.

Snapshots taken according to the backup policy display the frequency of the policy item that generated the snapshot in the Frequency column: Monthly, Weekly, Daily, or Hourly.

Note

If overlapping policy items generate the same snapshot, Atlas associates the snapshot with the policy item with the longest retention time. For example, if the policy specifies a daily snapshot with a retention of two days and a weekly snapshot every Saturday with a retention of three weeks, Atlas must choose which frequency unit to associate with the snapshot taken on Saturday, hourly or weekly. Since the frequency interval for the weekly policy item is larger than that specified for the hourly policy item, Atlas displays a frequency of Weekly in the Frequency column on the Snapshots page for the snapshot taken on Saturday.

On-Demand Snapshots

Atlas takes on-demand snapshots immediately, unlike scheduled snapshots which occur at regular intervals. If there is already an on-demand snapshot with a status of queued or inProgress, you must wait until Atlas has completed the on-demand snapshot before taking another. If there is already a scheduled snapshot with a status of queued or inProgress, you may queue an on-demand snapshot. You must have the Organization Owner or Project Owner role to successfully call this endpoint.

To take an on-demand snapshot:

  1. From the Clusters view, click the ellipsis h icon button below the cluster name and select Take Snapshot Now.
  2. In the On-Demand Snapshot modal, enter the following:
    1. In the Retention box, enter the number of days that you want Atlas to retain the snapshot.
    2. In the Description box, enter a descriptive name for the snapshot.
  3. Click Take Snapshot.

Click the Backup tab, then click Snapshots for the cluster to view the on-demand snapshot.

Note

The Take Snapshot Now button also appears on the Snapshots page for the cluster.