Azure Site Recovery (ASR) is often framed as a simple "set it and forget it" backup solution, but its true power lies in its ability to orchestrate complex failover and failback processes that are highly configurable and deeply integrated into Azure’s networking and compute fabric.
Let’s see ASR in action. Imagine we have a critical multi-tier application running on Azure VMs: a web server VM (web-prod-01), an application server VM (app-prod-01), and a database server VM (db-prod-01). All are in the East US region. We want to set up disaster recovery for this application in the West US region.
First, we need a Recovery Services vault. This is the central management entity for ASR.
az resource create --name 'my-asr-vault' --resource-group 'prod-rg' --location 'eastus' --resource-type 'Microsoft.RecoveryServices/vaults' --properties '{"sku": {"name": "Standard"}}'
Next, we enable replication for our VMs. This involves creating a replication policy and then targeting the VMs. The replication policy defines RPO (Recovery Point Objective) and recovery frequency. A common RPO is 5 minutes.
# Create a replication policy
az backup recovery services vault replication policy create --vault-name 'my-asr-vault' --resource-group 'prod-rg' --name 'hourly-rpo-policy' --properties '{"properties": {"recoveryPointObjectiveInMinutes": 5, "replicationIntervalInSeconds": 300, "retentionPolicy": {"retentionPolicyType": "SimpleRetentionPolicy", "daysRetention": 7}, "enhancedReplicationPolicy": {"enableEnhancedReplication": false}}}'
# Enable replication for the web server VM
az backup recovery services vault replication protected-item create --vault-name 'my-asr-vault' --resource-group 'prod-rg' --name 'web-prod-01' --properties '{"properties": {"policyId": "/Subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.RecoveryServices/vaults/my-asr-vault/replicationPolicies/hourly-rpo-policy", "protectedItemType": "Microsoft.Compute/virtualMachines", "sourceId": "/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.Compute/virtualMachines/web-prod-01", "resourceGroupId": "/subscriptions/<subscription-id>/resourceGroups/prod-rg"}}'
You’d repeat the protected-item create command for app-prod-01 and db-prod-01. ASR then starts replicating the disks of these VMs to the target region. This initial replication can take a significant amount of time depending on the disk size and network bandwidth.
Once replication is established, you can test the failover. This spins up VMs in the target region using the replicated data, without impacting your production environment.
# Test failover for the web server VM
az backup recovery services vault replication protected-item replicate-test-failover --vault-name 'my-asr-vault' --resource-group 'prod-rg' --name 'web-prod-01' --properties '{"properties": {"recoveryPointId": "latest", "networkId": "/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.Network/virtualNetworks/test-vnet-westus", "recoveryVmName": "web-prod-01-test"}}'
The networkId here points to a test network in the target region. After the test, you clean it up.
# Clean up test failover
az backup recovery services vault replication protected-item commit-failover --vault-name 'my-asr-vault' --resource-group 'prod-rg' --name 'web-prod-01' --properties '{"properties": {"recoveryPointId": "latest"}}' # This is for actual failover commit, use 'reverse-replication' for test cleanup
The real power comes with defining Recovery Plans. These orchestrate the failover of multiple VMs in a specific order, with custom scripts and wait conditions. For our three-tier app, we’d want the database to come up first, then the app server, then the web server.
{
"properties": {
"provisioningState": "Succeeded",
"friendlyName": "MultiTierAppRecoveryPlan",
"vaultId": "/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.RecoveryServices/vaults/my-asr-vault",
"replicationProtectedItemIds": [
"/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.RecoveryServices/vaults/my-asr-vault/replicationFabrics/Azure/replicationProtectionContainers/Azure/protectedServers/web-prod-01",
"/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.RecoveryServices/vaults/my-asr-vault/replicationFabrics/Azure/replicationProtectionContainers/Azure/protectedServers/app-prod-01",
"/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.RecoveryServices/vaults/my-asr-vault/replicationFabrics/Azure/replicationProtectionContainers/Azure/protectedServers/db-prod-01"
],
"groups": [
{
"name": "DB_Tier",
"type": "Custom",
"order": 1,
"replicationProtectedItemIds": [
"/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.RecoveryServices/vaults/my-asr-vault/replicationFabrics/Azure/replicationProtectionContainers/Azure/protectedServers/db-prod-01"
]
},
{
"name": "App_Tier",
"type": "Custom",
"order": 2,
"replicationProtectedItemIds": [
"/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.RecoveryServices/vaults/my-asr-vault/replicationFabrics/Azure/replicationProtectionContainers/Azure/protectedServers/app-prod-01"
]
},
{
"name": "Web_Tier",
"type": "Custom",
"order": 3,
"replicationProtectedItemIds": [
"/subscriptions/<subscription-id>/resourceGroups/prod-rg/providers/Microsoft.RecoveryServices/vaults/my-asr-vault/replicationFabrics/Azure/replicationProtectionContainers/Azure/protectedServers/web-prod-01"
]
}
],
"loadTyping": "MultiVm",
"replicationProtectedItemCount": 3
}
}
This JSON defines the order of operations. You’d then use the az backup recovery services vault recovery-plan create command with this payload.
The most surprising thing about Azure Site Recovery is how its network mapping and IP address management during failover can be so granularly controlled, allowing you to either keep original IPs or assign new ones, and even integrate with Azure Traffic Manager for seamless cutovers.
When performing a failover, ASR doesn’t just spin up VMs. It creates a new virtual network in the target region (or uses an existing one) and attaches the replicated VMs to it. Crucially, you can define how IP addresses are handled. By default, ASR will assign new dynamic IP addresses to the failed-over VMs. However, you can pre-configure static IP addresses within the recovery plan or use Azure’s IP address pools to ensure your application’s network footprint remains consistent. This is vital for applications with hardcoded IP dependencies or for maintaining DNS records.
The next hurdle you’ll likely encounter is managing the failback process from the disaster recovery site back to your primary region, especially when dealing with complex application dependencies and data synchronization.