Azure Site Recovery Replication

Azure Site Recovery (ASR) is a disaster recovery service that replicates workloads from a primary location to a secondary location, enabling failover if the primary becomes unavailable. Unlike Azure Backup (which creates point-in-time recovery points), ASR maintains a continuously updated replica of your VMs so you can fail over with minimal data loss. ASR supports Azure-to-Azure replication, on-premises VMware or Hyper-V to Azure, and physical servers to Azure.

For Azure-to-Azure replication, ASR uses the Mobility Service (installed automatically as a VM extension) to capture write I/O from the source VM's disks. The captured data is transmitted over the Azure backbone to a cache storage account in the target region, then written to replica managed disks. A Recovery Services vault in the target region orchestrates the replication. The source VM continues running normally during replication — there is no performance impact for writes below the replication bandwidth.

To enable replication, navigate to the source VM in the portal, select Disaster Recovery, choose the target region, and configure the target resource group, virtual network, and cache storage account. ASR creates the target resources and begins the initial replication phase — copying the full disk contents to the target region. After initial sync completes, ASR enters delta replication mode, sending only changed blocks continuously.

The ASR dashboard in the Recovery Services vault shows the replication health of each protected VM. Possible states include Healthy, Warning, and Critical. The RPO (Recovery Point Objective) achieved metric shows how far behind the replica is from the source — for Azure-to-Azure replication, ASR typically achieves RPO under 1 minute under normal conditions. You can also view replication bandwidth consumption and any error conditions.

A replication policy defines the crash-consistent recovery point frequency (every 5 minutes by default) and the app-consistent recovery point frequency (every 60 minutes by default). Crash-consistent recovery points are taken without quiescing the application; app-consistent recovery points use VSS/scripts to ensure the application can recover cleanly. The policy also sets how long recovery points are retained — from 0 to 72 hours for crash-consistent and 0 to 48 hours for app-consistent.

During replication setup, ASR creates or maps target region resources: a target resource group, a target virtual network, a cache storage account, and replica managed disks. You can customise the target network mapping to place the failover VMs into specific subnets, assign static private IPs, and configure target VM sizes (which can differ from the source size — useful for right-sizing during DR). These settings are stored in the Compute and Network configuration of the protected item.

For applications that span multiple VMs (e.g. a web server and a database server), you can group them into a multi-VM consistency group. ASR then coordinates crash-consistent and app-consistent recovery points across all VMs in the group simultaneously. This ensures that when you fail over, all VMs are restored to the same point in time — preventing data inconsistency between the application tier and the database tier that would cause application errors after failover.

Network mapping defines which target virtual network each source VNet maps to when VMs are failed over. If your source VM is in a VNet named prod-vnet in East US, you configure a network mapping so that on failover, the VM is placed in dr-vnet in West US. Without a network mapping, failed-over VMs are placed in the first available VNet, which may cause connectivity issues if the VNet topology differs from the source region.

ASR replication uses the Azure backbone for Azure-to-Azure scenarios — you do not pay for egress bandwidth between paired Azure regions for replication traffic. However, the delta replication rate must not exceed the available upload bandwidth of the source VM's storage. For high-write workloads (like large SQL Server databases with heavy write traffic), use the ASR Deployment Planner tool to estimate the required bandwidth and verify your environment is compatible before enabling replication.

ASR supports replication of both managed and unmanaged (blob-based) disks, but managed disk replication is strongly preferred because it eliminates storage account management and provides better performance. When replicating VMs with managed disks, ASR creates corresponding managed replica disks in the target region. You can also exclude specific data disks from replication (e.g. temporary or scratch disks) to reduce replication bandwidth and cost.

ASR and Azure Backup are complementary, not alternatives. Azure Backup protects against data corruption, accidental deletion, and ransomware — you restore to a known good state from days or weeks ago. ASR protects against regional outages — you fail over to a replica that is seconds to minutes behind the source. A production workload typically needs both: Backup for data protection and ASR for disaster recovery and business continuity.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Azure Site Recovery provides continuous delta replication of VMs to a target region to enable near-zero RPO disaster recovery, replication policies control the frequency of crash-consistent and app-consistent recovery points, and network mapping ensures failed-over VMs land in the correct target VNet. Next up we explore how to safely test and execute failover with ASR.