> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# Guidance for Atlas Disaster Recovery

Disaster recovery (DR) is a resilience strategy that uses manual procedures to recover your deployment when automatic failover cannot help. Unlike [high availability](https://www.mongodb.com/docs/atlas/architecture/current/high-availability.md#std-label-arch-center-high-availability), which provides automatic self-healing for infrastructure failures, disaster recovery requires human intervention to restore from backups.

**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)

## When to Use Disaster Recovery

**Important:**

Prefer [high availability](https://www.mongodb.com/docs/atlas/architecture/current/high-availability.md#std-label-arch-center-high-availability) when possible. Use disaster recovery as your primary resilience strategy only when high availability is not feasible.

Disaster recovery is appropriate as your primary resilience strategy in the following situations:

**Geographic Constraints**

You cannot deploy to multiple regions with sufficient availability zones. For example, if you must deploy in Canada, only 2 regions are available, preventing automatic failover quorum requirements.

**Cost Optimization**

Your budget requires minimizing infrastructure costs. Multi-region or multi-cloud high availability deployments cost more than single-region deployments with backups.

**Tolerance for Manual Recovery**

Your application can tolerate the time required for manual intervention and backup restoration (RTO (Recovery Time Objective) in minutes to hours rather than seconds).

**Note:**

Even if you use high availability, you might benefit from disaster recovery procedures for scenarios that automatic failover cannot address, such as data corruption or accidental deletion. To learn more about combining both approaches, see [Guidance for Atlas Business Continuity Planning.](https://www.mongodb.com/docs/atlas/architecture/current/business-continuity-planning.md#std-label-arch-center-bcp)

## How Backups Support Disaster Recovery

Backups are the primary tool for implementing disaster recovery. Atlas provides fully managed, customizable backups that enable manual recovery when automatic failover cannot help.

To automate backup configuration with Terraform, including snapshot export to a cloud provider storage bucket and Backup Compliance Policy setup, see the [cluster module backup guide.](https://github.com/terraform-mongodbatlas-modules/terraform-mongodbatlas-cluster/blob/main/docs/backup_guide.md)

### Cloud Backup

When you enable Cloud Backup for your cluster, Atlas uses your cloud provider's native snapshot capabilities to create incremental backups that are immutable by default with fast restore times.

**How it supports DR:**

- Configure snapshot frequency (hourly, daily, weekly, monthly, yearly) to meet your RPO (Recovery Point Objective) requirements.

- Set snapshot retention periods to meet compliance and recovery needs.

- Restore snapshots to recover from data corruption or deletion.

**When to use:** Standard disaster recovery scenarios where you can tolerate data loss equal to your snapshot frequency. For example, hourly snapshots result in up to 1 hour of data loss.

### Point-in-Time Recovery with Continuous Cloud Backup

When you enable Continuous Cloud Backup in addition to Cloud Backup, Atlas stores oplog data along with your Cloud Backup snapshots, allowing Atlas to restore your cluster to a specific moment in time within a configurable Point in Time (PIT) restore window.

**How it supports DR:**

- Restore to any moment within a configurable PIT restore window. Atlas retains oplog data for up to the length of the restore window, and replays oplog entries on top of the nearest Cloud Backup snapshot to restore to the precise moment you specify.

- Achieve an RPO (Recovery Point Objective) as low as 1 minute.

- Precisely target the moment before data corruption or deletion occurred.

**When to use:** When you need minimal data loss (low RPO (Recovery Point Objective)) or precise recovery to a specific timestamp.

### Multi-Region Snapshot Distribution

When you enable Cloud Backup with a [snapshot copy policy](https://www.mongodb.com/docs/atlas/backup/cloud-backup/snapshot-distribution.md#std-label-snapshot-distribution), you can configure Atlas to automatically distribute copies of your snapshots and oplogs to additional cloud provider regions in other geographies.

**How it supports DR:**

- Meets compliance requirements for geographically distributed backups.

- Ensures backups remain accessible even if the primary region fails completely.

- For a multi-region cluster, enabling the Automatically Sync Copy Regions with Cluster Regions option in your snapshot copy policy enables Atlas to automatically distribute snapshots to all regions where your cluster is deployed, and keeps your snapshot copy policy in sync as you add or remove regions. This enables Atlas to use faster, direct-attach restores to restore cluster regions using local snapshot copies after a regional outage, instead of slower cross-region streaming restores.

**When to use:** When you need protection against complete regional loss or provider outages that exceed your HA configuration.

#### Backup Strategy RTO/RPO Trade-offs

Backup strategies protect against data integrity failures that automatic failover cannot address, such as data corruption, accidental deletion, and complete deployment loss. All backup strategies involve some data loss (RPO > 0) and longer recovery times (RTO in minutes to hours). The trade-offs are in how much data you might lose and the operational complexity of each approach.

| Backup strategy | Primary use cases | Typical RTO | RPO | Operational considerations | Cost considerations |
| --- | --- | --- | --- | --- | --- |
| Periodic snapshots | Data corruption, accidental deletion, complete deployment loss. | Minutes to hours. | > 0 (up to snapshot interval). | Define schedule/ retention. Regularly test restore procedures. | Storage grows with frequency and retention. Restore incurs compute/ egress costs. |
| Continuous backup with point-in-time restore | Data corruption or deletion where "bad" timestamp is known. | Minutes to hours. | > 0 (near-zero, down to seconds). | Configure Point in Time (PIT) restore windows. Monitor for failures. | Higher storage and backup cost than snapshots alone. |
| Multi-region snapshot distribution | Region or provider loss that also affects local backups. | Minutes to hours (can be slower cross-region). | > 0 (tied to snapshot schedule). | Plan and test cross-region restores. Manage retention policy. | Additional storage in multiple regions. Cross-region egress on restore. |

### All Deployment Paradigm Recommendations

The following recommendations apply to all [deployment paradigms.](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms.md#std-label-arch-center-paradigms)

This section covers the following disaster recovery procedures:

- [Single Node Outage](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-single-node-outage)

- [Regional Outage](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-regional-outage)

- [Cloud Provider Outage](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-provider-outage)

- [Atlas Outage](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-atlas-outage)

- [Resource Capacity Issues](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-resource-capacity)

- [Resource Failure](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-resource-failure)

- [Deletion of Production Data](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-data-deletion)

- [Driver Failure](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-driver-failure)

- [Data Corruption](https://www.mongodb.com/docs/atlas/architecture/current/disaster-recovery.md#std-label-arch-center-data-corruption)

#### Single Node Outage

If a single node in your replica set fails due to a partial regional outage, your deployment should still be available, assuming you have followed best practices. If you are reading from secondaries, you might experience degraded performance or potential outages in the event that a secondary node should fail, because of the increased load on the then underprovisioned cluster.

You can test a primary node outage in Atlas using the Atlas UI's [Test Primary Failover](https://www.mongodb.com/docs/atlas/tutorial/test-resilience/test-primary-failover/) feature or the [Test Failover](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-restartgroupclusterprimaries) Atlas Administration API endpoint.

#### Regional Outage

In the event of a regional outage, multi-region clusters automatically hold an election and identify a new primary node if necessary. This topology change is automatically communicated to the application, allowing it to take any necessary corrective action. In order to maintain application uptime in the event of a regional outage, your application must also be deployed with a multi-region topology. This requirement extends to include any third-party service your application may be integrated with. To learn more, see [Multi-Region Deployment Paradigm.](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms/multi-region.md#std-label-arch-center-paradigms-multi-region)

If a single region outage or multi-region outage degrades the state of your cluster, follow these steps:

1. Identify the region experiencing issues

2. Identify how many nodes are still online

   You can find information about cluster health in the cluster's Overview tab of the Atlas UI.

3. Determine how many nodes you require

   Based on how many nodes are left online, determine how many new nodes you require to restore the replica set to a normal state.

   A normal state is a state in which the majority of nodes are available.

4. Determine which regions are unlikely to be affected by the current outage

   Depending on the cause of the outage, there may be additional regions in the near future that will also experience unscheduled outages. For example, if the outages were caused by a natural disaster on the east coast of the United States, you should avoid regions on the east coast of the United States in case there are additional issues.

5. Add nodes to the regions you identified

   Add the required number of nodes for a normal state across regions that are unlikely to be affected by the cause of the outage.

   To reconfigure a replica set during an outage by adding regions or nodes, see [Reconfigure a Replica Set During a Regional Outage.](https://www.mongodb.com/docs/atlas/reconfigure-replica-set-during-regional-outage/)

6. (Optional) Add additional nodes

   In addition to adding nodes to restore your replica set to a normal state, you can add additional nodes to match the topology of your replica set before the disaster.

You can test a region outage in Atlas using the Atlas UI's [Simulate Outage](https://www.mongodb.com/docs/atlas/tutorial/test-resilience/simulate-regional-outage/) feature or the [Start an Outage Simulation](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-startgroupclusteroutagesimulation) Atlas Administration API endpoint.

#### Cloud Provider Outage

With multi-cloud clusters, you can select electable nodes across cloud providers to maintain high availability. Should the provider in which your primary node is deployed become unavailable, Atlas automatically elects new primary nodes to ensure continuous operation. For example, you can create electable nodes on AWS (Amazon Web Services), Google Cloud, and Microsoft Azure to ensure that if one cloud provider experiences an outage, an electable node on a separate provider can automatically take over as your cluster's primary node. To learn more, see [Multi-Cloud Deployment Paradigm.](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms/multi-cloud.md#std-label-arch-center-paradigms-multi-cloud)

Most multi-region Atlas clusters will recover automatically from a single region outage. To learn more, see [Guidance for Atlas High Availability](https://www.mongodb.com/docs/atlas/architecture/current/high-availability.md#std-label-arch-center-high-availability) and [Multi-Region Deployment Paradigm](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms/multi-region.md#std-label-arch-center-paradigms-multi-region). In the case that regional outages have taken a majority of nodes offline, you must determine how many more nodes you need to add in order for a majority of nodes to be healthy.

In the highly unlikely event that an entire cloud provider is unavailable, follow these steps to bring your deployment back online:

1. Determine when the cloud provider outage began

   You need this information later in this procedure to restore your deployment.

2. Identify the alternative cloud provider you would like to deploy your new cluster on

   For a list of cloud providers and information, see [Cloud Providers.](https://www.mongodb.com/docs/atlas/reference/cloud-providers/)

3. If you store backups across multiple cloud providers, as a cloud provider outage implies that any backups stored on the primary cloud provider are necessarily unavailable, find the most recent available snapshot taken of the cluster before the outage began

   To learn how to view your backup snapshots, see [View M10+ Backup Snapshots.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/dedicated-cluster-backup/#view-m10--backup-snapshots)

4. Create a new cluster with the alternative cloud provider

   Your new cluster must have an identical topology of the original cluster.

   Alternatively, instead of creating a full new cluster, you can also add new nodes hosted by an alternative cloud provider to the existing cluster.

5. Restore the most recent snapshot from the previous step into the new cluster

   To learn how to restore your snapshot, see [Restore Your Cluster.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-overview/)

6. Switch any applications that connect to the old cluster to the newly-created cluster

   To find the new connection string, see [Connect via Client Libraries](https://www.mongodb.com/docs/atlas/driver-connection/). Review your application stack as you likely need to redeploy it onto the new cloud provider.

#### Atlas Outage

In the highly unlikely event that the Atlas Control Plane and the Atlas UI are unavailable, your cluster is still available and accessible. To learn more, see [Platform Reliability](https://www.mongodb.com/products/platform/trust#reliability). Open a high-priority [support ticket](https://www.mongodb.com/docs/atlas/support/#request-support) to investigate this further.

#### Resource Capacity Issues

Computational resource (such as disk space, RAM, or CPU) capacity issues can result from poor planning or unexpected database traffic. This behavior might not be a result of a disaster.

If a computational resource reaches the maximum allocated amount and causes a disaster, follow these steps:

1. Identify which computational resource is maxed out by using the Real Time Performance Panel or Atlas metrics

   To view your resource utilization in the Atlas UI, see [Monitor Real-Time Performance.](https://www.mongodb.com/docs/atlas/real-time-performance-panel/)

   To view metrics with the Atlas Administration API, see [Monitoring and Logs.](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/group/endpoint-monitoring-and-logs)

2. Determine how much more of the maxed-out resource you need to alleviate performance issues

3. Allocate the necessary resources

   Note that Atlas will perform this change in a rolling manner, so it should not have any major impact on your applications.

   To learn how to allocate more resources, see [Edit a Cluster.](https://www.mongodb.com/docs/atlas/scale-cluster/#edit-a-cluster)

4. Monitor your cluster to determine whether any other issues exist after the change

#### Resource Failure

**Important:**

This is a temporary solution intended to shorten overall system downtime. Once the underlying issue resolves, merge the data from the newly-created cluster into the original cluster and point all applications back to the original cluster.

If a computational resource fails and causes your cluster to become unavailable, follow these steps:

1. Open a high-priority [support ticket](https://www.mongodb.com/docs/atlas/support/#request-support)

2. Create a new cluster with the same topology as the failing cluster

3. Restore the most recent backup into the newly-created cluster

   To learn how to restore your snapshot, see [Restore Your Cluster.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-overview/)

4. Point all applications using the failing cluster to the newly-created cluster

#### Deletion of Production Data

Production data might be accidentally deleted due to human error or a bug in the application built on top of the database. If the cluster itself was accidentally deleted, Atlas might retain the volume temporarily.

If the contents of a collection or database have been deleted, follow these steps to restore your data:

1. Determine the date and time or oplog timestamp when the data was deleted

2. Create a copy of the current state of the collection or database, if it contains any data

   You can use [mongoexport](https://www.mongodb.com/docs/database-tools/mongoexport/) to create a copy.

3. Restore your data

   If the deletion occurred within the last 72 hours, and you configured continuous backup, use Point in Time (PIT) restore to restore from the point in time right before the deletion occurred.

   If the deletion did not occur in the past 72 hours, restore the most recent backup from before the deletion occurred into the cluster.

   To learn more, see [Restore Your Cluster.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-overview/)

4. If you created a copy of your data, import the new data you exported

   You can use [mongoimport](https://www.mongodb.com/docs/database-tools/mongoimport/) with [upsert mode](https://www.mongodb.com/docs/database-tools/mongoimport/#std-option-mongoimport.--mode) to import your data and ensure that any data that was modified or added is reflected properly in the collection or database.

#### Driver Failure

If a driver fails, follow these steps:

1. Determine the issue

   You can work with the technical support team during this step.

   Determine whether the issue is related to an outdated driver version or a recently updated driver version.

2. Identify the appropriate driver version to resolve the issue

   - If you are using an outdated driver, check if upgrading to a newer version resolves the issue. Most driver problems are fixed in newer releases.

   - If you recently upgraded your driver and suspect the new version introduced the issue, consider reverting to the previous working version.

3. Evaluate if any other changes are required to move to the target driver version

   This might include application code or query changes. For example, there might be breaking changes if you are moving between major versions, or new features available if upgrading.

4. Test the changes in a non-production environment

5. If you don't encounter issues while testing, deploy the new driver version

   Ensure that any other changes from the previous step are reflected in the production environment.

#### Data Corruption

**Important:**

This is a temporary solution intended to shorten overall system downtime. Once the underlying issue resolves, merge the data from the newly-created cluster into the original cluster and point all applications back to the original cluster.

If your underlying data becomes corrupted, follow these steps:

1. Open a high-priority [support ticket](https://www.mongodb.com/docs/atlas/support/#request-support)

2. Create a new cluster with the same topology as the failing cluster

3. Restore the most recent backup into the newly-created cluster

   To learn how to restore your snapshot, see [Restore Your Cluster.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-overview/)

4. Check the restored data to confirm that the corruption does not exist

5. Point all applications using the failing cluster to the newly-created cluster