灾难恢复是当今构建云架构的主要要求之一。这场灾难可能是生产错误，开发人员的过错，也可能是AWS Service本身即将结束时的缺陷。灾难恢复是应用程序的重要组成部分。在深入研究AWS Disaster Recovery策略之前，让我们了解一些与Disaster Recovery相关的术语。
恢复时间目标(RTO)： RTO是在损害业务之前服务可以保持不可用的最长时间。
恢复点目标(RPO)： RPO是系统宕机时可能丢失数据的最长时间。
RTO-RPO图片
在上面的示例中，系统在下午2点关闭，并在晚上6点恢复到其正常状态。这意味着以上情况的恢复时间目标为4小时。同样，假设上述情况每2小时进行一次备份，而系统的最后一次备份是在下午12点(由绿色箭头标记)。由于系统降为，这意味着12 pm到2 pm之间的数据将丢失，并且只能恢复12 pm的数据或系统状态。这意味着上述问题的恢复点目标为2小时。
您的体系结构和数据备份解决方案的选择将完全取决于您的应用程序可以支持多少RPO和RTO，而不会损害您的业务。
不同的灾难恢复策略
备份还原：
在此策略中，您需要对存储在EBS卷和RDS数据库中的数据进行频繁的快照，并将这些快照存储在可靠的存储空间(如AWS S3)中。您可以定期创建服务器的AMI，以保留服务器的状态。这将保留服务器上的所有软件和软件更新以及与服务器关联的IAM权限。备份和还原基本上使用AWS作为您的虚拟磁带库。不仅可以为AWS应用程序执行此策略，还可以为您的本地应用程序执行此策略。 AWS Storage Gateway允许您获取和备份本地卷的快照，并将这些快照存储在AWS S3中。这是灾难恢复策略中最慢的，最好与其他策略配合使用。在AWS Glacier中存储备份数据可以帮助进一步降低该策略的成本。
- RTO-高(例如：10-24小时)
- RPO-取决于备份的频率。可以是每小时，3小时，6小时或每天。
指示灯：
在此策略中，生产环境的最低版本将保持在AWS上运行。这并不意味着整个应用程序都会按比例缩小(热备份)，而是仅配置和运行生产环境的核心和最关键的组件。当灾难来袭时，将在此运行的核心周围重新启动整个应用程序。与您的备份和还原相比，Pilot Light的成本更高，因为您一直在运行一些最少的AWS服务。该策略还涉及使用诸如AWS CloudFormation之类的云脚本来配置基础架构 脚本来高效，快速地还原系统。
- RTO-高，但小于备份和还原。例如：5-10小时。
- RPO-与用于备份和还原的RPO相同，即取决于备份的频率。即使最小的核心环境正在运行，数据恢复仍然取决于备份。
暖待机：
顾名思义，热备份策略涉及运行规模极小，但功能完善，功能齐全的应用程序，类似于始终在云中运行的生产应用程序。万一发生故障或灾难，热备用应用程序可以立即扩大规模以用作生产应用程序。 EC2服务器可以保持最少数量和服务器类型的运行状态，并且可以使用AWS AutoScaling功能进行扩展以用作功能齐全的应用程序。同样，在发生故障的情况下，所有DNS记录和流量路由表都将更改为指向备用应用程序而不是生产应用程序。为了快速更改数据，架构师将必须在主要生产环境接管后将重复数据从备用站点反转到主要站点。
- RTO：低于指示灯。范例：<5小时。
- RPO：自上次数据写入主从多可用区数据库以来。
多站点：
顾名思义，多站点策略涉及运行生产环境的全功能版本作为云中的备份。这是主应用程序的一对一副本，通常在不同的可用区或完全不同的区域中运行，以实现持久性。这是所有灾难恢复选项中最昂贵的，因为它会使运行单个应用程序的运行成本增加一倍。成本开销由Multi-Site DR策略提供的最小RPO和RTO补偿。但是，RPO时序可能会因系统对数据复制方法(同步和异步)的选择而异。一旦出现故障，开发人员只需更改DNS记录和路由表即可指向辅助应用程序。
- RTO：所有灾难恢复策略中最低的。范例：<1小时。
- RPO：所有灾难恢复策略中最低的。数据复制的选择会影响RPO。最后的数据写入同步数据库中。
云计算是开发人员和投资者最大的资产之一，它们可以使他们高效，简单地进行应用程序，并且仍具有较便宜的成本结构。以传统(非云)方式进行的备份可能会更加昂贵，效率低下，并且容易出现硬件问题和人为错误。 AWS不仅为AWS应用程序提供了备份策略，还为可以利用AWS进行备份的本地应用程序提供了备份策略。与传统备份系统相比，云备份具有很多优势。如：
- 成本低
- 完全由AWS管理。
- 安全可靠。
- 无需硬件维护。
- 场外备份
- 易于使用Cloud Infrastructure访问和测试。