Cloud Backups¶

Encryption at Rest using Customer Key Management¶

Atlas encrypts the storage engine of all snapshot volumes, ensuring the security of cluster data at rest. For projects and clusters using Encryption at Rest using Customer 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.

To view the key used to encrypt a snapshot:

1. Click Databases in the top-left corner of Atlas.
2. From the Database Deployments view of the Atlas UI, click on the cluster name.
3. Click the Backup tab, then click Snapshots.
4. 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.

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

Single-Region Cluster Backups¶

With single-region cluster backups, Atlas:

• Determines the order of nodes to try to snapshot using the following algorithm:

  1. Snapshots on a secondary. ¹ Then,
  2. Snapshots the node with the lowest priority if possible. ² Then,
  3. Snapshots incrementally from one snapshot to the next if possible. ³ Then,
  4. Snapshots node lexically first by hostname.

  ¹ If there is a tie, Atlas skips to the next step to determine the node to snapshot.

  ² 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).

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

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,
• Modifying the Atlas cluster's storage volume or speed,
• Changing the Atlas cluster's region, and
• Maintenance performed by Atlas or the cluster's cloud provider.

Multi-Region Cluster Backups¶

With multi-region cluster backups, Atlas:

• Determines the order of nodes to snapshot using the following algorithm:

  1. Snapshots in the highest priority region if possible. ¹ Then,
  2. Snapshots on a secondary. ² Then,
  3. Snapshots the node with the lowest priority if possible. ³ Then,
  4. Snapshots incrementally from one snapshot to the next if possible. ⁴ Then,
  5. Snapshots node lexically first by hostname.

  ¹ If there is a tie, Atlas then compares based on the descending order of priority.

  ² If there is a tie, Atlas skips to the next step to determine the node to snapshot.

  ³ 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).

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

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,
• Modifying the Atlas cluster's storage volume or speed,
• Changing the Atlas cluster's highest priority region, and
• Maintenance performed by Atlas or the cluster's cloud provider.

Global Cluster Backups¶

Atlas can back up 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.

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

To enable global writes on the target cluster:

1. Click Databases in the top-left corner of Atlas.
2. Click Browse Collections beneath the target cluster on the Database Deployments page.
3. Click Enable Global Writes.

Continuous Cloud Backups¶

Continuous Cloud Backups replay the oplog to restore a cluster from a particular point in time within a window specified in the Backup Policy.

You may opt to enable Continuous Cloud Backup restores. Configure your continuous cloud backup window with the Backup Policy Editor.

Your cluster's snapshots stay within the cloud provider's storage service under the cluster or shard's highest priority region. Oplog backups on AWS clusters use standard AWS S3 encryption.

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.
• Perform a restore into the cluster.

If you change your cluster's highest priority region 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.

Snapshot Scheduling and Retention Policy¶

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

1. Click Databases in the top-left corner of Atlas.
2. From the Database Deployments view, click the cluster name.
3. Click the Backup tab.
4. Click Backup Policy.

A backup policy has the following sections:

• A time of day, in UTC, at which to create snapshots.
• A frequency interval and duration of retention.
• If PIT Restores are enabled, a PIT window that allows you to restore to any point in time in the last X days where X is the window.

To learn more about Cloud Backup billing, see Cloud Backups.

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. Click Databases in the top-left corner of Atlas.
2. From the Database Deployments view, click the button below the cluster name then click Take Snapshot Now.

3. 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.
4. Click Take Snapshot.

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