azure-site-recovery

Azure Site Recovery

Azure Site Recovery (ASR) 是灾难恢复即服务，可将 Azure VM 和本地计算机复制到辅助区域，并协调故障转移与故障恢复，确保工作负载在区域中断期间仍可用。它是业务连续性的重要组成部分，与备份不同，但可与备份互为补充。

何时使用

为关键工作负载提供区域级灾难恢复，并具备经过测试、可协调的故障转移能力。使用此技能设置 RPO / RTO、设计恢复计划并运行测试故障转移。

不要将此技能用于时间点备份（use Azure Backup）、仅针对数据库的高可用性，或未采用 Azure 特定设计的通用 BCDR 策略。

按 RPO / RTO 对工作负载分层

工作负载层级	RPO 目标	RTO 目标	策略
Tier 0 - 任务关键型	< 1 分钟	< 15 分钟	主动-主动多区域（不能仅依靠 ASR）；将 ASR 作为热备用
Tier 1 - 业务关键型	< 15 分钟	< 1 小时	ASR 持续复制 + 自动化恢复计划
Tier 2 - 重要	< 1 小时	< 4 小时	ASR 复制 + 手动故障转移
Tier 3 - 标准	< 24 小时	< 24 小时	Azure Backup + 在辅助区域还原
Tier 4 - 开发 / 测试	7 天	7 天	仅使用 Azure Backup；无需灾难恢复

**经验法则：**如果 RPO 低于 1 分钟或 RTO 低于 15 分钟，仅靠 ASR 不够

• 应设计主动-主动架构。对于 Tier 1 和 Tier 2，ASR 是合适的方案（RPO 为数分钟， RTO < 4 小时）。

方法

1. 为每个工作负载定义 RPO 和 RTO — 由工作负载负责人和业务方签字确认，而不是由 IT 猜测。按表格分层。记录“Tier 3 = 备份-还原， 而非故障转移”这一假设。 验证：已记录 RPO / RTO，并由每个 Tier 1 / Tier 2 工作负载的相关方签字确认。

2. 在配对区域中设置 Recovery Services 保管库 — 使用 Azure 配对 区域（例如 North Europe ↔ West Europe），以获得更低延迟、优化计费并采用 Microsoft- 协调的修补方式。每个业务部门的每对区域配置一个保管库。 验证：保管库位于辅助区域；已创建复制策略（例如保留 24 小时， 每 4 小时创建一次应用一致性快照）。

3. 为 Tier 1 / Tier 2 VM 启用复制 — 复制按 VM 配置。选择目标 区域、目标 VNet、目标存储，以及是否与源环境对齐 可用性区域。初始复制可能需要数小时 - 请规划带宽。 验证：所有范围内 VM 的复制运行状况均为正常；最新恢复点的时间 戳在 RPO 目标范围内。

4. 构建按顺序启动的恢复计划 — 按应用对 VM 分组；指定 启动顺序（先启动 DB 层，然后是应用层，最后是 Web 层）。添加前置 / 后置脚本 （Automation runbook），用于更新 DNS、更改 IP 和预热应用。添加需要人工验证的 手动操作暂停点。 验证：恢复计划已在测试故障转移中完成演练；已为值班 团队记录运行手册。

5. 考虑恢复区域中的依赖项 — 身份（Entra 是全局服务；AD DC 需要区域 DC 或 DR DC）、DNS（专用 DNS 区域）、Key Vault（区域复制或异地 复制）、存储帐户（GRS 或 RA-GRS）、网络（对等互连、网关、防火墙）、 许可证。 验证：依赖关系图已完成；恢复区域的 DNS 和 DC 可访问，且 Key Vault、 网关连接正常。

6. 按计划测试故障转移 — 至少每 6 个月在辅助区域的隔离网络中运行一次 测试故障转移（Tier 1 工作负载建议每季度测试一次）。验证应用功能，记录实际用时与 RTO 目标的对比，并记录问题。 验证：测试故障转移报告显示实际 RTO ≤ 文档中记录的 RTO；问题在 30 天内完成分级处理。

7. 规划故障转移 / 故障恢复流程 — 计划内故障转移（含同步），用于平稳切换； 计划外故障转移（数据丢失范围由最后一个恢复点决定），用于应对服务中断。故障恢复流程应作为测试故障转移生命周期的一部分进行测试。

防护措施

• 灾难恢复（DR）不等于备份——应将 ASR 与 Azure Backup 配合使用，以便按时间点还原并从勒索软件攻击中恢复（不可变／软删除的恢复点）。 ASR 也会复制损坏的数据；应使用不可变备份来应对勒索软件。
• 按计划测试故障转移；未经测试的灾难恢复计划只是一个假设，而非实际能力。 第一次真正故障转移时才发现从未测试过，就说明它行不通。
• 在恢复区域中考虑依赖项（身份、DNS、网络、Key Vault）。 应用故障转移正常，但无法连接域控制器或 Key Vault，服务仍然不可用。
• 配对区域很重要。 Microsoft 会协调配对区域之间的修补；非配对区域可能在同一周进行修补，导致两边都离线。
• 要有恢复计划，而不只是复制。 复制可以保留数据；恢复计划则会按正确顺序启动应用。
• 成本：ASR 按 VM 月计费，另加存储费用。 应谨慎分层——所有内容都做灾难恢复会造成浪费；什么都不做则是失职。

常见反模式

• “我们有 ASR，所以不需要备份”——ASR 会复制勒索软件加密后的内容。只有具备不可变性的备份才能用于勒索软件恢复。
• “为求稳妥，复制所有内容”——成本增加 10 倍，故障转移更慢，测试范围也更大。应按 RPO / RTO 分层。
• “从不测试故障转移——在生产环境中测试风险太大”——测试故障转移是隔离的，不会影响生产环境。真正的风险在于不测试。
• “两年前做过一次灾难恢复演练，之后再也没做”——架构已经发生变化。Tier 1 工作负载应每季度测试。
• “忘了在灾难恢复区域中部署域控制器／DNS／Key Vault”——VM 已启动，但应用无法进行身份验证或解析名称。应绘制依赖关系图。
• “所有区域共用一个全局保管库”——保管库是区域性的；如果主区域中的保管库丢失，就无法进行灾难恢复。每对区域应设置一个保管库。

示例提示词

• 使用 Azure Site Recovery 设计灾难恢复计划，并明确设定 RPO / RTO 目标。
• 如何在不影响生产环境的情况下运行测试故障转移？
• 设置区域到区域的复制，并制定按顺序启动的恢复计划。
• 将灾难恢复与 Azure Backup 一并规划，以增强勒索软件防护能力。
• 梳理故障转移到配对区域时的依赖项（身份、DNS、Key Vault）。
• 按 RPO / RTO 为工作负载分层，并确定哪些使用 ASR，哪些只需备份。

Microsoft Learn

• Site Recovery 概述：https://learn.microsoft.com/azure/site-recovery/site-recovery-overview
• Azure 到 Azure 灾难恢复：https://learn.microsoft.com/azure/site-recovery/azure-to-azure-tutorial-enable-replication
• 恢复计划：https://learn.microsoft.com/azure/site-recovery/recovery-plan-overview
• 测试故障转移：https://learn.microsoft.com/azure/site-recovery/azure-to-azure-tutorial-dr-drill
• Azure Backup 与 ASR：https://learn.microsoft.com/azure/backup/backup-overview
• 配对区域：https://learn.microsoft.com/azure/reliability/regions-paired
• Azure 到 Azure 复制架构：https://learn.microsoft.com/azure/site-recovery/azure-to-azure-architecture
• 故障转移与故障恢复：https://learn.microsoft.com/azure/site-recovery/azure-to-azure-tutorial-failover-failback