故障转移和故障回复
发生灾难时，借助 Azure Site Recovery 可以灵活地故障转移到 Azure，并在灾难结束后，故障回复到本地计算机。
现在最好将其余受保护的环境完全故障转移到 Azure。 在单个测试虚拟上成功运行故障转移演练后，即可执行完全故障转移。 故障转移成功完成后，执行故障回复。
在此单元中，你将探索故障转移和故障回复之间的区别。 你还将了解如何在设置复制到 Azure 的策略后自动创建故障回复策略。
故障转移和故障回复
故障转移在决定调用业务的 BCDR 计划时发生。 当前实时环境（通过 Site Recovery 受到保护）移动到副本环境时发生故障转移。 此目标副本环境将取代实时环境，成为主要基础结构。
故障回复是反向的故障转移。 之前的实时环境（由于发生故障转移而变为了副本环境）会恢复其原始角色，再次成为实时环境。 在第一个实例中发生故障转移后，需要有一个重新保护阶段。 在此阶段，要将原始环境与新的实时环境再次同步。 此过程中可执行故障转移和故障回复，而不丢失任何数据。 重新保护阶段可能花费较长时间，因为需要确定旧的实时环境在发生灾难后是否正常运行。
故障转移和故障回复操作的四个阶段为：
- 故障转移到 Azure：如果本地主站点出现故障，则决定故障转移到 Azure（或辅助站点），这会通过主要复制数据创建虚拟机。
- 重新保护 Azure 虚拟机：发生故障转移后，必须重新保护 Azure 虚拟机，从而在避灾难后将更改复制回本地环境。 关闭虚拟机以确保数据一致性。
- 故障回复到本地：本地站点恢复正常运行后，可以故障转移回该环境。 然后，它将再次成为实时环境。 不能故障回复到物理服务器。 所有系统都必须故障回复到虚拟机。
- 重新保护本地虚拟机：重新保护本地虚拟机，以便在故障回复成功完成后开始复制到 Azure。
故障回复策略
如果要创建用于将本地计算机复制到 Azure 的本地复制策略，则系统会自动为你创建相关的故障回复策略。 该策略具有一些无法更改的固定属性。 这些属性包括：
- 只能复制回本地配置服务器。
- 恢复点目标设置为 15 分钟。
- 恢复点保留期设置为 24 小时。
- 应用一致的快照设置为每小时一次。
运行故障回复会停止 Azure VM。 在复制完成后，启动本地 VM 以接管工作负载。 服务会中断，因此请将故障回复安排在不影响你业务的时间。
业务连续性和灾难恢复计划
Site Recovery 中的 BCDR 计划可以自定义和排序虚拟机及其运行的应用程序的故障转移和故障回复操作。 将计算机组合在一起，可以在故障转移或故障回复期间使用脚本自动执行恢复操作。 根据需要还可以添加更多手动操作步骤。 如果在灾难发生之前测试 BCDR 计划，你将更有信心获得积极结果。 你需要备份基础结构，并在辅助位置快速重新运行基础结构，以满足公司的恢复时间目标需求。
灵活的故障转移
由于故障转移具有灵活性，Site Recovery 可以按需运行故障转移以进行测试。 隔离测试意味着不会中断实时服务。 这种灵活性还支持在实时服务的计划中断期间运行故障转移。 故障不会中断系统用户，因为系统会自动切换为复制的环境。 灵活性也相反。 按需故障回复可以作为计划测试的一部分，也可以作为完全调用的灾难恢复方案的一部分。