制定业务连续性和灾难恢复计划
你的组织想要为应用程序设计站点恢复策略。 首先，应了解构建混合环境站点恢复的特定要求。 还必须了解 Azure 中有哪些工具可以帮助你。
在本单元中，了解如何确定关键基础结构、恢复时间目标 (RTO) 和恢复点目标 (RPO)。 了解与你可能正在使用的任何平台即服务 (PaaS) 服务相关的需求。 同时了解如何规划备份和灾难恢复。 最后，发现某些有助于生成站点恢复解决方案的 Azure 功能。
业务连续性和灾难恢复
你需要制定 BCDR 计划，以设计适当的站点恢复解决方案。 BCDR 是指在重大事件发生后帮助你将应用程序还原到正常运行状态的过程。 这类事件可能是自然灾害，如地震。 也可能是技术性事件，如删除数据库。 这类事件通常范围较广，且涉及更大量的恢复工作。
若要设计成功的灾难恢复流程，首先需要评估任何潜在的故障将会对业务产生的影响。 考虑尽可能使恢复过程自动化。 不可避免地，灾难恢复过程的某些部分涉及人工输入，因此必须完整地记录该过程。 还必须定期模拟灾难，确保恢复过程始终有效。
确定关键利益干系人和基础结构
确定与应用程序有利益干系的所有人是否仍能正常工作。 这些利益干系人可以是外部或内部用户。 支持人员以及需要在 BCDR 过程中手动输入的任何人都是利益干系人。 依赖于应用程序的其他应用程序和服务也可以看作利益干系人。
确定构成应用程序环境的基础结构。 此基础结构通常是虚拟机 (VM)、网络资源、存储资源以及与这些资源一起运行的任何其他服务。
确定恢复时间目标和恢复点目标
RPO 表示发生灾难时应用程序可接受的数据丢失量。 例如，如果应用程序停止运行，你可能发现只能接受它在恢复后依赖半小时内生成的数据运行。 有些应用程序使用较旧的数据也能正常工作，但对于其他应用程序，始终依赖尽可能最新的数据运行至关重要。
RTO 是应用程序可接受故障的最长持续时间。 例如，你可能无法接受应用程序宕机时间超过 4 小时，因为长时间的服务中断可能会对业务造成损失。 关键应用程序需要更短的 RTO。
合同或法规要求通常会应用程序的 RTO 和 RPO。 RPO 和 RTO 也可能因应用程序而异。 不太关键的应用程序可能具有较大的 RPO 和 RTO 值，而业务关键应用程序对故障时间和数据丢失的容忍度可能较小。 可以根据组织对停机时间和数据丢失带来的风险和成本的了解来计算 RTO 和 RPO。
确定任何 PaaS 要求
尽管可以控制所管理的应用程序的故障时间和恢复，但可能无法控制 PaaS 服务。 你使用的任何 PaaS 服务都可能有自己的可用性保证和恢复计划，必须在 BCDR 计划中考虑这些保证和恢复计划。
确定并清点所依赖的服务，以便将其恢复功能合并到 BCDR 计划。 了解相关要求以及它们对 BCDR 过程的影响很重要。
Azure Site Recovery
Azure Site Recovery 是一项服务，它为 Azure、本地和其他云提供商所提供云服务中的应用程序提供 BCDR 功能。 Site Recovery 提供帮助自动执行灾难恢复的计划。 它使你能够定义计算机的故障转移方式，以及成功故障转移后重启它们的顺序。 通过这种方式，Site Recovery 有助于自动执行任务并进一步降低 RTO。 还可以使用 Site Recovery 定期测试故障转移和恢复过程的总体效果。
数据备份
备份有助于防止应用程序意外删除或损坏数据。 备份在任何 BCDR 计划中都发挥着重要作用。
RPO 取决于运行备份过程的频率和规律。 例如，如果将备份过程配置为每两小时运行一次，并在下次备份前 5 分钟遭遇灾难，那么将丢失 1 小时 55 分钟的数据。 更频繁的备份意味着可以降低 RPO。 在总体计划中，必须包括详细的备份过程。
可以使用 Azure 备份执行备份过程。 Azure 备份服务为所有 Azure 管理的数据资产提供安全备份。 它使用零基础结构解决方案实现自助备份和还原，以可预测的成本进行大规模管理。
Azure 备份为 Azure 和本地 VM 提供专门的备份解决方案。 借助 Azure 备份，在 Azure VM 中运行的工作负载（例如 SQL Server 或 SAP HANA）还具有企业级备份和还原选项。
Azure 备份和 Azure Site Recovery 的目的都是使系统在出现错误和故障时的可复原性更强。 但 Azure 备份的主要目标是维护有状态数据的副本，使你能够及时返回。 Site Recovery 几乎实时地复制数据，并允许进行故障转移。 详细了解 Azure 备份。
Azure 复原功能
Azure 提供了多个功能，帮助确保应用程序和基础结构可复原。 Azure 复原功能包括区域配对、可用性集和可用性区域。
区域配对
所有 Azure 区域都与另一个区域配对。 在区域对中，区域永远不会同时更新。 并逐个对其进行更新。 如果某个区域发生问题，配对中的另一个区域将变为可用。
这些区域对也用于复制。 存储服务和许多 PaaS 服务在配对的区域中都有副本并拥有故障转移对。 在 BCDR 计划中，使用区域配对以利用其提供的隔离很重要。 你可以缩短从故障中恢复的时间，并提升可用性。
可用性集
可用性集是 Azure 中的逻辑分组功能。 可以将 VM 资源放在可用性集中，以确保在 Azure 数据中心内部署这些 VM 资源时它们彼此隔离。 可用性集由更新域和容错域构成。
当 Azure 数据中心内的 VM 主机需要停机进行维护时，更新域有助于确保始终有一部分应用程序服务器保持运行。 可以执行对 VM 主机的大多数更新，而不会影响 VM 主机上运行的 VM，但在某些情况下无法进行此类更新。
为确保更新不会同时发生在所有 VM 上，Azure 数据中心在逻辑上划分为更新域。 当发生维护事件时，如需要更新性能和对主机应用关键安全修补程序等，会通过更新域确定维护事件的顺序。 通过更新域进行排序可确保在平台更新和修补期间，整个数据中心不会不可用。
容错域表示数据中心的物理区段，有助于确保可用性集中服务器机架多样性。 容错域与数据中心中共享硬件的物理隔离性保持一致。 共享硬件包括为服务器机架上的物理服务器提供支持的电源、冷却和网络硬件。
如果支持服务器机架的硬件不可用，那么故障只会影响该服务器机架。 将 VM 放置在可用性集中时，它们会自动分布在多个容错域中。 如果发生硬件故障，只会影响部分 VM。
可用性区域
可用性区域是区域中的独立物理数据中心位置。 可用性区域包含自身的电源、散热设备和网络。 如果在部署资源时考虑了可用性区域，则有助于保护工作负载免受数据中心故障的影响，并在区域中保持正常运行。
区域服务是可以部署到区域中特定区域的服务（例如虚拟机）。 其他服务属于区域冗余服务，并跨特定 Azure 区域中的可用性区域进行复制。 这两种类型都有助于确保 Azure 区域中不存在单一故障点。
