AZ-104
Deep Dive
Azure Site Recovery replicates VMs and physical workloads to a secondary Azure region to enable disaster recovery. AZ-104 evaluates replication configuration, recovery plans, failover and failback.
Contents
Azure Site Recovery (ASR) continuously replicates Azure VMs between regions (or from on-premises to Azure) so that in case of a disaster you can fail over to the replica in minutes. It is not a backup — it's continuous replication for DR.
Critical difference: Backup saves point-in-time snapshots to restore data. ASR replicates the VM's full state in near real time for recovery after a region outage.
What it can replicate
Key benefits
What ASR is NOT
ASR components (Azure → Azure)
Recovery Services Vault
The main container where ASR is configured. Must be in the destination (secondary) region. Also used for Azure Backup.
Replication Policy
Defines: crash-consistent snapshot frequency (every 5 min), app-consistent snapshot frequency (every 1-12h), and recovery point retention (up to 72h).
Cache Storage Account
A temporary storage account in the source region where replication data is staged before being transferred to the destination region.
Target Resources
ASR automatically creates resources in the destination region: replica VNet, replica subnet, replica NIC. These resources are only used during failover.
Recovery point types
Crash-consistent
A snapshot of the disk state at that moment — equivalent to pulling the power cable on the VM. Data in memory is lost. Captured every 5 minutes.
App-consistent
A snapshot with OS quiescing — applications complete their pending writes before the snapshot. Data is consistent at the application level. Captured every 1-12 hours (configurable). Uses VSS on Windows.
Minimum RPO
With crash-consistent every 5 min: maximum RPO = 5 minutes of data lost in the event of a disaster. For transactional DBs, use app-consistent to guarantee transaction consistency.
Steps to enable replication
Mobility Service
An agent automatically installed by ASR on each replicated VM. Captures the data writes to the VM's disk and sends them to the cache storage account. For on-premises VMs: manual installation or via Configuration Server.
VM requirements
A Recovery Plan orchestrates the failover of multiple VMs in a specific order with custom actions between steps. It allows you to fail over an entire multi-tier application with dependencies.
Structure of a Recovery Plan
Groups (VM groups)
VMs are organized into numbered groups. Failover runs the groups in order: Group 1 completes before Group 2 starts.
Pre/Post actions
Between groups you can add: Azure Automation Runbooks (PowerShell/Python scripts) or Manual actions (pause for human intervention).
Example — 3-tier app
Group 1: DB Server → fails over first
Pre-action: script that verifies the DB is up
Group 2: App Servers → start after the DB
Group 3: Web/Frontend → start last
Test Failover
Test Failover lets you test DR without interrupting production. It creates the replica VMs in an isolated test VNet — production keeps running normally.
| Step | Action | Description |
|---|---|---|
| Failover 1 | Start failover | In the vault → Recovery Plan (or individual VM) → Failover. Select a recovery point and confirm. ASR creates the VMs in the secondary region. |
| Failover 2 | Verify secondary VMs | Confirm the VMs in the secondary region work correctly. Redirect DNS/Traffic Manager to the secondary region. |
| Failover 3 | Commit | Once verified, commit the failover. This finalizes the failover — the primary VM can no longer be used for failback without re-protection. |
| Re-protect 1 | Re-protect | After the commit, re-protect: now the secondary region is the primary. ASR starts replicating back to the original region. |
| Failback 1 | Failback (optional) | When the original region recovers, fail over back (failback) to the original region. |
| Failback 2 | Re-protect (final) | Re-protect again: the original region is primary, the secondary is DR. Configuration restored to its initial state. |
Failover types
Planned Failover
The primary VM is stopped first, syncs final data, then starts on the secondary. RPO = 0 (no data loss). For planned migrations.
Unplanned Failover
The primary region is unavailable. Failover from the last available recovery point. Some data loss possible (depends on the RPO of the last point).
Test Failover
A test with no impact on production. Replica VMs created in an isolated VNet. Does not interrupt active replication. Cleanup when done.
When to use ASR
Important limits
ASR costs
ASR license
Per protected instance per month. The first 31 days are free per instance.
Replica storage
Managed disks in the secondary region (billed even if the VM isn't running).
Replication egress
Data transfer between regions for continuous replication (standard egress cost).
Did you get this topic?
Test what you just learned
An administrator runs a Test Failover of a Recovery Plan in ASR. What is the impact on the production VMs in the primary region?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.