Disaster Recovery Strategies in Azure

DR tiers and recovery objectives

Not every workload needs the same level of DR investment. Tier your applications by criticality and assign recovery objectives accordingly. This prevents over-engineering low-criticality systems and under-engineering mission-critical ones.

Assign every production workload to a tier during architecture review. The tier determines the DR investment level and which Azure services you use for that workload. Review tier assignments annually as business criticality changes.

Azure Site Recovery for VM replication

Azure Site Recovery (ASR) provides continuous replication of VMs from a source region to a target (recovery) region. It replicates at the VM disk level, asynchronously, with a configurable RPO target (typically 30 seconds to 24 hours). When a disaster occurs, you initiate a failover and ASR creates the VMs in the recovery region from the latest replication point. For Tier 1 and Tier 2 workloads that run on VMs, ASR is the primary DR mechanism.

# Set up ASR for a VM (assumes Recovery Services vault already created in target region)
# Step 1: Register the source subscription with ASR provider
az provider register --namespace Microsoft.RecoveryServices

# Step 2: Enable replication for a VM via the portal or ARM template
# (CLI enablement requires an ARM template due to ASR's complexity)
# Verify replication health after enabling
az backup item show \
  --resource-group recovery-rg \
  --vault-name myRecoveryVault \
  --name myVM \
  --backup-management-type AzureIaasVM \
  --workload-type VM

# Step 3: View ASR protected items
az site-recovery protected-item list \
  --resource-group recovery-rg \
  --vault-name myRecoveryVault \
  --fabric-name primaryRegionFabric \
  --protection-container-name primaryContainer

ASR has a Test Failover capability that creates a copy of the protected VMs in an isolated virtual network in the recovery region. This allows you to verify that the VMs start correctly, that applications initialise, and that connectivity works — without affecting the live replication or the production environment. Run test failovers quarterly.

Database disaster recovery

Each managed database service in Azure has its own DR mechanism. Match the mechanism to your RPO requirement.

Azure SQL Database provides automated backups (full weekly, differential every 12 hours, transaction logs every 5–12 minutes) retained for 1–35 days. For cross-region DR, active geo-replication creates a continuously synchronised readable secondary in another region. Failover can be initiated manually or automatically via a failover group. Failover group DNS entries update automatically after failover, so applications using the listener endpoint do not need reconfiguration.

# Create a failover group for Azure SQL Database
az sql failover-group create \
  --name myFailoverGroup \
  --resource-group myRG \
  --server myPrimaryServer \
  --partner-server mySecondaryServer \
  --partner-resource-group myDRRG \
  --failover-policy Automatic \
  --grace-period 1

# Initiate manual failover (for DR test or planned maintenance)
az sql failover-group set-primary \
  --name myFailoverGroup \
  --resource-group myDRRG \
  --server mySecondaryServer

Azure Cosmos DB supports point-in-time restore within a region (up to 30 days) and geo-replication for cross-region DR. With multi-region writes enabled, a regional outage does not require a failover — traffic routes to the remaining write region automatically. The failover priority list determines which region becomes the new write region if the primary fails in single-write mode.

Azure Database for PostgreSQL Flexible Server with zone-redundant HA handles zone failures automatically. For regional DR, enable geo-redundant backup, which replicates backup files to the paired region. Restoration to the paired region is a manual process (restore from geo-redundant backup to a new server in the target region).

Azure Backup for data protection

Azure Backup provides managed backup for VMs, SQL databases, PostgreSQL, Azure Files, Blob Storage, and on-premises workloads. Backups are stored in a Recovery Services vault. Configure the vault with geo-redundant storage (GRS) to replicate backup data to the paired region, or zone-redundant storage (ZRS) for zone-redundant backup within the same region.

For compliance-regulated workloads, enable immutable vaults. An immutable vault prevents backup data from being modified or deleted for a configured period, even by administrators. This protects against ransomware attacks that attempt to destroy backups before encrypting production data.

# Create a GRS Recovery Services vault
az backup vault create \
  --resource-group myRG \
  --name myBackupVault \
  --location eastus

az backup vault backup-properties set \
  --resource-group myRG \
  --name myBackupVault \
  --backup-storage-redundancy GeoRedundant

# Enable VM backup with a daily policy
az backup protection enable-for-vm \
  --resource-group myRG \
  --vault-name myBackupVault \
  --vm myVM \
  --policy-name DefaultPolicy

# Check backup job status
az backup job list \
  --resource-group myRG \
  --vault-name myBackupVault \
  --output table

DR runbooks and automation

A DR plan with no runbook is a plan that will fail under the stress of an actual disaster. Write step-by-step runbooks for every Tier 1 and Tier 2 workload. The runbook should be detailed enough that any member of the on-call team can execute it, not just the system’s primary engineer.

Automate as much of the failover process as possible using Azure Automation runbooks or Azure Logic Apps. Manual steps take time and are error-prone under pressure. An automated failover that triggers on an Azure Monitor alert can execute a failover in minutes without human intervention.

Every runbook must include: the trigger criteria for initiating failover, the sequence of steps, the validation checks after each step (how do you know it worked?), the rollback steps if failover causes worse problems, and the communication plan (who to notify, in what order, through what channel).

Testing DR plans

A DR plan that has never been tested is an unvalidated assumption. DR tests reveal gaps that are invisible in documentation: the secondary region’s DNS was not updated, the SSL certificate for the DR endpoint was never provisioned, the failover database connection string was not updated in the application configuration.

Run three levels of DR testing:

• Component tests (monthly): Test individual DR capabilities in isolation. Restore a database backup to a test server. Run an ASR test failover in an isolated network.
• Partial DR drill (quarterly): Simulate a single-service failure and execute the runbook. Measure actual RTO and compare to target.
• Full DR simulation (annually): Simulate a complete regional failure. Execute all runbooks in sequence. Measure total recovery time. Identify and fix gaps before the next annual test.