D3 · Business Continuity

Disaster Recovery

DR addresses the loss of an entire region or site. The AZ-305 tests when to use Azure Site Recovery (VM replication), when geo-redundant backup is enough, and how DR is designed for PaaS services — which do NOT use ASR.

Contents

Azure Site Recovery — what it replicates
Scenarios: Azure-Azure, VMware, Hyper-V
Recovery plans and failover tests
DR for PaaS (not ASR)
Strategy: backup vs ASR vs active-active
Decision table

Azure Site Recovery — what it does

ASR continuously replicates VMs to another region (or from on-premises to Azure) and orchestrates failover. Unlike backup (discrete points, RPO of hours), ASR keeps an almost-current replica: typical RPO of ~minutes (continuous replication for Azure VMs), typical RTO of minutes.

Backup ≠ DR: backup protects DATA against corruption/deletion with historical retention; ASR protects workload AVAILABILITY with a current replica. A complete strategy usually includes both.

Key concepts

• Crash-consistent points (frequent) vs app-consistent (VSS, configurable every few hours)
• Failover: choose the recovery point; failback = re-protect in reverse and return
• Target resources (VNet, IPs, sizes) are mapped ahead of time
• Cost: ASR license per instance + replica storage + compute ONLY during failover

Limits to remember

• ASR is for VMs (IaaS) — it doesn't replicate PaaS
• Databases on VMs: native replication (Always On) is better for a lower RPO; ASR as a general layer
• Testing with test failover does NOT affect production (isolated network)

Supported scenarios

Source → Target	Components	Use
Azure VM → another region	Just enable replication (extension agent)	Regional DR for IaaS — the most common scenario
Azure VM → zone (zone-to-zone)	Same, within the region	Zonal DR when data can't leave the region
VMware → Azure	ASR replication appliance on-prem	DR of a VMware datacenter to Azure (and migrations)
Hyper-V → Azure	Provider on the Hyper-V host (+ optional VMM)	DR from Hyper-V to Azure
Physical → Azure	Appliance (VMware-like process)	Physical servers to Azure

Recovery plans and tests

Recovery plans

• Orchestrate the failover of a group of VMs in a defined order (DB first, then app, then web)
• Sequential groups + manual actions + Automation runbooks (reconfigure DNS, IPs, load balancers)
• One click to fail over the entire application

Test failover (DR drill)

• Spins up the replicas on an isolated network without touching production or replication
• Typical requirement: "test the DR plan quarterly with no impact" → test failover
• Validate real RTO by measuring the drill

DR for PaaS — each service brings its own

Service	DR mechanism
SQL Database / MI	Failover groups (endpoint that doesn't change) / active geo-replication
Cosmos DB	Multi-region replicas + service-managed failover (or multi-write)
Storage	GRS/GZRS + customer-initiated failover (RA-* for reading without failover)
App Service	Deploy in 2 regions + Front Door (no native replica)
AKS	Clusters in 2 regions + GitOps/IaC + geo-replicated registry (ACR Premium)
Key Vault	Automatic replication to the paired region (managed by Microsoft)
Event Hubs / Service Bus	Geo-disaster recovery (namespace alias; replicates METADATA, not messages) / geo-replication (Premium)

Exam trap

If the question asks for DR of App Service or SQL Database and an option says "Azure Site Recovery" — it's wrong. ASR only replicates VMs. PaaS uses its own native mechanisms + IaC to recreate the application layer.

Strategy: choosing by RTO/RPO and cost

🛡️Árbol de decisión — Estrategia de DR

Backup+IaC · ASR · Hot Standby · Activo-Activo

Interactivo

Pregunta 1

¿El workload que proteger es IaaS (VMs) o PaaS (SQL DB, App Service, AKS, Cosmos)?

💡 IaaS usa Azure Site Recovery (ASR) para replicar VMs. PaaS usa sus mecanismos nativos — ASR no replica servicios PaaS. Esta es la trampa más común del examen.

Strategy	Typical RTO / RPO	Cost
GRS backup + redeploy with IaC	RTO hours / RPO hours-days	$
ASR (warm standby of VMs)	RTO minutes / RPO minutes	$$
Hot standby (deployed infra + native data replication)	RTO minutes / RPO seconds-minutes	$$$
Active-active multi-region	RTO ≈ 0 / RPO ≈ 0	$$$$

Decision table

Requirement	Design
VMs with RTO/RPO of minutes in another region	Azure Site Recovery
Data can't leave the region but VM DR is required	ASR zone-to-zone
Ordered failover: DB → app → web with scripts	Recovery plan + Automation runbooks
Test DR without affecting production	Test failover on an isolated network
DR for SQL Database with a stable connection string	Failover group (not ASR)
Multi-region DR for App Service	2 deployments + Front Door (not ASR)
Hours-long RTO acceptable, minimal budget	GRS backup + CRR + IaC redeploy
Migrate VMware to Azure along the way	ASR (or Azure Migrate, which uses it under the hood)

Did you get this topic?

Test what you just learned

A 3-tier app runs on 12 Azure VMs in North Europe. DR requirements: RTO of 30 minutes, RPO of 5 minutes, orchestrated failover in order (SQL first, then app, then web) with automatic DNS reconfiguration, and quarterly drills without touching production. What do you design?

Ready to test "Disaster Recovery"?

Put what you learned to the test with original AZ-305 exam questions.

Start AZ-305 mock exam

Unlimited mock exams with the Pro plan

PreviousBackup DesignBusiness Continuity NextDatabase BCDRBusiness Continuity