Azure Site Recovery: Disaster Recovery Orchestration for Azure Workloads
Disaster recovery is not a backup strategy — it is an orchestration challenge. Azure Site Recovery (ASR) is Microsoft's managed DR orchestration service that automates replication, failover, and failback for virtual machines and physical servers running on-premises or in Azure. For any enterprise running regulated workloads, ASR is a foundational component of the business continuity architecture.
RPO and RTO: The Two Numbers That Define Your DR Requirements
Before configuring ASR, you must have clear RPO and RTO targets from the business:
- Recovery Point Objective (RPO): The maximum acceptable data loss measured in time. An RPO of 15 minutes means no more than 15 minutes of transactions can be lost in a DR event. ASR replicates continuously with near-synchronous replication, typically achieving RPOs of 30 seconds for Azure-to-Azure scenarios
- Recovery Time Objective (RTO): The maximum time the system can be offline. ASR recovery plans can automate multi-VM failovers with scripted dependencies, targeting RTOs of minutes rather than hours for well-designed plans
Replication Architecture
ASR supports three primary replication scenarios: Azure to Azure where production VMs in one region replicate to a secondary region, VMware or Hyper-V to Azure where on-premises VMs replicate to Azure as the DR target, and physical servers to Azure. Replication is handled by the ASR Mobility Service agent on the source machine, which sends block-level changes to a cache storage account, then to replicated managed disks in the target region.
Recovery Plans and Failover
The core operational value of ASR is Recovery Plans — ordered runbooks that define the sequence of VM failovers, dependency groups, and pre/post scripts. A typical three-tier application requires a specific failover order to maintain application integrity. Recovery Plans encode this sequence and can include Azure Automation scripts for configuration changes during failover.
ASR supports both test failover — non-disruptive validation against an isolated network — and planned failover — zero-data-loss switchover during maintenance. Test failover should be scheduled quarterly at minimum for regulated workloads.
Key Architectural Decisions
- DR region pairing: Use Azure's recommended regional pairs for geo-redundancy and compliance
- Network mapping: Map source virtual networks to pre-provisioned target networks to avoid IP address conflicts at failover
- Automation integration: Connect Recovery Plans to Azure Automation for DNS updates, load balancer reconfigurations, and health checks
- Cost optimisation: Replicated VMs in the target region run as unallocated managed disks until failover — compute costs are only incurred during test failover or actual DR events
Key Takeaways
- ASR automates the replication, failover, and failback lifecycle for VMs across regions and from on-premises
- Define RPO and RTO targets before designing your ASR architecture — they drive every configuration decision
- Recovery Plans encode the multi-VM failover sequence and should include automated scripts for full application recovery
- Run quarterly test failovers to validate your recovery architecture before a real DR event occurs
