灾难恢复 (DR) 是一种韧性策略，当自动故障转移无法提供帮助时，它使用手动过程来恢复部署。与为基础架构故障提供自动自我修复的高可用性不同，灾难恢复需要人工干预才能从备份中恢复。
注意
MongoDB Atlas责任共担模型定义了MongoDB及其客户在维护安全和弹性数据环境方面的互补职责。在此框架下， MongoDB管理根本的平台的安全性和操作完整性，而客户则负责其特定部署的配置、管理和数据策略。有关安全性和卓越运营之间所有权的详细划分，请参阅责任共担模型。
何时使用灾难恢复
重要
尽可能选择高可用性。仅当高可用性不可行时，才将灾难恢复作为主节点 (primary node in the replica set)韧性策略。
在以下情况下，灾难恢复适合作为主节点 (primary node in the replica set)韧性策略：
- 地理限制
- 您无法部署到具有足够可用区的多个区域。示例，如果您必须在加拿大部署，则只有 2 区域可用，从而满足自动故障转移法定人数要求。
- 成本优化
- 您的预算要求最大限度地降低基础架构成本。多区域或多云高可用性部署的费用高于带备份的单区域部署。
- 手动恢复容差
- 您的应用程序可以容忍手动干预和备份恢复所需的时间（RTO 以分钟到小时而不是秒为单位）。
注意
即使使用高可用性，对于自动故障转移无法解决的情况（例如数据损坏或意外删除），您也可能会受益于灾难恢复过程。要学习；了解有关结合使用这两种方法的更多信息，请参阅Atlas业务连续性规划指导。
备份如何支持灾难恢复
备份是实施灾难恢复的主节点 (primary node in the replica set)工具。Atlas提供完全托管、可自定义的备份，以便在自动故障转移无法启用帮助时启用手动恢复。
云备份
当您为集群启用云备份时， Atlas会使用云提供商的原生快照功能来创建增量备份，默认这些备份不可变，并且恢复速度快。
如何支持灾难恢复：
配置快照频率（每小时、每天、每周、每月、每年）以满足 RPO 要求。
设置快照保留期以满足合规和恢复需求。
恢复快照以从数据损坏或删除中恢复。
何时使用：标准灾难恢复场景，您可以容忍与快照频率相同的数据丢失。示例，每小时快照会导致最多 1 小时的数据丢失。
通过持续云备份进行时点恢复
当您除了 云备份 之外还启用Continuous Cloud Backup 时， Atlas会将oplog数据与 云备份 快照一起存储，从而允许Atlas将集群恢复到可配置的时间点 (PIT)恢复窗口内的特定时间点。
如何支持灾难恢复：
恢复到可配置的 PIT恢复窗口内的任何时刻。Atlas会在恢复窗口的长度内保留oplog数据，并在最近的云备份快照之上重放oplog条目，以恢复到您指定的精确时刻。
实现低至1分钟的RPO。
精确定位数据损坏或删除发生之前的那一刻。
何时使用：当您需要尽量减少数据丢失（低RPO）或精确恢复到特定时间戳时。
多区域快照分发
当您启用带有快照副本策略的云备份时，您可以将Atlas配置为自动将快照和 oplog 的副本分发到其他地理位置的其他云提供商区域。
如何支持灾难恢复：
满足地理分布式备份的合规要求。
即使主节点 (primary node in the replica set)区域完全故障，也确保备份仍可访问。
对于多区域集群，在快照复制策略中启用 Automatically Sync Copy Regions with Cluster Regions 选项， Atlas就能自动将快照分发到部署集群的所有区域，并在添加或删除区域时保持快照复制策略同步。这使Atlas能够在区域服务中断后使用更快的直连恢复来恢复使用本地快照副本的集群区域，而不是较慢的跨区域流媒体恢复。
何时使用：当您需要防止完全区域丢失或提供商服务中断超过您的 HA 配置时。
备份策略 RTO/RPO 权衡
备份策略可防止自动故障转移无法解决的数据完整性故障，例如数据损坏、意外删除和完全部署丢失。所有备份策略都会导致一定程度的数据丢失 (RPO > 0) 和较长的恢复时间（RTO 以分钟到小时为单位）。权衡取决于可能丢失的数据量以及每种方法的操作复杂性。
备份策略 | 主要用例 | 典型 RTO | RPO | 操作注意事项 | 成本考虑 |
|---|---|---|---|---|---|
定期快照 | 数据损坏、意外删除、完整部署丢失。 | 分钟到小时不等。 | > 0（取决于快照间隔）。 | 定义安排/保留。定期测试恢复过程。 | 存储空间随着频率和保留的增加而增长。恢复会产生计算/出口成本。 |
带时点还原的持续备份 | 已知“错误”时间戳的数据损坏或删除。 | 分钟到小时不等。 | > 0（接近于零，精确到秒）。 | 配置时点 (PIT)恢复窗口。监控故障。 | 与单独使用快照相比，存储和备份费用更高。 |
多区域快照分发 | 区域或提供商丢失也会影响本地备份。 | 从几分钟到几小时不等（跨区域可能会更慢）。 | > 0（与快照安排绑定）。 | 规划和测试跨区域恢复。管理保留策略。 | 多个地区的额外存储。恢复时的跨区域出口量。 |
所有部署范式建议
以下建议适用于所有部署范式。
本节介绍以下灾难恢复过程：
单节点中断
如果您的副本集中的单个节点因部分区域性服务中断而发生故障，只要遵循最佳实践，您的部署仍应能够正常运行。如果您从从节点读取，当从节点发生故障时，您可能会遇到性能下降或潜在的服务中断，因为集群在此时由于负载增加而资源不足。
您可以使用Atlas用户界面的“测试主节点 (primary node in the replica set)节点故障转移”功能或“测试故障转移Atlas Administration API”端点在Atlas中测试主节点中断。
区域中断
如果事件区域中断，多区域集群会自动进行选举，并在必要时确定新的主节点 (primary node in the replica set)节点。此拓扑结构更改会自动传达给应用程序，从而允许其采取任何必要的纠正操作。为了在区域服务中断事件时保持应用程序正常运行，您的应用程序还必须使用多区域拓扑结构进行部署。此要求扩展到包括您的应用程序可能集成的任何第三方服务。要学习；了解更多信息，请参阅多区域部署范例。
如果单地区中断或多区域中断导致集群状态下降，请执行以下步骤：
您可以使用Atlas用户界面的模拟停电功能或启动停电模拟Atlas Administration API端点来测试Atlas中的地区停电。
云提供商服务中断
对于多云集群，您可以跨云提供商选择可选举节点以保持高可用性。如果部署主节点 (primary node in the replica set)节点的提供商不可用， Atlas会自动选举新的主节点 (primary node in the replica set)节点以确保连续操作。示例，您可以在 AWS、Google Cloud 和Microsoft Azure上创建可选举节点，以确保在一个云提供商遇到服务中断时，另一提供商上的可选举节点可以自动接管，成为集群的主节点 (primary node in the replica set)。要学习；了解更多信息，请参阅多云部署范例。
大多数多区域Atlas集群都会从单区域服务中断中自动恢复。要学习；了解更多信息，请参阅Atlas高可用性指南和多区域部署范例。如果区域中断导致大多数节点离线，您必须确定还需要添加多少节点才能使大多数节点保持正常状态。
在极不可能发生的整个云提供商不可用的情况下，请按照以下步骤使部署重新上线：
确定要部署新集群的替代云提供商
有关云提供商列表和信息，请参阅云提供商。
如果您在多个云提供商之间存储备份，由于云提供商服务中断意味着存储在主节点上的任何备份都不可用，请查找在服务中断开始之前拍摄的集群的最新可用快照。
要了解如何查看备份快照，请参阅查看 M10+ 备份快照。
将上一步的最新快照恢复到新的集群中
要学习；了解如何恢复快照，请参阅恢复集群。
将连接到旧集群的所有应用程序切换到新创建的集群
要查找新的连接字符串，请参阅通过客户端库连接。查看您的应用程序堆栈，因为您可能需要将其重新部署到新的云提供商上。
Atlas中断
在极不可能发生的 Atlas 控制平面和 Atlas 用户界面不可用的情况下，您的 Atlas 集群仍然可用且可访问。要了解更多信息，请参阅平台 Reliability。打开高优先级支持工单，进一步调查此问题。
资源容量问题
规划不善或意外的数据库流量可能会导致计算资源（如磁盘空间、RAM 或 CPU）容量问题。这种行为可能不是由灾难引起的。
如果计算资源达到最大分配量并导致灾难，请遵循以下步骤：
资源故障
重要
这是一个临时解决方案，旨在缩短整个系统的停机时间。解决根本的问题后，将新创建集群中的数据合并到原始集群，并将所有应用程序点原始集群。
如果计算资源发生故障并导致您的集群不可用，请遵循以下步骤：
删除生产数据
由于人为错误或在数据库上构建的应用程序中的漏洞，生产数据可能会被意外删除。如果集群本身被意外删除，Atlas可能会暂时保留该卷。
如果集合或数据库的内容已被删除，请按照以下步骤恢复您的数据：
创建集合或数据库当前状态的副本（如果其中包含任何数据）
您可以使用mongoexport创建副本。
恢复您的数据
如果删除发生在过去 72 小时内，并且您已配置连续备份，请使用给定时间点 (PIT) 恢复，从删除发生之前的时间点进行恢复。
如果删除操作并非发生在过去 72 小时内，则将删除操作发生之前的最新备份恢复到集群中。
要学习；了解更多信息，请参阅恢复集群。
如果您创建了数据副本，请导入您导出的新数据
您可以使用 mongoimport 与更新或插入模式来导入数据，并确保在集合或数据库中正确反映任何已修改或添加的数据。
驱动程序故障
如果驱动程序出现故障，请按照以下步骤操作：
数据损坏
重要
这是一个临时解决方案，旨在缩短整个系统的停机时间。解决根本的问题后，将新创建集群中的数据合并到原始集群，并将所有应用程序点原始集群。
如果底层数据损坏，请遵循以下步骤：