Azure Backup and Site Recovery: Protect Your Workloads

Every production workload needs a resilience strategy that answers two questions: How quickly can we restore data after an accidental deletion or corruption? (Recovery Point Objective — RPO) and How quickly can we restore service after a disaster? (Recovery Time Objective — RTO). Azure provides two services that answer these questions: Azure Backup for data protection and Azure Site Recovery (ASR) for disaster recovery and business continuity.

Azure Backup: Data Protection

Azure Backup is a cloud-native backup service that protects Azure VMs, SQL Server databases, Azure Files shares, on-premises servers, and more. Backups are stored in a Recovery Services Vault — a geo-redundant storage container that also serves as the management plane for backup policies and restore operations.

Creating a Recovery Services Vault

# Create a resource group for backup infrastructure
az group create --name rg-backup-demo --location eastus

# Create a Recovery Services Vault
az backup vault create 
  --resource-group rg-backup-demo 
  --name rsv-prod-eastus 
  --location eastus

# Set storage redundancy to geo-redundant (default, recommended)
az backup vault backup-properties set 
  --resource-group rg-backup-demo 
  --name rsv-prod-eastus 
  --backup-storage-redundancy GeoRedundant

Enabling VM Backup

# Enable backup for an existing VM with the default policy
az backup protection enable-for-vm 
  --resource-group rg-backup-demo 
  --vault-name rsv-prod-eastus 
  --vm vm-webserver 
  --policy-name DefaultPolicy

# Trigger an on-demand backup immediately
az backup protection backup-now 
  --resource-group rg-backup-demo 
  --vault-name rsv-prod-eastus 
  --container-name vm-webserver 
  --item-name vm-webserver 
  --retain-until 2026-12-31

The Default Policy takes a daily backup at 10:00 PM UTC and retains it for 30 days. You can create custom policies with different schedules — weekly full backups retained for 12 weeks, monthly backups retained for 12 months, and yearly backups for long-term compliance requirements.

Restoring a VM

Azure Backup offers three restore options:

• Create a new VM: Spin up a new VM from the backup — fastest for complete disaster recovery.
• Restore disks: Restore the managed disks to a storage account, then attach them to an existing or new VM.
• File recovery: Mount the backup as a network share and copy only the specific files you need — ideal for recovering accidentally deleted files without restoring the entire VM.

# List available recovery points
az backup recoverypoint list 
  --resource-group rg-backup-demo 
  --vault-name rsv-prod-eastus 
  --container-name vm-webserver 
  --item-name vm-webserver 
  --output table

# Restore to a new VM from a specific recovery point
az backup restore restore-disks 
  --resource-group rg-backup-demo 
  --vault-name rsv-prod-eastus 
  --container-name vm-webserver 
  --item-name vm-webserver 
  --rp-name <RECOVERY_POINT_NAME> 
  --storage-account mystorageacct2026 
  --target-resource-group rg-vm-demo

Azure Site Recovery: Disaster Recovery

Azure Site Recovery (ASR) replicates workloads running on Azure VMs, on-premises VMware VMs, Hyper-V VMs, and physical servers to a secondary Azure region. If the primary region becomes unavailable, you failover to the secondary region — ASR brings up the replicated VMs there with a target RTO of minutes and RPO of 15 seconds for Azure-to-Azure replication.

Enabling Replication for Azure VMs

1. In the Portal, navigate to your VM and select Disaster recovery from the left menu.
2. Choose the target region (e.g., West US 2 if your primary is East US).
3. Review the auto-created target resources (VNet, storage account, cache storage account) and customize as needed.
4. Click Enable replication.

ASR installs the Mobility Service agent on the VM and begins continuous replication. Initial replication copies the full disk; subsequent replication sends only changed blocks (delta sync).

Test Failover

Run a Test Failover regularly — at least quarterly — to verify your recovery plan works without affecting production:

1. Navigate to the VM in the Recovery Services Vault > Replicated items.
2. Click Test Failover, select a recovery point, and choose an isolated test VNet.
3. ASR creates the test VM in the secondary region. Verify it boots and the application works.
4. Click Cleanup test failover when done — this removes the test VM.

Actual Failover

In a real disaster, initiate a Failover (not Test Failover). Select the latest recovery point and click Failover. ASR brings up the VM in the secondary region. Update DNS records to point to the new IP addresses. Once the primary region recovers, perform a Failback to return to the primary region.

Backup vs Site Recovery: When to Use Which

• Azure Backup: Protects against accidental deletion, data corruption, and ransomware. RPO measured in hours (based on backup frequency). Restores take 15-60 minutes.
• Azure Site Recovery: Protects against regional outages and major infrastructure failures. RPO measured in seconds (15-second for Azure-to-Azure). Failover completes in minutes.

Use both together for comprehensive protection: Backup for data-level recovery, ASR for infrastructure-level business continuity.

Key Takeaways

Store all backups in a geo-redundant Recovery Services Vault, define backup policies that match your compliance requirements, and test restores regularly — a backup you have never tested is not a backup. For critical workloads, pair Azure Backup with Site Recovery to achieve both short RPO for data and short RTO for infrastructure. Run test failovers quarterly to keep your DR plan current and your team practiced.