Microsoft AZ-801: Disaster Recovery and Business Continuity — Study Guide

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

Part of the Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Disaster recovery (DR) and business continuity (BC) design begins with quantifying two metrics: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). RTO represents how quickly you must restore service; RPO defines how much data loss (in time) is acceptable. These values drive technology choices, topology, and cost. Low RTO favors orchestration and automation (Azure Site Recovery recovery plans, runbooks, and pre-created target resources). Low RPO favors continuous replication (ASR) or synchronous commit (SQL Always On), while higher RPO can rely on periodic backups (Azure Backup, Windows Server Backup). Multi-VM consistency groups and application-consistent snapshots preserve cross-VM transaction integrity when strict RPO is required. Vault choice (Recovery Services vault vs Backup vault), replication policy design, and backup scheduling are all selected to meet these objectives without overspending.

Azure Site Recovery: Hyper-V, VMware, orchestration, and consistency

Azure Site Recovery (ASR) provides continuous replication and orchestrated failover/failback for on-premises VMware, Hyper-V, and Azure IaaS VMs.

Hyper-V protection

Replication policy: Defines RPO threshold, recovery point retention, and app-consistent snapshot cadence. For example, set the RPO threshold to 15 minutes, keep recovery points for 24–72 hours for point-in-time rollback, and take application-consistent snapshots every 1–4 hours. Policies control bandwidth throttling and compression; multi-VM consistency can be enabled for related VMs so their recovery points align.
Recovery points: ASR maintains crash-consistent points continuously and additional application-consistent points when VSS quiescing succeeds. Retention allows you to select earlier points to mitigate logical corruption or ransomware.
Test failover: Non-disruptive drills validate runbooks, boot ordering, and networking. Use an isolated VNet, provide test input values (e.g., DNS IPs), and ensure name resolution is isolated. Production replication continues unaffected, and cleanup removes test artifacts after validation. Establish network mapping and test NIC mappings beforehand to avoid IP conflicts.

VMware protection

Configuration server: The on-premises appliance that registers with the Recovery Services vault, discovers vCenter/ESXi inventory, coordinates replication, and pushes Mobility Service agents. It is the control plane for VMware protection.
Process server: Usually co-located with the configuration server initially; it performs change tracking, compression, encryption, and data transfer to Azure. Scale-out process servers are added for throughput and to position ingress near protected hosts to minimize latency.
Master target server: Used for failback from Azure to VMware. It receives replicated changes during re-protect and provides a landing zone so you can restore workloads back to vSphere. Size storage for aggregate write rate during failback, and ensure network throughput matches peak re-sync windows.
Mobility Service: Installed in each protected VM to capture disk changes. Keep credentials or push mechanisms updated, and monitor agent health in the vault.

Orchestration and consistency

Recovery plans: Declarative runbooks for DR that define groupings, boot order, manual approval steps, and automation tasks. Use Azure Automation runbooks to reconfigure NSGs, update DNS records, warm application caches, or run SQL scripts. Assign logical groups such as “Data,” “App,” and “Web” tiers, and insert pauses for validation.
Runbooks: Automate environment-specific tasks like flipping traffic manager endpoints, scaling PaaS dependencies, or disabling on-premises monitoring during failover to reduce false alerts. Parameterize them for test vs production failover.
Multi-VM consistency groups: Enable for tiers that share the same write order (e.g., app server and database log writer). This ensures a consistent point-in-time across VMs; it trades throughput for correctness and should be limited to truly interdependent VMs.

RTO/RPO impact

Tight RPO: Prefer ASR with aggressive replication and app-consistent snapshots, process servers sized for throughput, and dedicated replication networks. For databases, consider Always On synchronous commit within a metro area.
Tight RTO: Pre-create target VNets, subnets, and load balancers; use recovery plans with automation to eliminate manual steps. Use test failovers regularly to baseline expected RTO.

Backup and restore: Azure Backup (MARS, MABS/DPM), vaults, and Windows Server Backup

Azure Backup provides point-in-time protection across on-premises and Azure workloads. Choose the correct agent and vault type based on workload and features.

MARS agent (Microsoft Azure Recovery Services agent)

Backup policy: Configure up to three daily backups with granular retention (daily/weekly/monthly/yearly) in the Recovery Services vault. Select storage redundancy (LRS or GRS), and align retention to compliance while controlling vault growth. Schedule outside of peak I/O, and enable network throttling where needed.
System State backup: Supported with MARS for Windows Server to protect AD, registry, COM+, and boot files. Use for domain controller recovery (authoritative/non-authoritative) or OS repair without full image-level backup.
Online recovery: Restore files/folders using Browse or Search. Instant Restore mounts the recovery point as a volume for rapid file copy. You can restore to original or alternate paths and even to another server by using vault credentials on the target and authenticating to the vault.
Passphrase management: The MARS agent uses a customer-held encryption passphrase (AES-256) generated and stored locally; Microsoft never has it. Loss of the passphrase makes recovery impossible. Store it in a secure, backed-up location (e.g., sealed HSM-backed Key Vault secret with RBAC). To rotate, stop protection and reprotect with a new passphrase. Enable soft delete and security PIN features in the vault to protect against malicious stop/delete.

Azure Backup with MABS/DPM and IaaS

Bare Metal Recovery (BMR) backup: Use Microsoft Azure Backup Server (MABS) or System Center DPM to capture BMR for Windows Server. This enables full server rebuilds onto new hardware or a VM by booting WinRE or install media and pointing to the BMR image.
Recovery to alternate location: For file/data backups via MARS/MABS/DPM, restore to an alternate path or a different server to avoid overwriting source data. For Azure IaaS VM backups (in a Recovery Services vault), restore to a new VM, restore disks to an existing VM, or replace disks. With Cross-Region Restore enabled on the vault, you can restore in the paired region for regional outage scenarios.
SQL and SAP HANA in Azure VMs: Protect with workload-aware extensions to achieve application-consistent backups and granular database restore. Align log backup frequency to RPO (e.g., 15 minutes) and retention to compliance needs.

Windows Server Backup (WSB)

Bare metal recovery: WSB can capture BMR (system volumes and System State). Store to dedicated disk or volume for multiple recovery points. For network share targets, only the latest version is maintained. Recover by booting from Windows media into WinRE, selecting “System Image Recovery.”
System State backup: Provides quick recovery of AD DS, registry, and boot files. Useful for domain controllers and configuration servers. Combine with scheduled file backups for broader coverage.
Scheduling: Use the WSB MMC or wbadmin to schedule daily/hourly backups. Choose VSS Full vs Copy depending on whether you want to truncate application logs. Ensure backup windows avoid peak I/O and verify catalog integrity (wbadmin get versions).

Vault types: Recovery Services vault vs Backup vault

Recovery Services vault (RSV): The traditional vault for Azure VM backups, MARS agent backups, MABS/DPM, Azure Files backup, SQL Server in Azure VM, and SAP HANA in Azure VM. It also hosts ASR metadata. It supports features such as soft delete, security PIN, and Cross-Region Restore (where applicable).
Backup vault: The modernized vault for certain Azure-native workloads such as Azure Disks backup and Azure Blobs backup, and Azure Database for PostgreSQL flexible servers. It uses Azure RBAC for management-plane authorization, supports customer-managed keys, immutability options, and integrates with Resource Guard for critical operation protection. It does not host ASR metadata and, as of today, does not replace RSV for MARS/MABS/DPM or most IaaS VM backups.

Application-level HA: SQL Always On and DFS Replication

Some workloads demand native replication that complements or replaces hypervisor-level DR depending on RTO/RPO.

Always On Availability Groups (AGs)

Synchronous vs asynchronous commit: Synchronous commit waits for the secondary to harden the log before committing the transaction on the primary, providing near-zero data loss (low RPO) at the cost of latency and throughput; use within low-latency links (typically metro). Asynchronous commit does not wait for the secondary, enabling higher performance over WAN links with potential data loss during failover (higher RPO).
Automatic failover conditions: Automatic failover requires at least two synchronous-commit replicas with automatic failover enabled and synchronized. Windows Server Failover Clustering monitors node/service health; SQL Server’s flexible failover policy defines failure condition levels (from process crashes to severe I/O issues). Database health detection can be enabled to force failover when the primary database is suspect. Quorum and witness design ensure that split-brain is prevented; ensure DNS and listener IPs are ready in the recovery site for fast client reconnection.

DFS Replication (DFSR)

Replication groups and connections: A replication group is a set of servers replicating one or more replicated folders. Connections define the topology (full mesh, hub-spoke) and schedule/bandwidth throttling. Use hub-spoke for scale and easier troubleshooting.
Staging area: DFSR uses a per-replicated-folder staging area to hold delta files for Remote Differential Compression (RDC). Size staging to at least the size of your largest file and typically 1–2× expected daily churn; undersizing causes excessive cleanup and retries, harming RPO/RTO.
Conflict resolution: DFSR is multi-master. When simultaneous edits occur, DFSR employs version vectors and timestamps; last-writer wins and the losing copy is moved to the ConflictAndDeleted folder (space governed by quota). To avoid initial conflicts during seeding, set a primary member only for initial sync. For one-way scenarios, use read-only replicated folders. Monitor backlogs with dfsrdiag and tune schedules to meet RPO.

Architecture impact of RTO/RPO and integrated DR plans

Aggressive RPO: Favor synchronous database replication or ASR with high-frequency change processing and app-consistent snapshots. Isolate replication traffic and scale process servers. Use multi-VM consistency groups sparingly for only tightly coupled tiers.
Aggressive RTO: Pre-provision target VNets, subnets, Route Tables, and NSGs; script IP reassignments and DNS updates via recovery plans and runbooks. Keep golden images and VM sizes pinned to capacity-available SKUs. Test failovers quarterly and after material changes.
Data protection layering: Combine ASR (rapid service recovery) with Azure Backup (point-in-time rollback) to address both catastrophic failures and logical corruption. For domain controllers, pair System State backups (MARS or WSB) with ASR/test failovers to validate USN rollback-safe recovery. For file services, DFSR provides intra-site/intersite high availability, with Azure Backup for ransomware-resistant recovery.

Practical Problem Scenario

Fabrikam, Inc., a global manufacturer, operates a mixed environment: Hyper-V for ERP app tiers, VMware for legacy middleware, SQL Server 2019 AGs for databases, and large Windows file servers using DFS Replication. Business mandates RTO ≤ 1 hour and RPO ≤ 15 minutes for ERP; other workloads can tolerate RTO 4 hours, RPO 24 hours.

Classify workloads and RTO/RPO targets

ERP app/web VMs and SQL AGs flagged as Tier 1 (RTO 1h, RPO 15m). Middleware and file services are Tier 2/3.
Why: Ensures the most stringent objectives drive replication and orchestration choices.

Implement ASR for Hyper-V ERP tiers

Install ASR Provider on Hyper-V hosts and register with a Recovery Services vault. Create a replication policy with 15-minute RPO threshold, app-consistent snapshots every hour, and 48-hour retention. Enable a multi-VM consistency group across ERP app servers that share transactions with the SQL listener.
Why: Continuous replication and app-consistent checkpoints achieve the 15-minute RPO while keeping the tier consistent.

Implement ASR for VMware middleware

Deploy a configuration server on-premises, with a co-located process server sized for projected churn. Add a scale-out process server in the largest site. Install Mobility Service to protected VMs. Prepare a master target server for eventual failback.
Why: The ASR VMware architecture provides reliable change capture and a controlled path for failback when the on-premises site recovers.

Orchestrate with recovery plans and runbooks

Build a recovery plan grouping SQL (data), then ERP app, then web tiers. Insert Azure Automation runbooks to: reconfigure NSGs, update private DNS zones to point to Azure IPs, and switch Traffic Manager endpoints. Add a manual validation step before bringing web online.
Why: Automation compresses RTO and reduces human error during a crisis, enforcing correct boot order and network state.

Protect SQL Server with AGs tuned per site

Keep primary and one secondary in synchronous commit within the metro region for near-zero RPO; keep a distant DR secondary in asynchronous commit. Configure automatic failover between the synchronous replicas with database health detection enabled. Integrate AG failover steps into the ASR recovery plan for cross-visibility.
Why: Synchronous AGs deliver the lowest RPO for the database tier; ASR provides site orchestration around it.

Layer backups with Azure Backup

For on-premises Windows servers requiring file and System State protection, deploy the MARS agent and configure policies with daily backups and 30/52/7 retention (daily/weekly/yearly). Store and protect the encryption passphrase in Azure Key Vault (HSM-backed). Use MABS to capture BMR images for critical app servers to enable full rebuild if needed. Enable soft delete and security PIN on the vault.
Why: Point-in-time recovery protects against logical corruption and ransomware, complementing ASR’s fast failover.

Harden DFSR and backup file services

Review replication group topology (hub-spoke), ensure staging areas sized to 1.5× daily churn, and adjust schedules to maintain near-real-time replication intra-region. Protect shares with MARS/MABS for long-term retention and alternate location recovery tests.
Why: Proper DFSR tuning meets day-to-day availability, while backups provide roll-back safety.

Validate with test failovers and documented runbooks

Execute quarterly ASR test failovers into an isolated VNet, validate ERP functionality against masked data, and measure RTO. Perform restore drills: MARS alternate location restores and a full BMR recovery from MABS to a sandbox.
Why: Regular exercises prove the plan, surface drift, and provide executive evidence of compliance with RTO/RPO.

This design meets Fabrikam’s objectives: ASR delivers sub-hour RTO, SQL AGs in synchronous mode minimize RPO for databases, and Azure Backup with MARS/MABS provides secure point-in-time recovery and full-machine rebuild capability. Recovery plans and runbooks remove ambiguity during incidents, and DFSR remains optimized for operational continuity between backups.

← Hyper-V · All domains · Identity and Access Management for Hybrid Environments →

Practice these questions → · Timed practice on ExamRoll.io →