Home / Azure

AzureRunbookAdvanced

Azure Site Recovery for VM disaster recovery: design, recovery plans and failover runbook

Design region-to-region DR for Azure VMs with Site Recovery, including network mapping, recovery plans with scripts, failover, re-protect and failback, and the RPO/RTO you can realistically promise.

Deepak Bhardwaj3 min read

Applies toAzure Site Recovery (Azure-to-Azure), Recovery Services vaults

What ASR gives you

  • Continuous, crash-consistent replication of VM disks to the target region (RPO typically under a minute; app-consistent points every 1–12 hours as configured).
  • Recovery plans to fail over groups of VMs in order, with scripts and manual steps.
  • Test failover into an isolated network without affecting production.

ASR is for VMs. PaaS services (SQL Database, Storage, App Service) use their own DR features.

1. Prerequisites in the DR region

  • Recovery Services vault in the target region (not the source).
  • Target VNet with the same address space (simplest for apps with hard-coded IPs) or a different one with DNS updates.
  • A separate isolated VNet for test failovers.
  • Network security groups, route tables, firewall rules and DNS in the DR region prepared and kept in sync (IaC).
  • Target VM size quota checked in the DR region.

2. Enable replication

Portal (Site Recovery → Enable replication) or at scale with Azure Policy ("Configure disaster recovery on virtual machines by enabling replication via Azure Site Recovery"). Check:

az resource list -g rg-asr-cin --resource-type Microsoft.RecoveryServices/vaults -o table

Replication policy: recovery point retention (for example 24 hours), app-consistent snapshot frequency (for example 4 hours). Enable multi-VM consistency for VMs that must be consistent with each other (costs extra CPU; max 16 VMs per group).

3. Recovery plan

Group 1: domain controller / DNS (if any)
   └─ Manual action: confirm AD replication healthy
Group 2: database VMs
   └─ Script: start SQL services, verify databases online
Group 3: application servers
Group 4: web servers
   └─ Script: update Front Door / Traffic Manager / DNS to DR endpoints

Scripts run as Azure Automation runbooks; keep them idempotent.

4. Test failover (do this quarterly)

  1. Recovery plan → Test failover → latest processed point → isolated test VNet.
  2. Log in through Bastion in the test network; check services and data.
  3. Record the actual RTO.
  4. Cleanup test failover, with notes.

5. Real failover runbook

Step Action
1 Declare the disaster (who decides, criteria agreed in advance)
2 Recovery plan → Failover, choose recovery point (latest for lowest RPO, latest app-consistent for safety)
3 Validate application, then Commit
4 Switch DNS / Front Door / connection strings
5 Communicate to customers
6 Re-protect (replicate DR → original region) once the original region is back
7 Planned failback during a maintenance window, then re-protect again

Gotchas

  • Replication needs outbound access from source VMs to ASR endpoints (via the firewall, service tags AzureSiteRecovery, Storage.<region>, AzureActiveDirectory, EventHub).
  • Disks added after enabling replication must be added to replication.
  • Static IPs, load balancers and public IPs in the DR region need to be configured in the replicated item's Network settings.

Tip

Write the RTO from the last test into the customer's DR document, not the theoretical one. "We measured 47 minutes on 12 September" is worth more than "ASR supports RTO under 2 hours".

Related fixes