Azure到Azure站点恢复重保护时NIC未随VM清理问题咨询

这种情况大概率和你故障转移时用脚本修改NIC的操作有关，我来拆解原因和对应的解决办法：

为什么脚本会导致NIC残留？ #

Azure Site Recovery（ASR）在故障转移后，会自动管理它创建的VM和关联资源（包括默认的NIC）。但当你用脚本给NIC添加公网IP这类额外关联资源后，这个NIC就被标记为用户自定义修改过的资源了——ASR的自动清理逻辑只会删除它完全管控的、没有被外部操作修改过的资源，一旦NIC有了额外的依赖（比如绑定的公网IP），ASR就不会自动删除它，避免误删你手动配置的资源。

彻底清理现有残留NIC的步骤 #

你可以手动清理这些残留资源，注意要先解除NIC的依赖关系：

• 第一步：解绑NIC上的公网IP
  用Azure PowerShell或者CLI先移除NIC和公网IP的关联：

  # PowerShell命令示例
  $nic = Get-AzNetworkInterface -Name "<你的NIC名称>" -ResourceGroupName "<资源组名称>"
  $nic.IpConfigurations[0].PublicIpAddress = $null
  Set-AzNetworkInterface -NetworkInterface $nic
  

  或者Azure CLI：

  az network nic ip-config update --name ipconfig1 --nic-name "<你的NIC名称>" --resource-group "<资源组名称>" --remove publicIpAddress
  

• 第二步：删除残留的NIC
  解绑依赖后，就可以直接删除NIC了：

  Remove-AzNetworkInterface -Name "<你的NIC名称>" -ResourceGroupName "<资源组名称>" -Force
  

• 第三步：清理关联的公网IP/NSG（如果不再需要）
  如果你不需要这些手动添加的公网IP和NSG，也可以一并删除。

调整流程避免后续再出现这个问题 #

为了让ASR能正常清理故障转移后的资源，你需要调整脚本和恢复计划：

• 在恢复计划中添加前置清理步骤：在触发重新保护操作之前，先运行一个脚本解绑NIC上的公网IP，移除所有额外依赖，让NIC回到ASR可管控的状态。
• 修改原有的添加公网IP脚本：可以在脚本中给NIC添加一个自定义标签（比如ASR-Managed: True），或者确保脚本只在故障转移后的临时VM上生效，当需要清理时能快速识别并解除关联。
• 利用ASR的恢复计划钩子：把添加公网IP的操作整合到ASR的恢复计划中，同时在重新保护的准备阶段添加反向的清理脚本，形成完整的闭环。

额外提示 #

如果之后还有类似的自定义资源修改操作，记得先确认ASR的资源管理逻辑：ASR不会自动删除带有用户自定义依赖的资源，所以任何对ASR创建资源的修改，都要配套对应的清理步骤，才能保证整个故障转移-重新保护-清理流程的完整性。

内容的提问来源于stack exchange，提问作者tank104