有关 Azure Site Recovery 的一般问题

通过协调和自动化 Azure VM 复制（本地区域虚拟机和物理服务器到 Azure；本地计算机到辅助数据中心），Site Recovery 可帮助实现业务连续性与灾难恢复 (BCDR) 策略。 了解详细信息。

否，Azure Site Recovery 不支持在虚拟机上运行的 Docker 工作负载。 若要使用 Site Recovery 保护这些虚拟机，请排除已安装 Docker 的磁盘。

Site Recovery 采取各种措施来确保数据完整性。 使用 HTTPS 协议在所有服务之间建立安全连接。 这可确保任何恶意软件或外部实体都无法篡改数据。 采用的另一个措施是使用校验和。 源和目标之间的数据传输是通过计算它们之间数据的校验和来执行的。 这可确保传输的数据是一致的。

Azure 不支持永久性 MAC 地址，因此，使用基于 MAC 的许可证模型的软件无法用于本地到 Azure 的迁移或灾难恢复。

否，Azure Site Recovery 目前不支持临时磁盘。

Azure 恢复服务代理代理用于配置/注册到 Site Recovery 服务，以及监视所有组件的运行状况。 此组件是整个 Azure Site Recovery 本地基础结构的基本构建基块之一。 它有助于将工作负载从本地站点复制到另一个 Azure 区域，并在发生灾难时故障转移到 Azure。

是的，站点恢复同时支持专用与共享的基础结构模型。

不是。 租户标识是匿名的。 租户不需要访问 Site Recovery 门户。 只有服务提供商管理员才能与门户交互。

如果是复制到 Azure，应用程序数据将发送到 Azure 存储而不是站点恢复服务。 数据进行传输中加密 (HTTPS) 并在 Azure 中保持加密状态。

不是。 Azure 直接与服务提供商保持计费关系。 服务提供商责任为其租户生成特定的帐单。

不需要，数据会复制到订阅中的 Azure 存储。 执行测试故障转移（灾难恢复演练）或实际的故障转移时，Site Recovery 会在订阅中自动创建虚拟机。

是的。

我们支持 Azure Pack、云平台系统和基于 System Center 的（2012 和更高版本）的部署。 了解更多有关 Azure Pack 和 Site Recovery 集成的信息。

否，只能将 Hyper-V 虚拟机复制到 Azure。

请查看 Site Recovery 定价详细信息。

可以使用定价计算器来估算使用 Site Recovery 时的费用。

是的，使用 Site Recovery 复制虚拟机时，使用缓存存储帐户会产生额外的费用。 当副本存储的类型为托管磁盘或非托管磁盘时，缓存存储帐户成本保持不变。

是的。 在前 31 天内，每个受保护的实例不会产生任何 Azure Site Recovery 费用。 例如，你在过去六个月内保护了 10 个实例，现在你将第 11 个实例连接到 Azure Site Recovery，在连接后的前 31 天内，第 11 个实例不会产生任何费用。 而前 10 个实例将继续产生 Azure Site Recovery 费用，因为它们受到保护的时间已超过 31 天。

是，尽管受保护实例的 Site Recovery 在前 31 天内为免费，但可能会产生 Azure 存储、存储事务和数据传输的费用。 恢复后的虚拟机也可能会产生 Azure 计算费用。

灾难恢复演练不会产生任何单独的成本。 如果在测试性故障转移后创建虚拟机，则会产生计算费用。

不会。站点恢复不拦截复制的数据，也不拥有虚拟机或物理服务器上运行哪些项目的任何相关信息。 复制数据在本地 Hyper-V 主机、VMware 虚拟机监控程序或物理服务器和 Azure 存储或辅助站点之间交换。 站点恢复并不具有拦截该数据的能力。 只有协调复制与故障转移所需的元数据将发送到站点恢复服务。

站点恢复已通过 ISO 27001:2013、27018、HIPAA、DPA 认证，目前正在接受 SOC2 和 FedRAMP JAB 评估。

是的。 在某个区域中创建站点恢复保管库时，我们确保启用和协调复制与故障转移时所需的一切元数据都保留在该区域的地理边界范围内。

将虚拟机和物理服务器复制到 Azure 时，同时支持传输中加密和静态加密（Azure 中）。

是，对于 Azure 到 Azure Site Recovery 方案，默认强制实施 TLS 1.2 协议。

复制项上安装的移动代理仅通过 TLS 1.2 与进程服务器通信。 但是，从配置服务器到 Azure 以及从进程服务器到 Azure 的通信可以通过 TLS 1.1 或 1.0 进行。 请按照指南在设置的所有配置服务器和进程服务器上强制实施 TLS 1.2。

Azure Site Recovery 的微服务之间的所有通信均通过 TLS 1.2 协议进行。 Site Recovery 使用系统 (OS) 中配置的安全提供程序，并使用可用的最新 TLS 协议。 用户需要在注册表中显式启用 TLS 1.2，然后 Site Recovery 将开始使用 TLS 1.2 与服务进行通信。

可转到“标识”设置来打开恢复服务保管库的托管标识。 将保管库注册到 Microsoft Entra ID 后，可以转到存储帐户，向保管库分配以下角色：

• 基于资源管理器的存储帐户（标准类型）：
  • 参与者
  • 存储 Blob 数据参与者
• 基于资源管理器的存储帐户（高级类型）：
  • 参与者
  • 存储 Blob 数据所有者
• 经典存储帐户：
  • 经典存储帐户参与者
  • 经典存储帐户密钥操作员服务角色

Azure Site Recovery 不会跟踪源 OS 外部的源虚拟机更改。 例如，如果使用 Azure 到 Azure 复制并更改源虚拟机的大小，则源虚拟机大小的更改不会复制到目标虚拟机。

• Azure 虚拟机：Site Recovery 可以复制受支持 Azure 虚拟机上运行的任何工作负载。
• Hyper-V 虚拟机：Site Recovery 可以保护 Hyper-V 虚拟机上运行的任何工作负载。
• 物理服务器：站点恢复可以保护运行 Windows 或 Linux 的物理服务器。
• VMware 虚拟机：Site Recovery 可以保护 VMware 虚拟机上运行的任何工作负载。

可以使用 Site Recovery 来保护受支持虚拟机或物理服务器上运行的大多数工作负载。 站点恢复为应用程序感知型复制提供支持，因此，应用可以恢复为智能状态。 它除了与 Microsoft 应用程序（例如 SharePoint、Exchange、Dynamics、SQL Server 及 Active Directory）集成之外，还能与行业领先的供应商（包括 Oracle、SAP、IBM 及 Red Hat）紧密配合。 详细了解工作负荷保护。

是的。 使用站点恢复来协调分支机构的复制与故障转移时，可以在一个中心位置获得所有分支机构工作负载的统一视图。 不需要前往分支机构，就可以从总部轻松对所有分支机构运行故障转移和管理灾难恢复。

是，Site Recovery 支持 Azure 区域之间的 Azure 虚拟机灾难恢复。 查看有关 Azure 虚拟机灾难恢复的常见问题。 如果要在同一大洲的两个 Azure 区域之间进行复制，请使用 Azure 到 Azure 灾难恢复产品/服务。 无需设置配置服务器/进程服务器和 ExpressRoute 连接。

是，Site Recovery 支持本地 VMware 虚拟机的灾难恢复。 查看有关 VMware 虚拟机灾难恢复的常见问题。

是，Site Recovery 支持本地 Hyper-V 虚拟机的灾难恢复。 查看有关 Hyper-V 虚拟机灾难恢复的常见问题。

是，Site Recovery 支持将运行 Windows 和 Linux 的本地物理服务器灾难恢复到 Azure。 了解灾难恢复到 Azure 的要求。 故障转移后，物理服务器在 Azure 中作为虚拟机运行。 当前不支持从 Azure 故障回复到本地物理服务器。 只能故障回复到 VMware 虚拟机。

否，Azure Site Recovery 不支持移动托管了受保护虚拟机的恢复服务保管库。

Azure Site Recovery 通过公共终结点将数据复制到 Azure 存储帐户或托管磁盘。 但是，也可以通过站点到站点 VPN 执行复制。 站点到站点 VPN 连接允许组织将现有网络连接到 Azure 或将 Azure 网络相互连接。 站点到站点 VPN 通过 Internet 上的 IPSec 隧道发生，它使用 Azure 中现有的本地边缘网络设备和网络设备，例如 Azure 虚拟专用网 (VPN) 网关等原生功能或第三方选项（例如 Check Point CloudGaurd、Palo Alto NextGen 防火墙）。

• 通过公共 Internet 到 Microsoft Edge 的专用连接
• 使用专用终结点为安全性配置的恢复服务保管库
• 通过客户专用虚拟网络连接进行复制
• 轻松过渡到“将来状态”
• 无 SLA，延迟可能更高
• 需要本地 VPN 设备可用性

我们的合作伙伴 Riverbed 提供有关使用 Azure Site Recovery 的详细指导。 查看其解决方案指南。

能，可以使用 ExpressRoute 将本地虚拟机复制到 Azure。

• Azure Site Recovery 通过公共终结点将数据复制到 Azure 存储。 需要设置 Azure 对等互连或使用现有公共对等互连（对于新线路已弃用）来使用 ExpressRoute 进行 Site Recovery 复制。
• 在复制时，建议使用 Azure 对等互连作为路由域。
• 请注意，仅当为保管库启用了专用终结点时，才支持通过专用对等互连进行复制。
• 如果要保护 VMware 计算机或物理计算机，请确保也满足配置服务器的网络要求。 配置服务器需要与特定 URL 连接才能编排 Site Recovery 复制。 ExpressRoute 不能用于此连接。
• 将虚拟机故障转移到 Azure 虚拟网络后，可以使用通过 Azure 虚拟网络设置的专用对等互连对其进行访问。

Azure Site Recovery 不支持将存储帐户用作目标存储。 建议将托管磁盘用作计算机的目标存储。 托管磁盘仅支持使用 LRS 类型进行数据复原。

• Hyper-V：可以每隔 30 秒（高级存储除外）或 5 分钟复制一次 Hyper-V 虚拟机。
• Azure 虚拟机、VMware 虚拟机、物理服务器：复制频率在此处不相关。 复制是连续的。

不支持扩展或链式复制。 请在反馈论坛中请求此功能。

不支持此操作。 请在反馈论坛中请求此功能。

使用 Azure 门户将 VMware 虚拟机和 Hyper-V 虚拟机复制到 Azure 时，此功能受支持。

复制 Hyper-V 虚拟机以及将 VMware 虚拟机和物理计算机复制到 Azure 时，支持动态磁盘。 操作系统磁盘必须为基本磁盘。

是的。 可从以下文章详细了解如何限制带宽：

• 复制 VMware 虚拟机和物理服务器之前的容量规划
• 将 Hyper-V 虚拟机复制到 Azure 之前的容量规划

是的。 适用于 Linux 操作系统的 Azure Site Recovery 支持通过应用程序自定义脚本实现应用一致性。 在应用一致性期间，Azure Site Recovery 移动代理会使用带有 pre 和 post 选项的自定义脚本。 可使用以下步骤来启用此功能。

1. 以 root 身份登录计算机。

2. 将目录更改为 Azure Site Recovery 移动代理安装位置。 默认位置为“/usr/local/ASR”
   # cd /usr/local/ASR

3. 在安装位置下将目录更改为“VX/scripts”
   # cd VX/scripts

4. 使用 root 用户的执行权限创建名为“customscript.sh”的 bash shell 脚本。
   a. 脚本应支持“--pre”和“--post”（请注意双短划线）命令行选项
   b. 使用 pre 选项调用脚本时，它应冻结应用程序输入/输出；使用 post 选项调用时，它应解冻应用程序输入/输出。
   c. 示例模板 -
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. 对于需要应用一致性的应用程序，请在 pre 和 post 步骤中添加冻结和解冻输入/输出命令。 可以选择添加另一个脚本来指定这些命令，并使用 pre 和 post 选项从“customscript.sh”调用该脚本。

复制策略定义了恢复点的保留历史记录设置。 此策略还定义了应用一致性快照的频率。 默认情况下，Azure Site Recovery 使用以下默认设置创建新的复制策略：

• 恢复点历史记录的保留期为一天。
• 无应用一致性快照。

故障一致性恢复点包含，与在快照期间从服务器拔下电源线时一样的磁盘上数据。 故障一致性恢复点不包含在拍摄快照时的任何内存中数据。

目前，大多数应用程序都可以从崩溃一致性快照正常恢复。 对于无数据库操作系统以及文件服务器、DHCP 服务器、打印服务器等应用程序而言，崩溃一致性恢复点已足够。

Site Recovery 每隔 5 分钟创建崩溃一致性恢复点。

应用程序一致性恢复点是从应用程序一致性快照创建的。 应用一致性恢复点除了捕获与故障一致性快照相同的数据，还捕获内存中数据以及进程中的所有事务。

由于包含额外内容，因此应用一致性快照涉及最多且耗时最长。 我们建议对数据库操作系统以及 SQL Server 等应用程序使用应用程序一致性恢复点。

应用一致性恢复点捕获内存中和进程中的所有数据。 因为恢复点捕获此类数据，所以它们需要 Windows 上的卷影复制服务等框架来让应用处于静止状态。 如果捕获过程频繁发生，当工作负荷已经很忙时，它可能会影响性能。 对于非数据库工作负荷，建议不要对应用一致性恢复点使用低频率。 即使对于数据库工作负荷，1 小时也足够了。

Site Recovery 可以创建最低频率为 1 小时的应用一致性恢复点。

为了理解 Site Recovery 如何生成恢复点，让我们来看一个复制策略示例。 此复制策略有一个恢复点，它的保留期为 1 天，应用一致性快照频率为 1 小时。

Site Recovery 每隔 5 分钟创建崩溃一致性恢复点。 你无法更改此频率。 对于过去 2 小时，有 24 个故障一致性恢复点和 2 个应用一致性恢复点可供你选择。 一段时间后，Site Recovery 将删除 2 小时以前的所有恢复点，每小时只保存一个恢复点，这样持续长达 24 小时的时间。

以下屏幕截图演示了该示例。 在屏幕截图中：

• 在过去 2 小时内，有一些频率为 5 分钟的恢复点。

• 在过去 2 小时之前，Site Recovery 每小时只保留一个恢复点。

  

可以使用的最早恢复点对于托管磁盘是 15 天，对于非托管磁盘是 3 天。

不会，Site Recovery 将保留以前的所有恢复点。 根据恢复点的保留期，Site Recovery 仅在生成新点时才替换最早的点。 由于此问题，Site Recovery 无法生成任何新的恢复点。 在有新的恢复点之前，所有旧的恢复点都将在到达保留期后保留。

转到“Site Recovery 保管库”>“Site Recovery 基础结构”>“复制策略”。 选择要编辑的策略，然后保存所做的更改。 所有更改也会应用于所有现有复制。

生成的第一个恢复点包含完整副本。 任何后续恢复点包含增量更改。

是，如果你将保留期从一天延长到三天，Site Recovery 会额外保存恢复点两天。 增加的时间将产生存储费用，因为需要额外保存 12 个恢复点，保留期从一天增加至三天。 例如，一个恢复点可能有 10GB 的增量更改，每月每 GB 的费用为 $0.16。 额外费用为每月 $1.60 × 12。

可以通过安全的 Internet 连接或者站点到站点 VPN 或 Azure ExpressRoute 访问 Azure 虚拟机。 在连接之前需要做许多准备。 了解详细信息。

Azure 具有复原能力。 Site Recovery 已能够根据 Azure SLA 故障转移到辅助 Azure 数据中心。 发生此情况时，我们确保元数据和保管库都保留在为保管库选择的相同地理区域。

可以从辅助站点触发非计划的故障转移。 站点恢复不需要来自主站点的连接即可执行故障转移。

故障转移不是自动的。 可以在门户中单击一下来启动故障转移，或者使用站点恢复 PowerShell 来触发故障转移。 在站点恢复门户中可以轻松进行故障回复。

要自动化，可以使用本地 Orchestrator 或 Operations Manager 来检测虚拟机故障，并使用 SDK 来触发故障转移。

• 详细了解恢复计划。
• 详细了解故障转移。
• 详细了解如何故障回复 VMware 虚拟机和物理服务器

是，可以使用备用位置恢复从 Azure 故障回复到另一个主机。

• 对于 VMware 虚拟机
• 针对 Hyper-V 虚拟机

在从源位置将计算机故障转移到目标位置后，会有三个选项可供选择。 这三个选项的作用各不相同：

1. 完成迁移意味着你将不会再返回到源位置。 你已经迁移到目标区域，现在已经完成操作了。 单击“完成迁移”，会在内部触发“提交”，然后会触发“禁用复制”。
2. “提交”意味着这并不是复制过程的结束。 复制项和所有配置将会保留，并且你可以在以后某个时间点击“重新保护”，以便让计算机复制能够返回到源区域。
3. “禁用复制”会禁用复制并删除所有相关配置。 此选项不会影响目标区域中已经存在的计算机。

是的。 可以使用 REST API、PowerShell 或 Azure SDK 将站点恢复工作流自动化。 当前支持的使用 PowerShell 部署站点恢复的方案：

• 将 VMM 云中的 Hyper-V 虚拟机复制到 Azure PowerShell 资源管理器
• 将 Hyper-V 虚拟机复制（不使用 VMM）到 Azure PowerShell 资源管理器
• 使用 PowerShell 资源管理器将 VMware 复制到 Azure

否，AzureRM 模块的停用不会影响 Site Recovery 自动更新的工作方式。 内部 runbook 不需要任何更改，并且已使用的 REST API 继续按照预期方式作用于自动化帐户。

了解有关新更新的信息，并获取汇总信息。

后续步骤

• 阅读 站点恢复概述