Skip to main content
Azure Site Recovery (ASR) provides business continuity and disaster recovery (BCDR) by replicating virtual machines so workloads can continue running from a secondary region if a primary region becomes unavailable. This guide explains the ASR architecture and walks through configuring ASR for a single virtual machine from the Azure portal. It preserves the original diagram and screenshots while improving clarity and flow.

​
How Azure Site Recovery works — architecture overview

Conceptually, Azure Site Recovery replicates VM data from a primary (source) region to a secondary (target) region using a staged cache and managed disks. The high-level workflow:
  • Source environment: VMs running in an availability set, connected to a VNet/subnets in Region A.
  • Enable (enroll) VM for ASR: the ASR Mobility service extension is installed on the VM and a cache (staging) storage account is created in the source region to stage replication data.
  • ASR provisions infrastructure in the target region (Region B): resource group, virtual network, subnets, availability sets, and other related resources. ASR commonly appends an identifier (for example, -asr-west-us) to created resources.
  • Data replication: the cache storage account acts as an intermediary to replicate data to managed disks in the target region.
  • Failover: if the primary region fails, ASR creates VM instances in the secondary region and attaches the replicated managed disks so the VM can run from Region B.
At a glance, this is the architecture:
A diagram of Azure Site Recovery showing a Source Environment (Region A) and a Target Environment (Region B) with vnets, availability sets, subnets, disks and a cache storage account, connected by a failover arrow. It illustrates replication of virtual machines and disks from the source to the target region.

​
Key ASR components

For full product docs see: Azure Site Recovery overview and Recovery Services vault documentation.

​
Portal walkthrough (single VM)

This section walks through configuring ASR for one VM from the Azure portal. Steps assume you have a VM (example name: ASR Demo 1) running in the source region.
  1. Open the VM in the Azure portal and select Disaster recovery.
  2. Choose or create a Recovery Services vault. Select the target region for replication (for example, West US if the VM is in East US).
  3. Configure Advanced settings:
    • Control the infrastructure ASR will create in the target region: resource group, virtual network, availability set, etc.
    • ASR typically appends identifiers such as -asr-west-us to created resource names.
  4. Single-instance VMs: proximity placement groups are not commonly used; capacity reservations are optional.
  5. Storage settings: choose the cache (staging) storage account in the source region.
  6. Replication settings: choose the vault, replication policy, and replica disk type.
  7. Extension settings: control installation and management of the ASR Mobility service extension on the VM.
Before starting replication, the portal shows an overview of the replication settings so you can review what will be created:
A screenshot of the Microsoft Azure portal showing the "rsv-demo-1 | Disaster recovery" page for a virtual machine. It displays replication and recovery settings (churn, cache storage, replica disk type, vault/subscription, replication policy) with buttons to review and start replication.
  • Click Review and Start Replication to see the full list of resources ASR will provision in the target region (replica managed disks, ASR resource group, VNet, availability set, etc.).
  • Click Start Replication to provision the target resources and begin initial replication. The initial provisioning and seeding can take time depending on data size and network bandwidth.
After replication completes, the protected item displays health, RPO (for example, 4 minutes), and protection status. The infrastructure view shows the source VM and cache storage account in the primary region and the replicated managed disk in the disaster recovery region.

​
Test failover — run a non-disruptive drill

Use a test failover to perform a DR drill without impacting production replication:
  • Test failover creates a temporary VM in the target region and attaches the replicated disks to it.
  • You can choose the recovery point to use (latest processed, app-consistent point, etc.).
  • Select the virtual network to place the test VM in; ASR creates an isolated test VM so production replication continues.
During a test failover, the portal displays job progress (pre-checks, creating the test VM, preparing it, and starting the VM):
A screenshot of the Microsoft Azure portal showing a "Test failover" Site Recovery job with vault and protected item details. Below is a list of job steps (prerequisites check, create test VM, preparing VM, start VM) with two steps marked successful and one shown as in progress.
When the test VM starts, it appears in the Virtual Machines list with an ASR-prefixed test VM name:
A screenshot of the Microsoft Azure portal showing the "Virtual machines" page. It lists three VMs with details like name, subscription, resource group, location, status, operating system, size and public IP addresses.

​
Practical items during test failover

  • Network Security Groups (NSGs) are not always created or associated automatically. You may need to create and associate an NSG with the DR subnet to allow inbound traffic (for example, HTTP 80 and RDP 3389).
  • Public IPs are not automatically created for test VMs. If public access is required (e.g., to validate a web server or RDP), create a Public IP resource and manually attach it to the test VM’s network interface.
During test failovers, lack of proper NSG rules or a Public IP can block your ability to validate services. Confirm network security and IP assignment before expecting external access to the test VM.
Example: creating an NSG and associating it with the ASR subnet, then attaching a Public IP to the test VM:
Screenshot of the Microsoft Azure portal on the "Create network security group" page showing project and instance details. Visible fields include Subscription (Kodekloud Azure Admin - PoC 1), Resource group (rg-backup-rsv-asr), Name (rsv-dr-nsg) and Region (West US).
After creating and associating the NSG and attaching the Public IP to the test VM’s NIC, you can connect to the test VM (for example, browse the IIS page served by the instance). This validates that the VM and its data were successfully replicated.

​
Cleanup and real failover

  • Cleanup test failover: after verification, use Cleanup test failover from the replicated items blade to delete the test VM and temporary resources created during the test.
  • Real failover: to fail over production workloads permanently to the secondary region, use the Failover option. After the primary region is restored, perform a reverse operation (re-protect and commit the failback) to resume replication back to the primary region.

​
Advanced features

ASR includes advanced orchestration capabilities not covered here, such as Recovery Plans, runbook automation, and traffic management integration with Azure Traffic Manager. These features help coordinate multi-VM application failovers and global traffic routing.
Focus on the high-level ASR workflow: enable replication for a VM, understand that ASR installs an extension and uses a cache/staging storage account, run test failovers to drill procedures, perform failover to the secondary region, and re-protect/commit to fail back to the primary region. You do not need to memorize every advanced automation option.

Watch Video