Azure Site Recovery 的核心能力是在物理服务器或虚拟化平台上持续捕获数据变更，异步传输到 Azure 存储，并在目标区域维护一份几乎实时的副本。对于运行 Windows Server 的 Hyper-V 主机或 VMware vSphere 环境，ASR 通过一个轻量级的移动服务代理或 Hyper-V 复制提供程序实现块级增量复制，初始同步后仅传输变更的数据块，有效控制带宽占用。
复制引擎如何工作：从数据变化到云端一致副本
在 Windows Server 上启用 ASR 复制后，每一台受保护的虚拟机都会被分配一个复制策略，定义恢复点目标（RPO）和保留的恢复点数量。以 Hyper-V 为例，如果 Hyper-V 主机运行在 Windows Server 2012 R2 及以上版本，可以选择两种复制模式：基于 Hyper-V 复制（HVR）或基于代理的复制（InMage Scout 内核）。HVR 模式下，Hyper-V 主机直接通过证书认证与 Azure 存储进行通信，无需在虚拟机内部安装任何组件，适合快速批量保护。而代理模式则需要在每台虚拟机内安装移动服务，由配置服务器集中管理复制流，适用于混合环境或对复制粒度要求更高的场景。
无论哪种模式，ASR 都会在源端创建一个恢复点卷快照，将增量数据封装为日志，上传到 Azure 缓存存储账户。Azure 端的管理服务会定期处理这些日志，将其应用到托管磁盘或非托管磁盘的页面 blob 中，形成崩溃一致性恢复点。如果需要应用一致性快照，就需要在虚拟机上集成 ASR 的 VSS 编写器，以便在创建快照前自动冻结 I/O，保证 SQL Server、Exchange 等有状态应用的恢复点可用性。
复制过程中，带宽消耗是关注重点。ASR 允许设置每日数据传输上限，并基于时间表限制复制流量。在 Windows Server 上，可以通过本地组策略或注册表调整 Hyper-V 副本的压缩和频率，但对于 ASR 托管的 HVR，大部分调优参数被封装在 Azure 门户的复制策略中。了解底层原理后，才能更合理地规划网络和存储容量。
在 Windows Server 上完成 ASR 部署的关键步骤
准备工作从 Azure 侧开始：创建一个恢复服务保管库，在目标区域建立虚拟网络、存储账户（或直接使用托管磁盘）。随后下载保管库的注册密钥，用于后续配置服务器的注册。如果保护的是 Hyper-V 虚拟机，建议在 Windows Server 上安装 Azure Site Recovery 提供程序，并通过 PowerShell 或 GUI 将 Hyper-V 主机注册到保管库。
以下 PowerShell 脚本演示如何批量注册 Hyper-V 主机：
# 安装 Azure Site Recovery 提供程序 $installerPath = “C:ASRAzureSiteRecoveryProvider.exe” Start-Process -FilePath $installerPath -ArgumentList “/q /norestart” -Wait # 导入 ASR 模块并注册主机 Import-Module “C:Program FilesMicrosoft Azure Site Recovery ProviderMicrosoft.Azure.SiteRecovery.Provider.PSModule.dll” $vaultCreds = “C:ASRvaultCredentials.VaultCredentials” $friendlyName = “HyperV-Host-01” # 使用保管库凭据文件注册 Register-AzureSiteRecoveryProvider -VaultCredentialsPath $vaultCreds -FriendlyName $friendlyName
注册成功后，在 Azure 门户中的“Site Recovery 基础结构”里添加 Hyper-V 站点，并把注册好的主机分配到该站点。接下来需要创建复制策略，例如将 RPO 设置为 300 秒，应用一致性快照频率为 4 小时，恢复点保留 24 小时。然后将策略关联到 Hyper-V 站点，使策略对所有来自该站点的虚拟机生效。
在 Windows Server 本地，通过“Hyper-V 管理器”或 SCVMM（如果使用）启动“启用复制”向导。选择目标为 Azure，指定保管库和复制策略，确保虚拟机磁盘格式为 VHDX 且大小不超过 Azure 磁盘上限。对于运行 Linux 或旧版 Windows 的虚拟机，如果选择代理模式，则需要先手动在虚拟机内安装移动服务代理。安装完成后，ASR 便会开始初始复制，这一阶段可能会持续数小时，取决于数据量和可用带宽。
故障转移网络规划与常见问题排错
复制建立后，网络配置直接影响故障转移成功率。Azure 站点的虚拟网络需要与本地网络通过站点间 VPN 或 ExpressRoute 建立连接，否则故障转移后的虚拟机将无法与本地网络通信。更关键的是网络映射，它定义了源端虚拟机所在的子网与 Azure 目标子网的对应关系。如果未预先配置映射，故障转移时虚拟机将落在 Azure 默认子网，IP 地址也变为动态分配，这会破坏依赖固定 IP 的应用。
一个常见错误是：在测试故障转移时发现虚拟机无法启动，检查后往往是因为虚拟机大小（Azure VM Size）与源端磁盘配置不兼容。例如，源端虚拟机拥有超过 64 个数据磁盘，或使用了 Azure 不支持的磁盘控制器类型。此时应提前在复制设置中调整计算和网络属性，指定合适的虚拟机大小，并确保磁盘驱动为 IDE 或 SCSI 且启用集成服务。
RPO 持续较大的问题多由网络抖动或防火墙拦截所致。ASR 复制流量默认使用 HTTPS 443 端口出站，如果 Windows Server 防火墙或企业代理没有放行 Azure 数据中心 IP 范围，数据上传就会延迟。可以通过 Azure 门户的“Site Recovery 基础结构 - Hyper-V 主机”监控代理连接状态，同时在 Windows Server 事件查看器的“应用程序和服务日志 - Microsoft-Azure Site Recovery”中分析具体错误码，例如 7801 表示与存储服务连接超时。
对于需要保留原 IP 地址的场景，可以在故障转移计划中启用“使用复制网络中定义的 IP 地址”选项，前提是目标子网的地址空间与源端一致，且已在 Azure 中将该 IP 设置为静态私有 IP。在测试故障转移时，建议使用独立的隔离网络，避免与生产环境 IP 冲突。完成测试后务必执行清理，否则测试虚拟机将继续产生费用。
自动化运维团队还可以借助 Azure PowerShell 或 CLI 编排复杂故障转移流程。例如，下面的命令可启动计划内故障转移，并将虚拟机恢复到最近的恢复点：
$vault = Get-AzRecoveryServicesVault -Name “MyASRVault”
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
$fabric = Get-AzRecoveryServicesAsrFabric -FriendlyName “PrimarySite”
$protectionContainer = Get-AzRecoveryServicesAsrProtectionContainer -Fabric $fabric
$replicatedItem = Get-AzRecoveryServicesAsrReplicationProtectedItem -ProtectionContainer $protectionContainer | Where-Object { $_.FriendlyName -eq “WebServer01” }
# 启动计划内故障转移
Start-AzRecoveryServicesAsrPlannedFailoverJob -ReplicationProtectedItem $replicatedItem -Direction PrimaryToRecovery -Action PlannedFailover
持续监控复制健康度也至关重要。可以配置 Azure Monitor 警报，当复制状态变为“严重”或 RPO 超出阈值时自动通知运维组。这样结合 Windows Server 的性能计数器与 ASR 的内置诊断，能够构建一个闭环的灾备可视化管理体系。
Azure_Site_RecoveryWindows_Server虚拟机复制修改时间：2026-08-12 10:03:42