选择您的 Cookie 首选项

我们使用必要 Cookie 和类似工具提供我们的网站和服务。我们使用性能 Cookie 收集匿名统计数据,以便我们可以了解客户如何使用我们的网站并进行改进。必要 Cookie 无法停用,但您可以单击“自定义”或“拒绝”来拒绝性能 Cookie。

如果您同意,AWS 和经批准的第三方还将使用 Cookie 提供有用的网站功能、记住您的首选项并显示相关内容,包括相关广告。要接受或拒绝所有非必要 Cookie,请单击“接受”或“拒绝”。要做出更详细的选择,请单击“自定义”。

REL13-BP03 测试灾难恢复实施以验证实施效果 - AWS Well-Architected 框架

REL13-BP03 测试灾难恢复实施以验证实施效果

定期测试到恢复站点的失效转移,验证是否在正常运作,以及是否满足 RTO 和 RPO。

常见反模式:

  • 从不在生产环境中进行失效转移演练。

建立此最佳实践的好处:定期测试灾难恢复计划,验证计划在需要时能否正常发挥作用,以及团队是否知道如何执行策略。

在未建立这种最佳实践的情况下暴露的风险等级:

实施指导

要避免的模式是制定了恢复路径但很少测试。例如,您可能有一个用于只读查询的辅助数据存储。在写入某个数据存储,却发现主存储故障时,您可能希望失效转移到辅助数据存储。如果不经常测试此失效转移,您可能会发现自己关于辅助数据存储容量的假设是错误的。辅助数据存储容量在上次测试时可能是足够的,但可能无法再容纳这次情况下的负载。根据我们的经验,唯一有效的错误恢复路径是您经常测试的路径。因此,最好只制定几条恢复路径。您可以建立恢复模式并定期对其进行测试。如果恢复路径比较复杂或至关重要,您仍需定期在生产环境中测试该故障,确保恢复路径有效。在我们刚才讨论的示例中,您应该定期将故障转移到备用存储,无论是否有需要。

实施步骤

  1. 为灾难恢复设计工作负载。定期测试恢复路径。面向恢复的计算可识别系统中能够增强恢复功能的特性:隔离和冗余,系统范围回滚更改的能力,监控并确定运行状况的能力,提供诊断、自动恢复、模块化设计的能力,以及重启的能力。对恢复路径进行演练,确认可以在指定时间内恢复到指定状态。在此恢复过程中使用运行手册来记录问题,并在下一次测试之前找到问题的解决方案。

  2. 对于基于 Amazon EC2 的工作负载,使用 AWS Elastic Disaster Recovery 为灾难恢复策略实施和启动演练实例。AWS Elastic Disaster Recovery 可以高效地运行演练,帮助您为失效转移事件做好准备。您还可以使用弹性灾难恢复频繁地启动实例进行测试和演练,无需重定向流量。

资源

相关文档:

相关视频:

相关示例:

隐私网站条款Cookie 首选项
© 2025, Amazon Web Services, Inc. 或其附属公司。保留所有权利。