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.

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

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.

AWS Identity and Access Management (IAM)

Azure Key Vault

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:

From the Clusters view of the Atlas UI, click
on the cluster name.

Click the Backup tab, then click
Snapshots.

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 am 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:

From the Clusters view of the Atlas UI, click
on the cluster name.

Click the Backup tab, then click
Snapshots.

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

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
cloud region as the cluster. Atlas retains snapshots based
on the retention policy.

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

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.

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

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.

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.

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.

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

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

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.

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.

Atlas takes the first snapshot when you enable cloud provider
snapshots for a cluster and takes subsequent snapshots of the cluster
every 24 hours from that point in time. By default, Atlas retains
the last 3 snapshots for each cluster.

You can view and customize the snapshot schedule and retention settings:

From the Clusters view, click on the cluster name.

Click on the Backup tab.

Click Backup Policy.

Atlas displays the UTC snapshot time using the 24-hour clock format.
To modify the snapshot time, click the dropdown for the hr
or min and select your preferred hour or minute for
Atlas to take snapshots. The first snapshot taken after updating
the snapshot schedule occurs within 24 hours, breaking the default
behavior of one snapshot every 24 hours. All subsequent
snapshots occur once every 24 hours at the configured point in time.

Atlas displays the number of snapshots to retain in a text
input field. Type in your preferred number of snapshots for retention.
Changing the number of retained snapshots effects the total cost
of backups for the cluster. For complete documentation on cloud provider
snapshot billing, see Cloud Provider Snapshots.
If you decrease the number of retained snapshots, Atlas
immediately deletes the extra snapshots.

Click Save Changes to save any changes you’ve made to either
the snapshot schedule or retention settings.

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 OrganizationOwner or ProjectOwner
role to successfully call this endpoint.

To take an on-demand snapshot:

From the Clusters view, click the
ellipsis h icon
button
below the cluster name and select Take Snapshot Now.

In the On-Demand Snapshot modal, enter the following:

In the Retention box, enter the number of days that
you want Atlas to retain the snapshot.

In the Description box, enter a descriptive name
for the snapshot.

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.