业务连续性计划可确保您的应用程序在中断期间保持可用并可恢复。您的计划应结合以下内容：
高可用性 (HA)：部署在基础架构出现故障时自动进行自我修复的架构。
灾难恢复 (DR)：建立在自动故障转移无法提供帮助时手动恢复的程序。
测试：定期验证 HA 和 DR 功能。
文档：保持明确的程序和恢复目标。
注意
MongoDB Atlas责任共担模型定义了MongoDB及其客户在维护安全和弹性数据环境方面的互补职责。在此框架下， MongoDB管理根本的平台的安全性和操作完整性，而客户则负责其特定部署的配置、管理和数据策略。有关安全性和卓越运营之间所有权的详细划分，请参阅责任共担模型。
选择韧性策略
根据您的要求，从以下主节点 (primary node in the replica set)方法中进行选择：
高可用性 - 自动自我修复
当您需要近乎零的停机时间并且可以跨多个可用区 (AZ)、区域或云提供商部署时，请选择高可用性。
特点：
自动故障转移，无需人工干预。
RPO = 0 使用
majority写关注（write concern）时。RTO = 秒。
基础设施费用更高。
何时使用：大多数生产部署，尤其是在以下情况下：
您的用户分布在多个区域。
您的应用程序需要持续可用性。
您可以部署到具有 3 个以上可用区的区域。
要了解更多信息，请参阅 Atlas 高可用性指南和 Atlas 部署范式。
灾难恢复 - 手动恢复
当 HA 不可行或不具有成本效益时，请选择 DR，例如：
地理限制，例如加拿大只有 2 个地区。
成本敏感的应用程序。
手动恢复过程的容忍度。
特点：
需要手动干预。
RPO > 0，具体取决于备份频率。
RTO = 分钟到小时。
降低基础架构费用、备份存储应用。
何时使用：
地理或监管限制阻碍了多区域部署。
预算约束要求费用优化。
应用程序可以容忍计划内的恢复停机。
要了解更多信息，请参阅 Atlas 灾难恢复指导。
结合 HA 和 DR
大多数生产环境都受益于结合使用这两种方法来提供全面的保护：
针对基础架构故障的高可用性：自动故障转移可防止节点、区域、地区或提供商服务中断。
针对数据完整性问题的灾难恢复：备份可防止自动故障转移无法解决的情况。
为什么即使具有高可用性，您也可能从灾难恢复中受益
即使采用高可用性部署，您也可能会从灾难恢复过程中受益：
- 数据损坏或意外删除
- 高可用性可跨所有节点复制损坏的数据。您必须从备份中恢复，才能恢复到发生损坏或删除之前的状态。
- 应用程序级故障
- 影响数据完整性而不是基础架构的代码错误或恶意攻击。损坏的状态已复制到整个副本集。
- 合规要求
- 许多法规对时间点恢复功能和备份保留策略的要求超出了自动故障转移提供的范围。
这种分层方法提供了全面的保护，同时优化了可用性和数据完整性。
定义恢复目标
建立明确的恢复目标来指南架构和备份决策：
恢复点目标(RPO)
按时间衡量的最大可接受数据丢失量。
例子：
RPO = 0：使用具有
majority写关注（write concern）的高可用性。RPO = 1 小时：配置每小时快照。
RPO = 1 天：配置每日快照。
恢复时间目标(RTO)
中断后恢复服务的最大可接受时间。
例子：
RTO = 秒：使用带自动故障转移的 HA。
RTO = 1 小时：确保备份恢复过程在 <1 小时内完成。
RTO = 4 小时：记录并测试手动恢复过程。
您的部署模式和备份策略应与这些目标保持一致。使用Atlas高可用性指南和Atlas灾难恢复指南中的比较表来评估选项。
定期测试您的计划
至少每半年测试一次业务连续性计划（建议每季度一次）。测试可验证您的程序并培训您的团队。
测试高可用性故障转移
自动化测试：
验证：
故障转移在预期 RTO 内完成。
应用程序会自动重新连接。
不会发生数据丢失 (RPO = 0)。
测试灾难恢复程序
手动恢复测试：
练习在非生产环境中从备份恢复。
记录实际恢复时间并与 RTO 进行比较。
验证恢复的数据完整性。
如果使用多区域快照分布，请测试跨区域恢复。
验证：
团队正确遵循形成文件的程序。
恢复在预期 RTO 内完成。
数据丢失与预期 RPO 一致。
所有依赖项（网络、凭证）都能正常工作。
某些测试可能需要执行标准用户无法执行的操作。至少提前一周打开支持案例，安排人为服务中断或其他受限测试场景。
记录您的计划
为业务连续性计划保留清晰的文档：
所需文档
恢复目标：
记录每个应用程序层级的 RPO 和 RTO。
所选部署模式的理由。
备份频率和保留决策。
架构文档：
部署拓扑结构（区域、区域、云提供商）。
网络架构和故障转移行为。
应用程序部署拓扑结构。
第三方服务依赖项。
恢复程序：
分步恢复程序。
待命团队的联系信息。
不同场景类型的升级路径。
指向监控仪表盘和警报的链接。
测试结果：
历史测试执行日期和结果。
已识别的问题和修复状态。
根据测试结果对程序进行更改。
在每次测试练习或基础架构更改后进行查看和更新，以保持文档最新。
常见情况和响应计划
为常见中断情况制定响应计划。有关详细过程，请参阅Atlas灾难恢复指南中的特定场景部分。
基础设施故障（HA场景）
单节点服务中断：
HA 部署：自动故障转移，无需执行操作。
监控故障转移和节点恢复是否成功。
可用区域服务中断：
多可用区部署：自动故障转移，无需执行操作。
验证应用程序是否继续提供流量。
区域服务中断：
多区域部署：自动故障转移到另一个区域。
确保应用程序也部署到多区域。
验证第三方服务是否仍可访问。
云提供商服务中断：
多云部署：自动故障转移到其他提供商。
单云部署：执行灾难恢复程序。
数据完整性问题（容灾场景）
数据损坏：
识别损坏时间戳。
从发生损坏之前的备份中恢复。
对于连续备份：使用时点还原。
意外删除：
识别删除时间戳。
从删除前的备份中恢复。
验证恢复的数据完整性。
完全部署丢失：
执行已记录的灾难恢复程序。
从最近的备份恢复。
验证应用程序功能。
控制平面故障：
极为罕见。Atlas保持高可靠性。
请参阅平台可靠性。
立即联系MongoDB支持。
有关每种情况的详细恢复过程，请参阅Atlas灾难恢复指南。