已知问题 - Azure Stack Hub上的Azure Site Recovery

本文介绍有关Azure Stack Hub Azure Site Recovery的已知问题。有关Azure Stack Hub Azure Site Recovery中当前已知问题和限制的详细信息，请使用以下部分。

支持的最大磁盘大小为 1,022 GB

保护虚拟机（VM）时，Azure Site Recovery需要向现有磁盘添加额外的 1 GB 数据。由于Azure Stack Hub磁盘的最大大小限制为 1,023 GB，因此受Site Recovery保护的磁盘的最大大小必须等于或小于 1022。

尝试保护磁盘大小为 1023 GB 的虚拟机时，会发生以下行为：

启用保护成功，因为创建了仅 1 GB 且可供使用的种子磁盘。此步骤中没有错误。
复制在 (百分比)% 同步时被阻止，一段时间后，复制的运行状况会变为严重，并出现错误 AzStackToAzStackSourceAgentDiskSourceAgentSlowResyncProgressOnPremToAzure。发生此错误的原因是，在复制期间，Site Recovery尝试将种子磁盘的大小调整为 1,024 GB 并写入该磁盘。此作失败，因为Azure Stack Hub不支持 1,024 GB 磁盘。
为此磁盘创建的种子磁盘（在目标订阅中）大小仍为 1 GB， 活动日志 显示一些 写入磁盘 故障，并显示错误消息 “disk.diskSizeGb”的值“1024”超出范围。值“1024”必须介于“1”和“1023”（含）之间。

此问题的当前解决方法是创建新磁盘（1,022 GB 或更少），将其附加到源 VM，将数据从 1,023 GB 磁盘复制到新磁盘，然后从源 VM 中删除 1,023 GB 磁盘。完成此过程后，VM 的所有磁盘较小或等于 1,022 GB，可以使用Azure Site Recovery启用保护。

重新保护：设备上的可用数据磁盘插槽

确保设备 VM 有足够的数据磁盘槽，因为用于重新保护的副本磁盘已附加到设备。
允许同时重新保护的磁盘数最初为 31 个。从市场项创建的设备的默认大小为 Standard_DS4_v2，它最多支持 32 个数据磁盘，并且设备本身会使用一个数据磁盘。
如果受保护 VM 的总数大于 31，请执行以下操作之一：
- 将需要重新保护的 VM 拆分为较小的组，以确保同时重新保护的磁盘数不超过设备支持的最大数据磁盘数。
- 增加 Azure Site Recovery 设备虚拟机的容量。
注意事项

我们不会针对设备 VM 测试和验证大型 VM SKU。
如果尝试重新保护 VM，但设备上没有足够的槽来保存复制磁盘，则 会出现错误消息“内部错误 ”。可以检查设备上当前的数据磁盘数，或登录到设备，转到 Event Viewer，并在 Applications 和服务日志下打开 Azure Site Recovery的日志：

查找最新警告以识别问题。

不支持 Linux VM 内核版本

通过运行命令 uname -r检查内核版本。

有关支持的 Linux 内核版本的详细信息，请参阅 Azure Azure support matrix。
在支持的内核版本下，故障转移会导致 VM 重启，可能使故障转移的 VM 更新为不支持的较新内核版本。若要避免由于故障转移 VM 重启而导致的更新，请运行以下命令 sudo apt-mark hold linux-image-azure linux-headers-azure ，以便内核版本更新可以继续。
对于不受支持的内核版本，请通过在 VM 上运行相应的命令来检查是否有可以回滚的旧内核版本：
- Debian/Ubuntu： dpkg --list | grep linux-image
下图显示了在版本 5.4.0-1103-azure（不受支持）上的 Ubuntu 虚拟机中的一个示例。命令运行后，可以看到支持的版本 5.4.0-1077-azure，该版本已安装在 VM 上。有了这些信息，你可以回滚到支持的版本。
使用以下步骤回滚到受支持的内核版本：
1. 首先，创建 /etc/default/grub 的副本，以防出现错误;例如， sudo cp /etc/default/grub /etc/default/grub.bak.
2. 然后，修改 /etc/default/grub ，将 GRUB_DEFAULT 设置为要使用的早期版本。你可能遇到类似于 GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.4.0-1077-azure" 的内容。
3. 选择 “保存” 以保存文件，然后选择“ 退出”。
4. 运行 sudo update-grub。
5. 最后，重启 VM 并继续回滚到受支持的内核版本。
如果没有可回滚到的旧内核版本，请等待移动代理更新完成，然后你的内核可受支持。更新会自动完成，如果已准备就绪，你可以在门户上检查版本以确认：

目前不支持重新保护手动重新同步

重新保护作业完成后，按顺序启动复制。在复制期间，可能存在需要重新同步的情况，这意味着会触发新的初始复制来同步所有更改。

有两种类型的重新同步：

自动重新同步。无需用户操作，可自动完成。用户可以查看门户上显示的一些事件：
手动重新同步。需要用户操作以手动触发重新同步。在以下情况下需要手动重新同步：
- 为重新保护选择的存储帐户缺失。
- 设备上的复制磁盘缺失。
- 复制写入超出了设备上复制磁盘的容量。
  
  提示
  
  还可以在 “事件 ”中找到手动重新同步原因，以帮助确定是否需要手动重新同步。

PowerShell 自动化中的已知问题

如果将$failbackPolicyName和$failbackExtensionName留空或为 null，则重新保护可能会失败。请看以下示例：

始终指定 $failbackPolicyName 和 $failbackExtensionName，如以下示例所示：

$failbackPolicyName = "failback-default-replication-policy"
$failbackExtensionName = "default-failback-extension"
$parameters = @{
    "properties" = @{
        "customProperties" = @{
            "instanceType" = "AzStackToAzStackFailback"
            "applianceId" = $applianceId
            "logStorageAccountId" = $LogStorageAccount.Id
            "policyName" = $failbackPolicyName
            "replicationExtensionName" = $failbackExtensionName
        }
    }
}
$result = Invoke-AzureRmResourceAction -Action "reprotect" ` -ResourceId $protectedItemId ` -Force -Parameters $parameters

移动服务代理警告

复制多个虚拟机时，可能会在 Site Recovery 作业中看到受保护的项的运行状况已更改为警告错误。

此错误消息应仅为警告，而不是实际复制或故障转移过程的阻碍问题。

提示

可以检查相应 VM 的状态，以确保其正常运行。

删除设备虚拟机（源）会防止删除保管库（目标）

若要删除目标上的 Azure Site Recovery 保管库，必须先删除所有受保护的 VM。如果首先删除设备 VM，则Site Recovery保管库会阻止删除受保护的资源，并尝试删除保管库本身也会失败。删除资源组也失败，要删除保管库，唯一的方法是删除创建保管库的 Azure Stack Hub 用户订阅。

要避免此问题，请确保先从保管库中的所有项中移除保护，然后再删除设备 VM。保管库因此可以完成源端设备上的资源清理。删除受保护的项后，就可以删除保管库并移除设备虚拟机。

后续步骤

Azure Stack Hub 上的 Azure Site Recovery。
Azure Site Recovery 在 Azure Stack Hub 上的容量规划。

Last updated on 2026-03-10

通过