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 復原計畫、Runbook 和預先建立的目標資源)。低的 RPO 偏好使用持續複寫 (ASR) 或同步認可 (SQL Always On)，而較高的 RPO 則可依賴定期備份 (Azure Backup, Windows Server Backup)。當需要嚴格的 RPO 時，多重 VM 一致性群組和應用程式一致性快照可維護跨 VM 的交易完整性。保存庫的選擇 (Recovery Services vault vs Backup vault)、複寫原則的設計以及備份排程，都是為了在不超支的情況下達成這些目標而選定的。

Azure Site Recovery：Hyper-V、VMware、協調流程與一致性

Azure Site Recovery (ASR) 為地端的 VMware、Hyper-V 和 Azure IaaS VM 提供持續複寫以及協調的容錯移轉/容錯回復。

Hyper-V 保護

複寫原則：定義 RPO 閾值、復原點保留期和應用程式一致性快照的頻率。例如，將 RPO 閾值設為 15 分鐘，保留 24–72 小時的復原點以供時間點復原，並每 1–4 小時擷取一次應用程式一致性快照。原則可控制頻寬節流和壓縮；可為相關的 VM 啟用多重 VM 一致性，使其復原點保持一致。
復原點：ASR 會持續維護損毀一致性點，並在 VSS 靜止成功時，額外產生應用程式一致性點。保留期讓您能夠選擇較早的時間點，以減輕邏輯損毀或勒索軟體的影響。
測試容錯移轉：非干擾性的演練可驗證 Runbook、開機順序和網路設定。使用隔離的 VNet，提供測試輸入值 (例如 DNS IP)，並確保名稱解析是隔離的。生產環境的複寫不受影響，驗證後會透過清理程序移除測試產物。預先建立網路對應並測試 NIC 對應，以避免 IP 衝突。

VMware 保護

組態伺服器：在地端的設備，它會向 Recovery Services vault 註冊、探索 vCenter/ESXi 清查、協調複寫，並推送 Mobility Service 代理程式。它是 VMware 保護的控制平面。
程序伺服器：初期通常與組態伺服器共置；它執行變更追蹤、壓縮、加密以及將資料傳輸到 Azure。可新增向外擴充的程序伺服器以提高輸送量，並將輸入流量的接收點置於受保護主機附近，以最小化延遲。
主要目標伺服器：用於從 Azure 容錯回復至 VMware。它在重新保護期間接收複寫的變更，並提供一個登陸區域，讓您可以將工作負載還原回 vSphere。為容錯回復期間的彙總寫入速率規劃儲存空間大小，並確保網路輸送量能應付重新同步的尖峰時段。
Mobility Service：安裝在每個受保護的 VM 中，以擷取磁碟變更。保持認證或推送機制的更新，並在保存庫中監控代理程式的健康狀況。

協調流程與一致性

復原計畫：用於 DR 的宣告式 Runbook，可定義群組、開機順序、手動核准步驟和自動化任務。使用 Azure Automation Runbook 來重新設定 NSG、更新 DNS 記錄、暖化應用程式快取或執行 SQL 指令碼。指派如「資料」、「應用程式」和「Web」層等邏輯群組，並插入暫停以進行驗證。
Runbook：自動化執行特定於環境的任務，例如切換流量管理員端點、擴展 PaaS 相依性，或在容錯移轉期間停用地端監控以減少誤報。將其參數化，以適用於測試與生產環境的容錯移轉。
多重 VM 一致性群組：為共享相同寫入順序的層啟用 (例如，應用程式伺服器和資料庫日誌寫入器)。這能確保跨 VM 的時間點一致性；它以輸送量換取正確性，應僅限於真正相互依存的 VM 使用。

RTO/RPO 的影響

嚴格的 RPO：偏好使用 ASR 搭配積極的複寫和應用程式一致性快照、為高輸送量而規劃大小的程序伺服器，以及專用的複寫網路。對於資料庫，可考慮在都會區內使用 Always On 同步認可。
嚴格的 RTO：預先建立目標 VNet、子網路和負載平衡器；使用帶有自動化的復原計畫來消除手動步驟。定期使用測試容錯移轉來建立預期 RTO 的基準。

備份與還原：Azure Backup (MARS, MABS/DPM)、保存庫及 Windows Server Backup

Azure Backup 為地端與 Azure 工作負載提供特定時間點的保護。請根據工作負載和功能選擇正確的代理程式與保存庫類型。

MARS 代理程式 (Microsoft Azure Recovery Services agent)

備份原則：在 Recovery Services 保存庫中設定每日最多三次的備份，並搭配細微的保留原則 (每日/每週/每月/每年)。選擇儲存體備援 (LRS 或 GRS)，並將保留原則與合規性要求對齊，同時控制保存庫的成長。排程應避開 I/O 尖峰時段，並在需要時啟用網路節流。
System State 備份：MARS 支援 Windows Server 的 System State 備份，以保護 AD、登錄檔、COM+ 及開機檔案。可用於網域控制站的復原 (授權/非授權) 或在沒有完整映像層級備份的情況下修復作業系統。
線上復原：使用「瀏覽」或「搜尋」來還原檔案/資料夾。Instant Restore 會將復原點掛載為磁碟區，以利快速複製檔案。您可以還原到原始路徑或替代路徑，甚至可以透過在目標伺服器上使用保存庫認證並向保存庫進行驗證，來還原到另一台伺服器。
複雜密碼管理：MARS 代理程式使用客戶持有的加密複雜密碼 (AES-256)，該密碼在本地產生並儲存；Microsoft 絕不會持有它。遺失複雜密碼將導致無法復原。請將其儲存在安全且有備份的位置 (例如，以 RBAC 保護且由 HSM 支援的 Key Vault 中密封的祕密)。若要輪替密碼，請停止保護，然後使用新的複雜密碼重新進行保護。在保存庫中啟用虛刪除和安全性 PIN 功能，以防止惡意的停止/刪除操作。

Azure Backup 搭配 MABS/DPM 與 IaaS

Bare Metal Recovery (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 或取代磁碟。在保存庫上啟用 Cross-Region Restore 後，您可以在配對的區域中進行還原，以應對區域性中斷情境。
Azure VM 中的 SQL 與 SAP HANA：使用感知工作負載的擴充功能進行保護，以實現應用程式一致性備份和細微的資料庫還原。將記錄備份頻率與 RPO (例如 15 分鐘) 對齊，並將保留原則與合規性需求對齊。

Windows Server Backup (WSB)

裸機復原：WSB 可以擷取 BMR (系統磁碟區和 System State)。儲存到專用磁碟或磁碟區可保留多個復原點。對於網路共用目標，只會保留最新版本。復原時，需從 Windows 安裝媒體開機進入 WinRE，並選擇「系統映像修復」。
System State 備份：提供 AD DS、登錄檔和開機檔案的快速復原。對於網域控制站和組態伺服器很有用。可與排程的檔案備份結合，以獲得更廣泛的涵蓋範圍。
排程：使用 WSB MMC 或 wbadmin 來排程每日/每小時的備份。根據您是否要截斷應用程式記錄，選擇 VSS Full 或 VSS Copy。確保備份時段避開 I/O 尖峰，並驗證目錄完整性 (wbadmin get versions)。

保存庫類型：Recovery Services vault vs Backup vault

Recovery Services vault (RSV)：傳統的保存庫，用於 Azure VM 備份、MARS 代理程式備份、MABS/DPM、Azure Files 備份、Azure VM 中的 SQL Server 以及 Azure VM 中的 SAP HANA。它也託管 ASR 的中繼資料。它支援虛刪除、安全性 PIN 和跨區域還原 (如適用) 等功能。
Backup vault：現代化的保存庫，用於特定的 Azure 原生工作負載，例如 Azure Disks 備份、Azure Blobs 備份以及 Azure Database for PostgreSQL 彈性伺服器。它使用 Azure RBAC 進行管理平面的授權，支援客戶管理的金鑰、不可變性選項，並與 Resource Guard 整合以提供關鍵作業的保護。它不託管 ASR 的中繼資料，且截至今日，它尚未取代 RSV 用於 MARS/MABS/DPM 或大多數 IaaS VM 的備份。

應用程式層級 HA：SQL Always On 與 DFS 複寫

有些工作負載需要原生的複寫機制，以根據 RTO/RPO 來補充或取代 hypervisor 層級的災難復原 (DR)。

Always On 可用性群組 (AG)

同步與非同步認可：同步認可 (Synchronous commit) 會等待次要複本強化日誌後，才在主要複本上認可交易，以延遲和輸送量的代價提供近乎零的資料遺失 (低 RPO)；適用於低延遲連結 (通常是都會區網路)。非同步認可 (Asynchronous commit) 不會等待次要複本，因此能在 WAN 連結上實現更高的效能，但在容錯移轉期間可能會有資料遺失 (較高 RPO)。
自動容錯移轉條件：自動容錯移轉需要至少兩個啟用自動容錯移轉且已同步的同步認可複本。Windows Server 容錯移轉叢集會監控節點/服務的健康狀況；SQL Server 的彈性容錯移轉原則定義了失敗條件的層級 (從處理程序崩潰到嚴重的 I/O 問題)。可以啟用資料庫健康狀態偵測，以便在主要資料庫可疑時強制進行容錯移轉。仲裁 (Quorum) 和見證 (witness) 的設計可確保防止腦裂 (split-brain)；請確保復原站點的 DNS 和接聽程式 IP 已準備就緒，以便用戶端快速重新連線。

DFS 複寫 (DFSR)

複寫群組與連線：複寫群組是一組伺服器，用於複寫一個或多個複寫資料夾。連線定義了拓撲 (完整網狀、中樞輪輻式) 以及排程/頻寬節流。使用中樞輪輻式 (hub-spoke) 以利於擴展和簡化疑難排解。
臨時區域：DFSR 為每個複寫資料夾使用一個臨時區域 (staging area)，以存放用於遠端差異壓縮 (Remote Differential Compression, RDC) 的差異檔案。臨時區域的大小至少要設定為最大檔案的大小，通常是預期每日變動量的 1-2 倍；空間過小會導致過多的清理和重試，從而損害 RPO/RTO。
衝突解決：DFSR 是多主機 (multi-master) 架構。當同時發生編輯時，DFSR 會採用版本向量和時間戳記；最後寫入者獲勝，而失敗的複本會被移至 ConflictAndDeleted 資料夾 (其空間受配額管理)。為避免植入 (seeding) 期間的初始衝突，請僅為初始同步設定一個主要成員。對於單向複寫的情境，請使用唯讀複寫資料夾。使用 dfsrdiag 監控待辦項目 (backlogs)，並調整排程以滿足 RPO。

RTO/RPO 與整合式 DR 計畫對架構的影響

嚴格的 RPO：優先採用同步資料庫複寫或 ASR，搭配高頻率的變更處理與應用程式一致性快照。隔離複寫流量並擴展處理伺服器。僅對緊密耦合的層級謹慎使用多 VM 一致性群組。
嚴格的 RTO：預先佈建目標 VNet、子網路、路由表與 NSG；透過復原計畫與 runbook，以指令碼處理 IP 重新指派與 DNS 更新。將黃金映像檔與 VM 大小鎖定在有可用容量的 SKU。每季及在重大變更後測試容錯移轉。
資料保護分層：結合 ASR (快速服務復原) 與 Azure Backup (時間點復原)，以應對災難性故障與邏輯毀損。對於網域控制站，將系統狀態備份 (MARS 或 WSB) 與 ASR/測試容錯移轉配對，以驗證 USN 回復安全的復原。對於檔案服務，DFSR 提供站內/站間高可用性，並搭配 Azure Backup 進行抗勒索軟體攻擊的復原。

實務問題情境

全球製造商 Fabrikam, Inc. 營運一個混合式環境：用於 ERP 應用程式層級的 Hyper-V、用於舊版中介軟體的 VMware、用於資料庫的 SQL Server 2019 AG，以及使用 DFS Replication 的大型 Windows 檔案伺服器。業務要求 ERP 的 RTO ≤ 1 小時，RPO ≤ 15 分鐘；其他工作負載可容忍 RTO 4 小時，RPO 24 小時。

分類工作負載與 RTO/RPO 目標

ERP 應用程式/Web VM 與 SQL AG 被標記為 Tier 1 (RTO 1h, RPO 15m)。中介軟體與檔案服務為 Tier 2/3。
原因：確保最嚴格的目標能驅動複寫與協調流程的選擇。

為 Hyper-V ERP 層級實作 ASR

在 Hyper-V 主機上安裝 ASR Provider，並註冊到一個 Recovery Services vault。建立一個複寫原則，設定 15 分鐘的 RPO 閾值、每小時一次的應用程式一致性快照，以及 48 小時的保留期。在與 SQL 接聽程式共用交易的 ERP 應用程式伺服器之間，啟用一個多 VM 一致性群組。
原因：持續複寫與應用程式一致性檢查點可在維持層級一致性的同時，達成 15 分鐘的 RPO。

為 VMware 中介軟體實作 ASR

在地端部署一台組態伺服器，並搭配一台根據預估變動量調整大小的共置處理伺服器。在最大的站點新增一台向外擴展的處理伺服器。將 Mobility Service 安裝到受保護的 VM。準備一台主要目標伺服器以供最終的容錯回復。
原因：ASR VMware 架構提供可靠的變更擷取，並在地端站點復原時提供一條受控的容錯回復路徑。

使用復原計畫與 runbook 進行協調

建立一個復原計畫，依序將 SQL (資料)、ERP 應用程式、然後是 Web 層級分組。插入 Azure Automation runbook 來：重新設定 NSG、更新私有 DNS 區域以指向 Azure IP，以及切換 Traffic Manager 端點。在 Web 上線前，新增一個手動驗證步驟。
原因：自動化可在危機期間縮短 RTO 並減少人為錯誤，強制執行正確的開機順序與網路狀態。

使用依站點調整的 AG 保護 SQL Server

在都會區內，將主要複本與一個次要複本保持在同步認可模式，以達到近乎零的 RPO；將一個遠端的 DR 次要複本保持在非同步認可模式。在同步複本之間設定自動容錯移轉，並啟用資料庫健康狀態偵測。將 AG 容錯移轉步驟整合到 ASR 復原計畫中，以獲得跨平台的能見度。
原因：同步 AG 為資料庫層級提供最低的 RPO；ASR 則在其周圍提供站點協調。

使用 Azure Backup 進行分層備份

對於需要檔案與系統狀態保護的地端 Windows 伺服器，部署 MARS 代理程式並設定原則，包含每日備份與 30/52/7 (日/週/年) 的保留期。將加密複雜密碼儲存並保護在 Azure Key Vault (由 HSM 支援) 中。使用 MABS 為關鍵應用程式伺服器擷取 BMR 映像，以便在需要時能夠完全重建。在 vault 上啟用虛刪除與安全性 PIN 碼。
原因：時間點復原可防禦邏輯毀損與勒索軟體，補充了 ASR 的快速容錯移轉功能。

強化 DFSR 與備份檔案服務

檢視複寫群組拓撲 (中樞-輪輻)，確保暫存區大小為每日變動量的 1.5 倍，並調整排程以維持區域內的近乎即時複寫。使用 MARS/MABS 保護共用資料夾，以進行長期保留與替代位置復原測試。
原因：適當的 DFSR 調校可滿足日常可用性，而備份則提供回復的安全性。

透過測試容錯移轉與文件化的 runbook 進行驗證

每季執行 ASR 測試容錯移轉至一個隔離的 VNet，針對遮罩後的資料驗證 ERP 功能，並測量 RTO。執行還原演練：MARS 替代位置還原，以及從 MABS 到沙箱環境的完整 BMR 復原。
原因：定期演練可證明計畫有效、揭露設定偏移，並向管理層提供符合 RTO/RPO 的證據。

此設計滿足 Fabrikam 的目標：ASR 提供低於一小時的 RTO，同步模式的 SQL AG 將資料庫的 RPO 降至最低，而 Azure Backup 搭配 MARS/MABS 則提供安全的時間點復原與全機重建能力。復原計畫與 runbook 消除了事件期間的模糊性，而 DFSR 則持續為備份之間的營運連續性進行最佳化。

← Hyper-V、虛擬化與儲存 · 所有領域 · 混合式環境的身分識別與存取管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →