Microsoft AZ-801: 灾难恢复和业务连续性 — 学习指南

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

属于 Microsoft Windows Server Hybrid Administrator Associate AZ-801 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

灾难恢复 (DR) 和业务连续性 (BC) 设计始于量化两个指标：恢复时间目标 (RTO) 和恢复点目标 (RPO)。RTO 代表您必须多快恢复服务；RPO 定义了可接受多少数据丢失（以时间衡量）。这些值决定了技术选型、拓扑和成本。低 RTO 倾向于使用业务流程和自动化（Azure Site Recovery 恢复计划、运行手册和预先创建的目标资源）。低 RPO 倾向于使用连续复制 (ASR) 或同步提交 (SQL Always On)，而较高的 RPO 则可以依赖定期备份 (Azure Backup, Windows Server Backup)。在需要严格 RPO 时，多虚拟机一致性组和应用程序一致性快照可保持跨虚拟机的事务完整性。保管库选择（Recovery Services vault 与 Backup vault）、复制策略设计和备份计划都旨在满足这些目标而不超支。

Azure Site Recovery：Hyper-V、VMware、业务流程和一致性

Azure Site Recovery (ASR) 为本地 VMware、Hyper-V 和 Azure IaaS 虚拟机提供连续复制和经过编排的故障转移/故障恢复。

Hyper-V 保护

• 复制策略：定义 RPO 阈值、恢复点保留期和应用一致性快照的频率。例如，将 RPO 阈值设置为 15 分钟，保留恢复点 24-72 小时以用于时间点回滚，并每 1-4 小时生成一次应用程序一致性快照。策略可控制带宽限制和压缩；可以为相关虚拟机启用多虚拟机一致性，以使其恢复点保持一致。
• 恢复点：ASR 持续维护崩溃一致性点，并在 VSS 静默成功时生成额外的应用程序一致性点。保留期允许您选择更早的时间点以缓解逻辑损坏或勒索软件攻击。
• 测试故障转移：无中断演练可验证运行手册、启动顺序和网络配置。使用隔离的 VNet，提供测试输入值（例如，DNS IP），并确保名称解析是隔离的。生产环境的复制不受影响，验证后清理操作会移除测试产物。预先建立网络映射并测试 NIC 映射，以避免 IP 冲突。

VMware 保护

• 配置服务器：一种本地设备，它在 Recovery Services 保管库中注册，发现 vCenter/ESXi 清单，协调复制，并推送 Mobility Service 代理。它是 VMware 保护的控制平面。
• 进程服务器：通常最初与配置服务器部署在同一位置；它执行变更跟踪、压缩、加密以及到 Azure 的数据传输。可以添加横向扩展的进程服务器以提高吞吐量，并将其部署在靠近受保护主机的入口位置以最小化延迟。
• 主目标服务器：用于从 Azure 故障恢复到 VMware。它在重新保护期间接收复制的变更，并提供一个着陆区，以便您可以将工作负载恢复到 vSphere。根据故障恢复期间的总写入速率来规划存储大小，并确保网络吞吐量能满足峰值重新同步窗口的需求。
• Mobility Service：安装在每个受保护的虚拟机中以捕获磁盘变更。保持凭据或推送机制的更新，并在保管库中监控代理的健康状况。

业务流程和一致性

• 恢复计划：用于 DR 的声明式运行手册，定义了分组、启动顺序、手动批准步骤和自动化任务。使用 Azure Automation 运行手册来重新配置 NSG、更新 DNS 记录、预热应用程序缓存或运行 SQL 脚本。分配逻辑组，如“数据”、“应用”和“Web”层，并插入暂停以进行验证。
• 运行手册：自动化特定于环境的任务，例如切换流量管理器端点、扩展 PaaS 依赖项，或在故障转移期间禁用本地监控以减少误报。为测试与生产故障转移对其进行参数化。
• 多虚拟机一致性组：为共享相同写入顺序的层（例如，应用服务器和数据库日志写入程序）启用此功能。这可以确保跨虚拟机的时间点一致性；它以吞吐量换取正确性，应仅限于真正相互依赖的虚拟机。

RTO/RPO 影响

备份和还原：Azure Backup (MARS, MABS/DPM)、保管库和 Windows Server Backup

Azure Backup 为本地和 Azure 工作负载提供时间点保护。请根据工作负载和功能选择正确的代理和保管库类型。

MARS 代理 (Microsoft Azure Recovery Services agent)

• 备份策略：在 Recovery Services 保管库中配置每天最多三次的备份，并提供精细的保留策略（每日/每周/每月/每年）。选择存储冗余（LRS 或 GRS），使保留策略符合合规性要求，同时控制保管库增长。在 I/O 高峰期之外安排计划，并在需要时启用网络限制。
• 系统状态备份：MARS 支持 Windows Server 的系统状态备份，以保护 AD、注册表、COM+ 和启动文件。用于域控制器恢复（授权性/非授权性）或操作系统修复，而无需完整的映像级备份。
• 联机恢复：使用“浏览”或“搜索”还原文件/文件夹。即时还原将恢复点装载为卷，以实现快速文件复制。您可以还原到原始路径或备用路径，甚至可以通过在目标服务器上使用保管库凭据并向保管库进行身份验证来还原到另一台服务器。
• 密码管理：MARS 代理使用客户持有的加密密码 (AES-256)，该密码在本地生成和存储；Microsoft 绝不会持有它。丢失密码将导致无法恢复。将其存储在安全的、有备份的位置（例如，使用 RBAC 保护的、由 HSM 支持的密封 Key Vault 机密）。要轮换密码，请停止保护并使用新密码重新进行保护。在保管库中启用软删除和安全 PIN 功能，以防止恶意停止/删除操作。

使用 MABS/DPM 和 IaaS 的 Azure Backup

• 裸机恢复 (BMR) 备份：使用 Microsoft Azure Backup Server (MABS) 或 System Center DPM 来捕获 Windows Server 的 BMR。通过启动 WinRE 或安装介质并指向 BMR 映像，可以实现将服务器完全重建到新硬件或 VM 上。
• 恢复到备用位置：对于通过 MARS/MABS/DPM 进行的文件/数据备份，请还原到备用路径或不同的服务器，以避免覆盖源数据。对于 Azure IaaS VM 备份（在 Recovery Services 保管库中），可以还原为新 VM、将磁盘还原到现有 VM 或替换磁盘。在保管库上启用跨区域还原后，您可以在配对区域中进行还原，以应对区域性中断场景。
• Azure VM 中的 SQL 和 SAP HANA：使用可感知工作负载的扩展进行保护，以实现应用程序一致性备份和精细的数据库还原。使日志备份频率与 RPO（例如 15 分钟）保持一致，并使保留策略符合合规性要求。

Windows Server Backup (WSB)

• 裸机恢复：WSB 可以捕获 BMR（系统卷和系统状态）。存储到专用磁盘或卷以获得多个恢复点。对于网络共享目标，仅保留最新版本。通过从 Windows 安装介质启动到 WinRE，并选择“系统映像恢复”来进行恢复。
• 系统状态备份：提供 AD DS、注册表和启动文件的快速恢复。对域控制器和配置服务器很有用。与计划的文件备份相结合以获得更广泛的覆盖。
• 计划：使用 WSB MMC 或 wbadmin 来计划每日/每小时备份。根据是否要截断应用程序日志来选择 VSS 完整备份或 VSS 副本备份。确保备份窗口避开 I/O 高峰期，并验证目录完整性 (wbadmin get versions)。

保管库类型：Recovery Services 保管库 vs 备份保管库

• Recovery Services 保管库 (RSV)：用于 Azure VM 备份、MARS 代理备份、MABS/DPM、Azure Files 备份、Azure VM 中的 SQL Server 和 Azure VM 中的 SAP HANA 的传统保管库。它还托管 ASR 元数据。它支持软删除、安全 PIN 和跨区域还原（如适用）等功能。
• 备份保管库：用于某些 Azure 原生工作负载（例如 Azure Disks 备份、Azure Blobs 备份和 Azure Database for PostgreSQL 灵活服务器）的现代化保管库。它使用 Azure RBAC 进行管理平面授权，支持客户管理的密钥、不可变性选项，并与 Resource Guard 集成以提供关键操作保护。它不托管 ASR 元数据，并且截至目前，它不能替代用于 MARS/MABS/DPM 或大多数 IaaS VM 备份的 RSV。

应用级 HA：SQL Always On 和 DFS Replication

某些工作负载需要原生复制，以根据 RTO/RPO 补充或替代 hypervisor 级 DR。

Always On Availability Groups (AGs)

• 同步提交与异步提交：同步提交会在主副本上提交事务之前，等待辅助副本固化日志，从而以延迟和吞吐量为代价，提供近乎零的数据丢失（低 RPO）；适用于低延迟链路（通常是城域网）。异步提交不等待辅助副本，可在广域网链路上实现更高性能，但在故障转移期间可能存在数据丢失（较高 RPO）。
• 自动故障转移条件：自动故障转移至少需要两个启用了自动故障转移并已同步的同步提交副本。Windows Server Failover Clustering 监控节点/服务运行状况；SQL Server 的灵活故障转移策略定义了故障条件级别（从进程崩溃到严重的 I/O 问题）。可以启用数据库运行状况检测，以便在主数据库状态可疑时强制执行故障转移。仲裁和见证设计可确保防止脑裂；确保恢复站点中的 DNS 和侦听器 IP 已就绪，以便客户端快速重新连接。

DFS Replication (DFSR)

• 复制组和连接：复制组是一组服务器，用于复制一个或多个复制文件夹。连接定义了拓扑（全网状、中心辐射型）以及计划/带宽限制。使用中心辐射型拓扑以实现扩展并简化故障排除。
• 暂存区：DFSR 为每个复制文件夹使用一个暂存区，以存放用于远程差分压缩 (Remote Differential Compression, RDC) 的增量文件。将暂存区的大小设置为至少是最大文件的大小，通常是预期每日变更量的 1-2 倍；大小设置不足会导致过多的清理和重试，从而损害 RPO/RTO。
• 冲突解决：DFSR 是多主模式。当发生同时编辑时，DFSR 采用版本向量和时间戳；最后写入者获胜，失败的副本将被移动到 ConflictAndDeleted 文件夹（空间受配额限制）。为避免在初始同步期间产生初始冲突，请仅为初始同步设置一个主成员。对于单向场景，请使用只读复制文件夹。使用 dfsrdiag 监控积压情况，并调整计划以满足 RPO。

RTO/RPO 和集成 DR 计划对架构的影响

• 严格的 RPO：倾向于使用同步数据库复制或具有高频变更处理和应用一致性快照的 ASR。隔离复制流量并扩展进程服务器。谨慎地仅将多虚拟机一致性组用于紧密耦合的层。
• 严格的 RTO：预先预配目标 VNet、子网、路由表和 NSG；通过恢复计划和 runbook 编写 IP 重新分配和 DNS 更新的脚本。将黄金映像和虚拟机大小固定到有可用容量的 SKU。每季度以及在发生重大变更后测试故障转移。
• 数据保护分层：将 ASR（快速服务恢复）与 Azure Backup（时间点回滚）相结合，以应对灾难性故障和逻辑损坏。对于域控制器，将系统状态备份（MARS 或 WSB）与 ASR/测试故障转移配对，以验证 USN 回滚安全的恢复。对于文件服务，DFSR 提供站点内/站点间高可用性，而 Azure Backup 则用于抗勒索软件的恢复。

实际问题场景

全球制造商 Fabrikam, Inc. 运营着一个混合环境：用于 ERP 应用层的 Hyper-V、用于旧式中间件的 VMware、用于数据库的 SQL Server 2019 AG，以及使用 DFS 复制的大型 Windows 文件服务器。业务要求 ERP 的 RTO ≤ 1 小时，RPO ≤ 15 分钟；其他工作负载可以容忍 RTO 4 小时，RPO 24 小时。

1. 对工作负载和 RTO/RPO 目标进行分类

• ERP 应用/Web 虚拟机和 SQL AG 被标记为 Tier 1（RTO 1 小时，RPO 15 分钟）。中间件和文件服务为 Tier 2/3。
• 原因：确保最严格的目标驱动复制和编排选择。

2. 为 Hyper-V ERP 层实施 ASR

• 在 Hyper-V 主机上安装 ASR 提供程序，并将其注册到恢复服务保管库。创建一个复制策略，设置 15 分钟的 RPO 阈值、每小时进行一次应用一致性快照，并保留 48 小时。在与 SQL 侦听器共享事务的 ERP 应用服务器之间启用一个多虚拟机一致性组。
• 原因：连续复制和应用一致性检查点可在保持层一致性的同时，实现 15 分钟的 RPO。

3. 为 VMware 中间件实施 ASR

• 在本地部署一个配置服务器，并共置一个根据预计数据变动量调整大小的进程服务器。在最大的站点中添加一个横向扩展进程服务器。向受保护的虚拟机安装移动服务。准备一个主目标服务器以备最终的故障回复。
• 原因：ASR VMware 架构为本地站点恢复时提供了可靠的变更捕获和受控的故障回复路径。

4. 使用恢复计划和 runbook 进行编排

• 构建一个恢复计划，按 SQL（数据）、ERP 应用、Web 层的顺序进行分组。插入 Azure Automation runbook 以：重新配置 NSG、更新专用 DNS 区域以指向 Azure IP，以及切换流量管理器终结点。在将 Web 上线之前添加一个手动验证步骤。
• 原因：自动化可缩短 RTO 并减少危机期间的人为错误，强制执行正确的启动顺序和网络状态。

5. 使用根据站点调整的 AG 保护 SQL Server

• 在城域内将主副本和一个辅助副本保持在同步提交模式，以实现接近于零的 RPO；将一个远程的 DR 辅助副本保持在异步提交模式。在同步副本之间配置自动故障转移，并启用数据库运行状况检测。将 AG 故障转移步骤集成到 ASR 恢复计划中，以实现跨可见性。
• 原因：同步 AG 为数据库层提供了最低的 RPO；ASR 在其周围提供站点编排。

6. 使用 Azure Backup 进行分层备份

• 对于需要文件和系统状态保护的本地 Windows 服务器，部署 MARS 代理并配置策略，包括每日备份和 30/52/7 的保留期（每日/每周/每年）。在 Azure Key Vault（HSM 支持）中存储和保护加密密码。使用 MABS 捕获关键应用服务器的 BMR 映像，以便在需要时进行完全重建。在保管库上启用软删除和安全 PIN。
• 原因：时间点恢复可防范逻辑损坏和勒索软件，补充了 ASR 的快速故障转移能力。

7. 强化 DFSR 和备份文件服务

• 审查复制组拓扑（中心辐射型），确保暂存区域的大小为每日数据变动量的 1.5 倍，并调整计划以维持区域内的近实时复制。使用 MARS/MABS 保护共享，以实现长期保留和备用位置恢复测试。
• 原因：正确的 DFSR 调优可满足日常可用性，而备份则提供回滚安全性。

8. 通过测试故障转移和文档化的 runbook 进行验证

• 每季度执行一次到隔离 VNet 的 ASR 测试故障转移，对照脱敏数据验证 ERP 功能，并测量 RTO。执行还原演练：MARS 备用位置还原和从 MABS 到沙盒的完整 BMR 恢复。
• 原因：定期演练可以证明计划的有效性，发现配置漂移，并向管理层提供符合 RTO/RPO 的证据。

此设计满足了 Fabrikam 的目标：ASR 提供了亚小时级的 RTO，同步模式下的 SQL AG 最大限度地减少了数据库的 RPO，而带有 MARS/MABS 的 Azure Backup 提供了安全的即时点恢复和整机重建能力。恢复计划和 runbook 消除了事件期间的模糊性，DFSR 保持优化以实现备份之间的操作连续性。

← Hyper-V、虚拟化和存储 · 所有领域 · 混合环境的身份和访问管理 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →