根据组织中的应用程序对业务的重要性,您可以为所有应用程序制定统一的策略,或根据每个应用程序的重要性制定更复杂的灾难恢复策略。在灾难恢复站点中启动所有应用程序之前,您的组织可能会容忍几个小时的停机时间。在这种情况下,您可以选择基于所有数据库的备份和恢复的经济高效的灾难恢复策略。另一方面,您公司的业务可能取决于某些关键服务或应用程序的快速可用性,具有更严格的RPO和RTO要求,而其他应用程序可能容忍不那么严格的RPO或RTO要求。在这种情况下,您需要为每一层应用程序和数据库分配正确的灾难恢复策略。
下表描述了AWS云中运行的工作负载的四个灾难恢复选项,以帮助您确定和定义组织的灾难恢复策略。本表中记录的RPO和RTO适用于包括应用程序和数据库组件的完整堆栈。有关更多信息,请参阅AWS良好架构框架文档中的云灾难恢复选项。下一节将介绍特定于数据库的RPO和RTO选项。
Recovery option | RPO | RTO | Infrastructure tasks in DR Region | Cost |
---|---|---|---|---|
备份和恢复 | 小时 | 少于24小时 |
在DR区域中调配所有必需的应用程序资源,并从复制的快照恢复数据库。 |
低的 |
指示灯 | 几十分钟 | 几十分钟 |
提供应用程序基础结构的副本并关闭应用程序堆栈中的资源。 将数据从一个区域复制到另一个区域。保持数据库始终打开并与主数据库同步。在故障切换和测试事件期间按需调配资源。 您还需要同时将基础架构更改和应用程序更改部署到两个地区。您可以通过构建自动化管道来简化这一过程,该管道可以同步主区域和灾难恢复区域中的代码和基础设施。 |
中等的 |
热备用 | Minutes | 分钟 |
在灾难恢复区域中调配整个应用程序基础架构的副本,但与主区域相比,保持该副本的规模缩小。DR区域将能够以比主要区域更小的流量接受流量。 |
高的 |
多站点或活动/活动 | Near zero | 零或接近零 |
将基础架构的完整副本调配到灾难恢复区域。灾难恢复地区的所有资源将与主要地区的资源相等,并能够以与主要地区相同的规模服务交通。由于流量没有中断,因此此选项不需要将故障切换任务作为灾难恢复计划的一部分。 |
较高的 |
最新内容
- 1 week 5 days ago
- 2 weeks 6 days ago
- 3 weeks 2 days ago
- 3 weeks 2 days ago
- 3 weeks 5 days ago
- 3 weeks 6 days ago
- 4 weeks ago
- 4 weeks 1 day ago
- 4 weeks 1 day ago
- 4 weeks 1 day ago