访问此页面需要授权。 可以尝试 登录 或 更改目录 。 访问此页面需要授权。 可以尝试 更改目录 。 在平台级别查看和实施 基础结构复原 的设计注意事项后，了解虚拟机（VM）和应用程序如何应对故障至关重要。 这种理解帮助他们能够在可接受的时间段内检测、承受并从故障中恢复。 复原能力是维护业务关键型应用程序的持续作的基础。 默认情况下，Azure 本地上的所有虚拟机（VM）都旨在实现高可用性。 如果群集中的物理节点发生故障，则任何受影响的 VM 都会自动重启并继续在剩余节点上运行，前提是 VM 有足够的计算容量。 即使有了这些强大的平台级容错和复原功能，在 VM 中部署的应用程序也必须遵守设计良好的原则。 架构良好的应用程序将可靠性集成到其代码、基础结构和作中。 例如，在两个或多个 Azure 本地 VM 中部署多个应用程序服务的实例对于消除应用程序层中的单一故障至关重要。 如果单个 VM 或应用程序实例发生故障，请在此层合并额外的复原能力，从而降低停机的风险。 有关详细信息，请参阅 工作负荷复原能力 。 此外，可靠的应用程序设计应包括全面的业务连续性和灾难恢复（BCDR）策略，包括常规 DR 故障转移验证和数据备份和恢复测试，以确保灾难恢复过程按预期运行。 为了降低服务中断或数据丢失的风险，单个 Azure 本地实例的冗余功能无法缓解，必须实现综合 备份策略 与连续 数据复制技术 的组合。 备份策略可防止数据损坏、意外或恶意删除和灾难性事件等情况。 它们有助于在必要时将数据还原到以前的状态。 备份策略可防止数据损坏、意外或恶意删除和灾难性事件等情况。 它们有助于在必要时将数据还原到以前的状态。 数据复制技术支持跨多个 Azure 本地实例和 Azure 区域维护虚拟机数据的同步副本。 这种做法可以最大程度地减少停机时间，并在硬件或系统故障时实现快速负载故障转移。 这些方法共同提供了一个可靠的安全网，旨在保护数据，并在意外中断期间保持运营和业务连续性。 数据复制技术支持跨多个 Azure 本地实例和 Azure 区域维护虚拟机数据的同步副本。 这种做法可以最大程度地减少停机时间，并在硬件或系统故障时实现快速负载故障转移。 这些方法共同提供了一个可靠的安全网，旨在保护数据，并在意外中断期间保持运营和业务连续性。 有关增强工作负荷和应用程序的复原能力的详细信息和建议，请查看 Azure Well-Architected Framework （WAF） - 可靠性设计原则 。 使用 “创建工作负荷卷”和所需的基础结构卷（推荐） 选项部署的 Azure 本地实例会创建一个名为“UserStorage_X”的群集共享卷（CSV），每个物理节点一个，并在 Azure 中为每个卷创建相关的存储路径资源。 工作负荷资源（例如 Azure 本地 VM 和已启用 Arc 的 Azure Kubernetes 服务器 （AKS） 群集）使用 Azure 中的存储路径资源来存储 VM 映像。 例如，具有本地文件系统路径的 C:\ClusterStorage\UserStorage_1\ 的 CSV，会在 Azure 中创建一个存储路径资源，该资源代表群集共享卷（CSV），从而使 Azure 本地虚拟机（VM）的虚拟硬盘（VHD）能够放置在特定的目标卷上。 有关详细信息，请参阅 存储路径 。 部署利用多个 Azure 本地 VM 来增强工作负荷复原能力（尽可能）的精心构建的应用程序时，请将每个 VM 的虚拟硬盘（VHD）放在单独的存储路径中，以优化冗余。 例如，在预配多个运行同一服务实例的 Azure 本地 VM 时，为每个 VM 的 VHD 使用不同的存储路径有助于降低所有 VM 共享单一存储路径（卷）带来的风险。 创建虚拟硬盘时，配置 Azure 本地 VM 使用的存储路径。 当您使用基础设施即代码 (IaC) 来配置工作负载时，VHD 的放置逻辑会采用轮询分配逻辑来选择存储路径。 对于多节点 Azure 本地实例，每个存储路径默认映射到不同的卷。 因此，每个 VM VHD 分布在不同的存储路径（卷）之间，这会增加工作负荷复原能力，特别是对于单个卷暂时脱机或不可用的情况。 若要进行更精细的预配控制，请在将 Azure CLI 用于工作负荷部署时指定 --storage-path-id 参数，以便在为 Azure 本地 VM 预配虚拟硬盘时以特定存储路径为目标。 Microsoft Azure 备份服务器 Microsoft Azure 备份服务器 （MABS），System Center Data Protection Manager 的演变是一种Microsoft备份解决方案，可用于保护 Azure 本地 VM。 MABS 提供一种混合备份方案，在本地磁盘存储上实现短期保留，以便快速操作恢复，并通过集成 Azure 备份服务来实现长期数据保留，使您能够将备份异地存储到 Azure 恢复服务保管库。 如果使用 MABS，可以使用两种方法来保护 VM： 主机级 VM 备份 和 来宾级 VM 备份 。 主机级 VM 备份 ：在每个 Azure 本地主机（每个群集节点）上安装备份代理，并在虚拟机监控程序级别备份整个 VM。 此方法捕获整个 VM，包括所有虚拟磁盘。 它不需要每个 VM 中的代理，并且与来宾 OS 无关。 主机级备份允许完整 VM 还原，可以在其中将整个 VM 恢复到相同或不同的群集。 但是，主机级备份无法识别应用程序。 例如，它们不会截断 SQL 日志，也不保证在卷影复制服务 (VSS) 提供的范围之外进行应用程序一致性恢复。 注释 将 Azure Local 虚拟机恢复到另一个集群时，该虚拟机将作为非托管虚拟机恢复。 这意味着，VM 中的所有服务开始工作，但在新 Azure 本地群集上注册 VM 并重新连接到 Azure 中存在的资源之前，无法从 Azure 管理 VM。 重新连接意味着使用新资源组（可选）更新 Azure 资源（可选），也可以将其保留在同一资源组中、自定义位置、存储路径和 VM 的逻辑网络。 如果在同一群集上就地还原 VM，则不需要注册和重新连接。 VM 的 Azure 连接已还原，只要它位于 Azure Arc 的 45 天重新连接窗口中 ，它就会继续从 Azure 进行管理。 主机级 VM 备份 ：在每个 Azure 本地主机（每个群集节点）上安装备份代理，并在虚拟机监控程序级别备份整个 VM。 此方法捕获整个 VM，包括所有虚拟磁盘。 它不需要每个 VM 中的代理，并且与来宾 OS 无关。 主机级备份允许完整 VM 还原，可以在其中将整个 VM 恢复到相同或不同的群集。 但是，主机级备份无法识别应用程序。 例如，它们不会截断 SQL 日志，也不保证在卷影复制服务 (VSS) 提供的范围之外进行应用程序一致性恢复。 将 Azure Local 虚拟机恢复到另一个集群时，该虚拟机将作为非托管虚拟机恢复。 这意味着，VM 中的所有服务开始工作，但在新 Azure 本地群集上注册 VM 并重新连接到 Azure 中存在的资源之前，无法从 Azure 管理 VM。 重新连接意味着使用新资源组（可选）更新 Azure 资源（可选），也可以将其保留在同一资源组中、自定义位置、存储路径和 VM 的逻辑网络。 如果在同一群集上就地还原 VM，则不需要注册和重新连接。 VM 的 Azure 连接已还原，只要它位于 Azure Arc 的 45 天重新连接窗口中 ，它就会继续从 Azure 进行管理。 来宾级 VM 备份 ：在 VM 的来宾 OS 中安装备份代理。 此方法使得在操作系统中运行并支持 VSS 的应用程序进行数据一致性备份，确保应用程序数据在一致状态下被捕获。 例如，可以使用完全保真度备份 SQL 数据库，并轻松还原单个项，例如单一数据库或特定文件。 权衡是可管理性：必须在每个 VM 上管理代理，备份仅涵盖 VM 内部的内容。 若要还原整个 VM，通常会重新生成它，然后在其中还原数据。 来宾级 VM 备份 ：在 VM 的来宾 OS 中安装备份代理。 此方法使得在操作系统中运行并支持 VSS 的应用程序进行数据一致性备份，确保应用程序数据在一致状态下被捕获。 例如，可以使用完全保真度备份 SQL 数据库，并轻松还原单个项，例如单一数据库或特定文件。 权衡是可管理性：必须在每个 VM 上管理代理，备份仅涵盖 VM 内部的内容。 若要还原整个 VM，通常会重新生成它，然后在其中还原数据。 同时使用这两 种方法：许多组织都使用这两种方法的组合。 对于需要特定时间点或项目级恢复的关键应用程序（例如，在不回滚整个虚拟机的情况下恢复单个数据库或文件），请使用客户机级备份。 使用主机级备份快速恢复整个 VM 或从主机故障方案中恢复。 同时使用这两 种方法：许多组织都使用这两种方法的组合。 对于需要特定时间点或项目级恢复的关键应用程序（例如，在不回滚整个虚拟机的情况下恢复单个数据库或文件），请使用客户机级备份。 使用主机级备份快速恢复整个 VM 或从主机故障方案中恢复。 设置 MABS 涉及在群集上的专用 VM 上部署 MABS 服务器软件、配置其本地存储、在 Azure 本地主机和/或来宾上安装保护代理，然后使用要保护的 VM 创建保护组。 保护组定义备份的内容（例如，特定的 VM）、备份计划和本地磁盘或 Azure 上的短期和长期保留策略。 有关为 Azure 本地 VM 安装 MABS 的详细信息，请参阅 使用 Azure 备份服务器备份 Azure 本地虚拟机 。 除了 MABS 之外，合作伙伴备份和恢复供应商的成熟市场为 Azure 本地环境提供了可靠的解决方案。 这些解决方案通常提供一组丰富的高级功能、更广泛的平台支持，以及根据特定组织要求可能有吸引力的不同许可或成本模型。 CloudCasa by Catalogic CloudCasa 为 Azure 本地群集和 Arc 启用群集上的 AKS 提供 Kubernetes 原生备份、灾难恢复和迁移。 它可以保护集群资源和持久卷，并能够执行细粒度的还原，包括文件级恢复。 备份可以存储在 Azure Blob 存储、其他对象存储或网络文件系统（NFS） 中。 CloudCasa 支持将数据恢复到同一站点、第二个 Azure Local 集群或 Azure AKS，以实现灾难恢复。 Azure 市场上的 CloudCasa 适用于 Azure 的 CloudCasa 解决方案 简化 Azure 本地升级和备份 Cohesity DataProtect Cohesity DataProtect 是数据云平台的一部分，它使用单个数据安全平台保护 VM。 它将备份、复制和灾难恢复与无限的不可变快照、精细的文件/VM/数据库还原、大规模大规模还原以及集成的异常情况检测和数据分类相结合，以加快网络事件后清理恢复的速度。 对于 Azure Local，Cohesity 提供与平台的深度集成。 此集成包括自动 VM 发现、基于策略的保护、许多还原选项以及使用Microsoft弹性更改跟踪（RCT）的增量永久备份。 Cohesity 通过利用成熟的 Hyper-V 连接器和工作流来扩展支持，从而在客户将 Hyper-V 工作负载移动到 Azure 本地时提供一致的作模型。 Cohesity DataProtect Azure Local 的支持语句 Cohesity NetBackup Cohesity NetBackup 为 Azure Local 提供可复原的网络数据保护，使组织能够使用跨混合和多云环境依赖的相同企业级平台保护 Azure 本地虚拟机和应用程序。 NetBackup 使用其成熟的 Hyper-V 集成和 Microsoft 弹性更改跟踪（RCT）为 Azure 本地工作负载提供基于策略的永续增量备份。 高效的块级更改捕获可最大程度地减少备份窗口和网络使用情况。 NetBackup 11.x 软件兼容性列表（Hyper-V 和 Azure 本地）中记录了 Azure 本地支持。 Cohesity NetBackup NetBackup 11.x 软件兼容性列表 - Hyper-V 和 Azure 本地 所有版本的 NetBackup 兼容性列表 Commvault Cloud 为 Azure 本地环境提供统一的企业级数据保护，支持跨虚拟机、数据库和非结构化数据的安全备份、恢复和勒索软件保护。 借助智能自动化和策略驱动的工作流，Commvault 简化了合规性，提高了复原能力，并提供了从边缘到云的可缩放保护，同时保持对 Azure 本地区域中数据的完全控制。 适用于 Azure 本地的 Commvault Commvault 市场 SaaS Rubrik Security Cloud 为 Azure 本地环境中部署的虚拟机提供全面的数据保护和安全性。 Rubrik 会执行首次完整备份和永久增量备份，通过不可变、物理隔离且受访问控制的副本确保数据安全。 通过统一的 SaaS 控制平面，组织可以从其 Azure 本地环境管理数据，从而提供关键数据资产的单一视图。 此集成还支持持续威胁监视、威胁搜寻、异常情况检测，并有助于快速网络恢复，从而在攻击后快速将 VM 和应用程序还原到干净状态。 Veeam 备份和复制支持备份和复制 Azure 本地 VM。 使用 Veeam 备份和复制，可以将工作负荷从不同平台或从 Hyper-V 迁移到 Azure 本地。 可以使用即时 VM 恢复执行跨平台还原。 还可以将较旧版本的 Hyper-V 工作负荷复制到 Azure 本地。 Veeam Azure 本地支持 即便硬件容错和 存储空间直通 维护多个数据副本，实现并定期测试数据备份过程仍然至关重要。 存储冗余可防止基础结构故障，但不会防止数据损坏、删除或站点范围的灾难。 定期备份可确保根据需要将数据或整个 VM 还原到以前的时间点。 备份频率和保留 期：确保备份频率与恢复点目标（RPO）保持一致，该目标定义了组织可接受的最大数据丢失量。 根据虚拟机对业务的重要性，使用增量备份计划每天的夜间备份或多个备份（如有必要）。 此外，实施符合业务和符合性要求的保留策略（例如，将每日备份保留两周，每月备份六个月，每年备份七年）。 Azure 备份可通过 Microsoft Azure 备份服务器（MABS）促进短期本地保留和长期基于云的保留。 备份频率和保留 期：确保备份频率与恢复点目标（RPO）保持一致，该目标定义了组织可接受的最大数据丢失量。 根据虚拟机对业务的重要性，使用增量备份计划每天的夜间备份或多个备份（如有必要）。 此外，实施符合业务和符合性要求的保留策略（例如，将每日备份保留两周，每月备份六个月，每年备份七年）。 Azure 备份可通过 Microsoft Azure 备份服务器（MABS）促进短期本地保留和长期基于云的保留。 测试还原 ：备份的重要性在于您是否能够成功还原，因此请务必定期测试从备份中还原 VM 和数据。 定期对隔离网络或实验室群集执行完整的 VM 恢复测试，以确保该过程平稳且及时。 这种做法是灾难恢复策略的一部分，用于保证备份在实际紧急情况下发挥作用。 测试还原 ：备份的重要性在于您是否能够成功还原，因此请务必定期测试从备份中还原 VM 和数据。 定期对隔离网络或实验室群集执行完整的 VM 恢复测试，以确保该过程平稳且及时。 这种做法是灾难恢复策略的一部分，用于保证备份在实际紧急情况下发挥作用。 虽然备份能保护数据并支持特定时间点的恢复，但无法提供即时故障转移功能。 从备份还原可能非常耗时，通常需要几个小时。 对于业务或任务关键型虚拟机，即使最短的停机时间或数据丢失也不可接受，连续复制技术提供了一种手段来维护备份站点中虚拟机的最新副本。 在发生灾难时，这些技术可实现快速故障转移和最小数据丢失。 Azure 本地支持的两种连续复制技术是 Azure Site Recovery 和 Hyper-V 副本。 使用 Azure Site Recovery 将 Azure 本地 VM 复制到 Azure Azure Site Recovery 是Microsoft基于云的灾难恢复解决方案，旨在将本地 VM 复制到 Azure。 Azure Site Recovery 有助于将 Azure 本地 VM 复制到 Azure，确保保护业务关键型工作负荷。 此服务持续将更改从本地 VM 传输到 Azure。 因此，如果本地站点或群集发生重大中断，可以将 VM 切换到 Azure，以确保业务连续性。 有关 Azure Local 的 Azure Site Recovery 的要点： 部署： 自动部署：Azure 本地为 Azure Site Recovery 创建了用于自动部署的扩展。 Azure Site Recovery 扩展可以检测群集的所有节点，并在所有节点上自动部署 Azure Site Recovery，并使用复制策略对其进行配置。 有关详细信息，请参阅 使用 Azure Site Recovery 保护 VM 工作负荷 。 手动部署：适用于 Azure Local 的 Azure Site Recovery 扩展为预览版，仅适用于测试环境。 对于需要生产就绪解决方案的客户，可以使用 Hyper-V Azure 灾难恢复 选项在 Azure 本地群集上手动配置 Azure Site Recovery。 自动部署：Azure 本地为 Azure Site Recovery 创建了用于自动部署的扩展。 Azure Site Recovery 扩展可以检测群集的所有节点，并在所有节点上自动部署 Azure Site Recovery，并使用复制策略对其进行配置。 有关详细信息，请参阅 使用 Azure Site Recovery 保护 VM 工作负荷 。

手动部署：适用于 Azure Local 的 Azure Site Recovery 扩展为预览版，仅适用于测试环境。 对于需要生产就绪解决方案的客户，可以使用 Hyper-V Azure 灾难恢复 选项在 Azure 本地群集上手动配置 Azure Site Recovery。 频繁复制 ：Azure Site Recovery 可以实现 30 秒以下的恢复点目标（RPO）。 频繁复制 ：Azure Site Recovery 可以实现 30 秒以下的恢复点目标（RPO）。 故障转移 ： 一旦复制就绪，即可启动向 Azure 的故障转移。 此过程使用复制的数据在 Azure 中启动 VM。 可以执行测试性故障转移来测试此过程，该过程会在 Azure 上的隔离网络中创建一个 VM 副本进行验证测试，而无需关闭本地 VM。 在实际灾难发生时，如果主站点意外宕机，即使源虚拟机未运行，您也可以执行非计划故障转移。 对于硬件维护或更换等场景，您可以启动计划内故障转移。 此类故障转移会优雅地关闭虚拟机，使其将内存内容写入磁盘，从而确保零数据丢失。 故障转移后，虚拟机在 Azure 中运行。 一旦复制就绪，即可启动向 Azure 的故障转移。 此过程使用复制的数据在 Azure 中启动 VM。 可以执行测试性故障转移来测试此过程，该过程会在 Azure 上的隔离网络中创建一个 VM 副本进行验证测试，而无需关闭本地 VM。 在实际灾难发生时，如果主站点意外宕机，即使源虚拟机未运行，您也可以执行非计划故障转移。 对于硬件维护或更换等场景，您可以启动计划内故障转移。 此类故障转移会优雅地关闭虚拟机，使其将内存内容写入磁盘，从而确保零数据丢失。 故障转移后，虚拟机在 Azure 中运行。 故障回退 ： 当灾难得到缓解，群集恢复正常运行时，Azure Site Recovery 可以扭转复制方向，将在使用 Azure 期间所作的任何更改复制回 Azure 本地群集。 反向复制完成后，您可以将虚拟机故障回退，使操作切换回本地环境。 要成功进行故障回退，本地环境必须处于正常运行状态。 如果您的集群不可用，您可以将另一个 Azure Local 集群注册到 Azure Site Recovery Hyper-V 站点，并将虚拟机故障回退到备用集群上的某个节点。 注释 将 Azure Local 虚拟机故障回退到备用集群时，该虚拟机将作为非托管虚拟机进行故障回退。 这意味着，VM 中的所有服务开始工作，但在新 Azure 本地群集上注册 VM 并重新连接到 Azure 中存在的资源之前，无法从 Azure 管理 VM。 重新连接意味着使用新资源组（可选）更新 Azure 资源（可选），也可以将其保留在同一资源组中、自定义位置、存储路径和 VM 的逻辑网络。 如果虚拟机故障回退到同一集群，则无需进行注册和重新连接。 VM 的 Azure 连接已还原，只要它位于 Azure Arc 的 45 天重新连接窗口中 ，它就会继续从 Azure 进行管理。 当灾难得到缓解，群集恢复正常运行时，Azure Site Recovery 可以扭转复制方向，将在使用 Azure 期间所作的任何更改复制回 Azure 本地群集。 反向复制完成后，您可以将虚拟机故障回退，使操作切换回本地环境。 当灾难得到缓解，群集恢复正常运行时，Azure Site Recovery 可以扭转复制方向，将在使用 Azure 期间所作的任何更改复制回 Azure 本地群集。 反向复制完成后，您可以将虚拟机故障回退，使操作切换回本地环境。 要成功进行故障回退，本地环境必须处于正常运行状态。 如果您的集群不可用，您可以将另一个 Azure Local 集群注册到 Azure Site Recovery Hyper-V 站点，并将虚拟机故障回退到备用集群上的某个节点。 注释 将 Azure Local 虚拟机故障回退到备用集群时，该虚拟机将作为非托管虚拟机进行故障回退。 这意味着，VM 中的所有服务开始工作，但在新 Azure 本地群集上注册 VM 并重新连接到 Azure 中存在的资源之前，无法从 Azure 管理 VM。 重新连接意味着使用新资源组（可选）更新 Azure 资源（可选），也可以将其保留在同一资源组中、自定义位置、存储路径和 VM 的逻辑网络。 如果虚拟机故障回退到同一集群，则无需进行注册和重新连接。 VM 的 Azure 连接已还原，只要它位于 Azure Arc 的 45 天重新连接窗口中 ，它就会继续从 Azure 进行管理。 要成功进行故障回退，本地环境必须处于正常运行状态。 如果您的集群不可用，您可以将另一个 Azure Local 集群注册到 Azure Site Recovery Hyper-V 站点，并将虚拟机故障回退到备用集群上的某个节点。 将 Azure Local 虚拟机故障回退到备用集群时，该虚拟机将作为非托管虚拟机进行故障回退。 这意味着，VM 中的所有服务开始工作，但在新 Azure 本地群集上注册 VM 并重新连接到 Azure 中存在的资源之前，无法从 Azure 管理 VM。 重新连接意味着使用新资源组（可选）更新 Azure 资源（可选），也可以将其保留在同一资源组中、自定义位置、存储路径和 VM 的逻辑网络。 如果虚拟机故障回退到同一集群，则无需进行注册和重新连接。 VM 的 Azure 连接已还原，只要它位于 Azure Arc 的 45 天重新连接窗口中 ，它就会继续从 Azure 进行管理。 有关详细信息和安装 Azure Site Recovery，请参阅 使用 Azure 本地 Azure Site Recovery 保护 VM 工作负荷（预览版）。 使用 Hyper-V 副本进行业务关键虚拟机的连续复制 Hyper-V 副本是 Azure Local 中内置的一项功能，用于在两个 Hyper-V 主机或故障转移群集之间异步复制 VM。 可以使用此技术在两个单独的 Azure 本地群集之间复制 VM，从而提供本地灾难恢复解决方案。 为 VM 启用 Hyper-V 副本时，它会在指定的副本服务器或群集上创建 VM 的初始副本（包括其配置和 VHD）。 Hyper-V 副本，然后跟踪对主 VM 所做的更改，并将其写入日志文件。 它将这些日志传输到副本站点，其中以异步方式将它们应用于副本 VM。 有关将 Hyper-V 副本与 Azure 本地配合使用的要点： 部署： 手动部署 ：无法通过 Azure 门户配置 Hyper-V 副本。 使用 Azure 本地节点上的 PowerShell 对其进行配置。 或者，管理员可以从同一网络中的任何 Windows Server 计算机远程访问 Azure 本地群集，并通过故障转移群集管理器用户界面完成设置。 需要适当的权限才能连接到和管理这两个 Azure 本地群集。 配置 ：使 Azure 本地群集能够充当副本服务器、设置身份验证方法（通常是域中的 Kerberos 或基于证书的非已加入域或跨域方案），配置防火墙规则以允许复制流量，然后基于每个 VM 启用复制。 Per-VM 设置包括指定副本服务器或群集、选择要复制的 VHD、选择复制频率以及定义在副本端维护的恢复点（快照时间）数量。 Hyper-V 复制支持计划内和计划外场景下的复制、测试故障转移、故障转移、反向复制以及故障回退。 手动部署 ：无法通过 Azure 门户配置 Hyper-V 副本。 使用 Azure 本地节点上的 PowerShell 对其进行配置。 或者，管理员可以从同一网络中的任何 Windows Server 计算机远程访问 Azure 本地群集，并通过故障转移群集管理器用户界面完成设置。 需要适当的权限才能连接到和管理这两个 Azure 本地群集。 手动部署 ：无法通过 Azure 门户配置 Hyper-V 副本。 使用 Azure 本地节点上的 PowerShell 对其进行配置。 或者，管理员可以从同一网络中的任何 Windows Server 计算机远程访问 Azure 本地群集，并通过故障转移群集管理器用户界面完成设置。 需要适当的权限才能连接到和管理这两个 Azure 本地群集。 配置 ：使 Azure 本地群集能够充当副本服务器、设置身份验证方法（通常是域中的 Kerberos 或基于证书的非已加入域或跨域方案），配置防火墙规则以允许复制流量，然后基于每个 VM 启用复制。 Per-VM 设置包括指定副本服务器或群集、选择要复制的 VHD、选择复制频率以及定义在副本端维护的恢复点（快照时间）数量。 Hyper-V 复制支持计划内和计划外场景下的复制、测试故障转移、故障转移、反向复制以及故障回退。 配置 ：使 Azure 本地群集能够充当副本服务器、设置身份验证方法（通常是域中的 Kerberos 或基于证书的非已加入域或跨域方案），配置防火墙规则以允许复制流量，然后基于每个 VM 启用复制。 Per-VM 设置包括指定副本服务器或群集、选择要复制的 VHD、选择复制频率以及定义在副本端维护的恢复点（快照时间）数量。 Hyper-V 复制支持计划内和计划外场景下的复制、测试故障转移、故障转移、反向复制以及故障回退。 复制频率 ：可以将复制频率配置为每隔 30 秒、5 分钟或 15 分钟发生一次。 复制频率 ：可以将复制频率配置为每隔 30 秒、5 分钟或 15 分钟发生一次。 故障转移 ： 一旦复制就绪，您即可启动向复制服务器的故障转移。 此操作使用已复制的数据在副本服务器上启动 VM。 您可以通过测试故障转移来验证此操作，该操作会在隔离网络中创建一台虚拟机以供验证，而无需关闭已复制的虚拟机。 在实际灾难期间，如果主站点意外关闭，即使复制的 VM 未运行，也可以执行计划外故障转移。 对于硬件维护或更换等场景，您可以启动计划内故障转移。 此过程以优雅方式关闭复制的 VM，确保其内存已写入磁盘，从而防止任何数据丢失。 故障转移后，您的虚拟机在副本服务器上运行。 注释 将 Azure 本地虚拟机故障转移到副本集群时，该虚拟机将作为未受管虚拟机进行故障转移。 这意味着 VM 中的所有服务都开始工作，但在新 Azure 本地群集上注册 VM 并重新连接到 Azure 中存在的资源之前，无法从 Azure 管理 VM。 重新连接意味着使用新资源组（可选）更新 Azure 资源（可选），也可以将其保留在同一资源组中、自定义位置、存储路径和 VM 的逻辑网络。 如果故障转移是临时的，则可能不需要注册和重新连接，并且一旦灾难得到缓解，虚拟机应恢复到原始群集。 在此期间，VM 无法从 Azure 进行管理，但其服务可正常运行。 一旦复制就绪，您即可启动向复制服务器的故障转移。 此操作使用已复制的数据在副本服务器上启动 VM。 您可以通过测试故障转移来验证此操作，该操作会在隔离网络中创建一台虚拟机以供验证，而无需关闭已复制的虚拟机。 一旦复制就绪，您即可启动向复制服务器的故障转移。 此操作使用已复制的数据在副本服务器上启动 VM。 您可以通过测试故障转移来验证此操作，该操作会在隔离网络中创建一台虚拟机以供验证，而无需关闭已复制的虚拟机。 在实际灾难期间，如果主站点意外关闭，即使复制的 VM 未运行，也可以执行计划外故障转移。 对于硬件维护或更换等场景，您可以启动计划内故障转移。 此过程以优雅方式关闭复制的 VM，确保其内存已写入磁盘，从而防止任何数据丢失。 在实际灾难期间，如果主站点意外关闭，即使复制的 VM 未运行，也可以执行计划外故障转移。 对于硬件维护或更换等场景，您可以启动计划内故障转移。 此过程以优雅方式关闭复制的 VM，确保其内存已写入磁盘，从而防止任何数据丢失。 故障转移后，您的虚拟机在副本服务器上运行。 注释 将 Azure 本地虚拟机故障转移到副本集群时，该虚拟机将作为未受管虚拟机进行故障转移。 这意味着 VM 中的所有服务都开始工作，但在新 Azure 本地群集上注册 VM 并重新连接到 Azure 中存在的资源之前，无法从 Azure 管理 VM。 重新连接意味着使用新资源组（可选）更新 Azure 资源（可选），也可以将其保留在同一资源组中、自定义位置、存储路径和 VM 的逻辑网络。 如果故障转移是临时的，则可能不需要注册和重新连接，并且一旦灾难得到缓解，虚拟机应恢复到原始群集。 在此期间，VM 无法从 Azure 进行管理，但其服务可正常运行。 故障转移后，您的虚拟机在副本服务器上运行。 将 Azure 本地虚拟机故障转移到副本集群时，该虚拟机将作为未受管虚拟机进行故障转移。 这意味着 VM 中的所有服务都开始工作，但在新 Azure 本地群集上注册 VM 并重新连接到 Azure 中存在的资源之前，无法从 Azure 管理 VM。 重新连接意味着使用新资源组（可选）更新 Azure 资源（可选），也可以将其保留在同一资源组中、自定义位置、存储路径和 VM 的逻辑网络。 如果故障转移是临时的，则可能不需要注册和重新连接，并且一旦灾难得到缓解，虚拟机应恢复到原始群集。 在此期间，VM 无法从 Azure 进行管理，但其服务可正常运行。 故障回退 ： 灾难缓解且群集恢复运行后，Hyper-V 副本可以逆转复制方向，将在副本服务器上运行期间进行的任何更改复制回原始 Azure 本地群集。 反向复制完成后，您可以将虚拟机故障回原集群，使其切换回源集群。 注释 当虚拟机恢复到其原始群集后，无需注册和重新连接。 VM 的 Azure 连接已还原，只要它位于 Azure Arc 的 45 天重新连接窗口中 ，它就会继续从 Azure 进行管理。 灾难缓解且群集恢复运行后，Hyper-V 副本可以逆转复制方向，将在副本服务器上运行期间进行的任何更改复制回原始 Azure 本地群集。 灾难缓解且群集恢复运行后，Hyper-V 副本可以逆转复制方向，将在副本服务器上运行期间进行的任何更改复制回原始 Azure 本地群集。 反向复制完成后，您可以将虚拟机故障回原集群，使其切换回源集群。 注释 当虚拟机恢复到其原始群集后，无需注册和重新连接。 VM 的 Azure 连接已还原，只要它位于 Azure Arc 的 45 天重新连接窗口中 ，它就会继续从 Azure 进行管理。 反向复制完成后，您可以将虚拟机故障回原集群，使其切换回源集群。 当虚拟机恢复到其原始群集后，无需注册和重新连接。 VM 的 Azure 连接已还原，只要它位于 Azure Arc 的 45 天重新连接窗口中 ，它就会继续从 Azure 进行管理。 有关详细信息，请参阅 “设置 Hyper-V 副本 ”中的部署步骤。 为 VM 启用 Hyper-V 副本时，它会在指定的副本服务器或群集上创建 VM 的初始副本（包括其配置和 VHD）。 Hyper-V 副本，然后跟踪对主 VM 所做的更改，并将其写入日志文件。 它将这些日志传输到副本站点，并根据可配置的复制频率（例如，每 30 秒、5 分钟或 15 分钟）以异步方式将它们应用到副本 VM。 配置涉及使 Azure 本地群集能够充当副本服务器、设置身份验证方法（通常是域中的 Kerberos 或基于证书的非已加入域或跨域方案），配置防火墙规则以允许复制流量，然后基于每个 VM 启用复制。 Per-VM 设置包括指定副本服务器或群集、选择要复制的 VHD、选择复制频率以及定义在副本端维护的恢复点（快照时间）数量。 Hyper-V 复制支持计划内和计划外场景下的复制、测试故障转移、故障转移、反向复制以及故障回退。 对于 Azure 本地群集到群集复制，必须在每个群集上配置 Hyper-V 副本代理角色。 此代理协调复制，并提供用于接收 VM 更改的群集范围的终结点。 需要在 Azure 本地节点上使用 PowerShell 配置 Hyper-V 副本，或者可以通过与 Azure 本地实例位于同一网络中的任何 Windows Server 计算机上的故障转移群集管理器用户界面远程设置副本。 需要适当的权限才能连接和管理这两个 Azure 本地计算机。 无法从 Azure 门户配置 Hyper-V 副本。 有关详细信息，请参阅 “设置 Hyper-V 副本 ”中的部署步骤。 在复制过程中，你使用的硬件和网络会影响依赖它们的服务。 此过程使用大量的系统资源，具体取决于源系统和目标系统之间复制的数据量。 在此过程完成之前，设备性能会受到影响。 两个 Azure 本地群集之间需要足够的网络带宽，以便 Hyper-V 副本以最佳方式运行，尤其是复制间隔较低的（例如，30 秒）。 同样，目标集群需要具备足够的每秒存储输入输出操作次数（IOPS），以跟上传入的复制流量。 有关详细信息，请参阅 Hyper-V 副本（HVR）的功能和性能优化 。 比较 Azure Site Recovery 和 Hyper-V 复制 在 Azure Site Recovery 和 Azure 本地 VM 的 Hyper-V 副本之间进行选择时，请考虑这两种解决方案之间的差异： 使用 Azure Site Recovery 和 Hyper-V 副本 ：具有具有单个群集的远程站点和具有多个群集的大型中心的组织可以将 Azure 扩展为灾难恢复站点。 对于远程站点使用 Azure Site Recovery，对于较大位置则使用 Hyper-V 副本。 此体系结构允许某些 VM 复制到 Azure，而另一些 VM 则复制到辅助站点，确保针对各种作需求提供灵活性和定制的灾难恢复策略。 必须制定恢复计划，以便在其中记录故障转移工作负载所需的所有步骤，包括顺序（例如，应在应用程序服务器之前激活域控制器），以及任何必要的网络调整（例如 DNS 更新和用户重定向）。 Hyper-V 副本支持创建恢复计划，以便对 VM 组进行排序，并在故障转移过程中集成脚本。 可以通过 PowerShell 手动或编写这些计划脚本。 通过模拟演练定期测试灾难恢复计划。 每月至少进行一次故障转移测试，以确保功能正常并保持人员操作熟练度。 此外，测试还显示是否满足恢复时间目标（RTO），例如在 Azure 或辅助硬件中启动所需的时间。 有关其他信息，请查看 用于设计灾难恢复策略的体系结构策略 。 详细了解 工作负荷复原能力 。 想要尝试使用 Ask Learn 阐明或指导你完成本主题？ Last updated on 2026-09-15