Azure Site Recovery
Region-to-region · Zone-to-zone · Recovery plans · Test failover
Practice questions for this topic →
What ASR does
| Scenario | Notes |
|---|---|
| Azure VM → another region | Continuous replication; fail over and fail back |
| Azure VM → another zone (same region) | Zone-to-zone DR; data stays in region; not for ZRS disks or Ultra Disks; the vault can be in another region (it holds only metadata) |
| On-prem VMware/Hyper-V/physical → Azure | DR to Azure (and migration) |
| Recovery plans | Group machines (up to 100 protected instances per plan); groups fail over in order and machines within a group in parallel; add scripts, runbooks and manual steps |
| Test failover | DR drill into an isolated VNet that mimics production (same subnet names and address ranges keep placement and IPs); no impact on production or replication |
Recovery point choice at failover
| Option | Optimizes |
|---|---|
| Latest processed | Lowest RTO (no processing wait) |
| Latest | Lowest RPO (processes all pending data first) |
| Latest app-consistent | Application consistency |
| Latest multi-VM processed / app-consistent | Consistency across VMs in a replication group |
| Custom | Specific point |
Running a test failover (Microsoft Learn order)
- In Site Recovery select Recovery Plans → the plan → Test Failover; select a recovery point; select the Azure virtual network for the test VMs; then track progress on the Jobs tab. A test failover validates replication and your DR strategy without data loss or downtime and doesn't affect ongoing replication or production.
- Test VMs are created in a subnet with the same name and the same IP address as in the VM's Compute and Network settings. If no subnet has that name, the first subnet alphabetically is used; if the IP isn't free, another address in the subnet is assigned.
Testing and monitoring
| Dashboard state (test failover) | Meaning |
|---|---|
| Test recommended | Machines that haven't had a test failover since protection was enabled |
| Performed successfully | Machines with one or more successful test failovers |
| Not applicable | Machines not currently eligible (failed over, or initial replication, test failover or failover in progress) |
- Microsoft recommends a test failover at least once every six months; the failover article says at least once every 180 days. A test counts as successful only after the failover and the post-failover cleanup complete.
- Replicated-item states: Healthy, Warning, Critical (replication stuck or not keeping up with the change rate), Not applicable. A configuration-issue validator runs every 12 hours by default.
- Built-in Azure Monitor alerts cover unhealthy replication and failed failovers and can be routed through action groups.
Exam Tips
Tick each tip once you can answer it without looking.
“Fail over VMs to another region with RPO of minutes” → Azure Site Recovery. Trap: Azure Backup restores take longer and have hours-to-day RPO.
“Multi-tier app must start DB first, then app, then web, after failover” → ASR recovery plan with groups/ordering.
“DR drill without impacting production” → Test failover into an isolated VNet. Trap: Microsoft recommends running one at least every six months.
“DR from zone failure, data must stay in the region” → ASR zone-to-zone replication (or deploy across zones).
“Fail over with the least data loss” → Recovery point: Latest.
“Fail over as fast as possible” → Recovery point: Latest processed.
“Several VMs must recover to the same consistent point” → Multi-VM consistency (replication group).
“DR for on-prem Hyper-V/VMware servers to Azure” → Azure Site Recovery.
“Site Recovery dashboard: 'Test recommended'” → Machines with no test failover since protection began. Trap: Test failover success needs both the failover and the cleanup to complete.
“How often the configuration validator runs” → Every 12 hours by default (you can refresh it manually). Trap: Replicated-item states: Healthy, Warning, Critical, Not applicable.
“Recovery plan size” → Up to 100 protected instances per plan. Trap: Groups fail over in order; machines in a group fail over in parallel.
“Run a Site Recovery test failover on a recovery plan” → Recovery Plans, select the plan, Test Failover, choose a recovery point, choose the test virtual network, track progress on the Jobs tab. Trap: It doesn't affect replication or production; test VMs try the same-named subnet and the same IP address.