In one sentence. Backup gives you last night's copy; getting a server running from it in another city takes hours. Site Recovery keeps a second copy of the server's disks in another region updated every few minutes. When the first region fails you press Failover and the copy becomes a running VM. When the first region is back, you reverse the process.
Azure Backup · a copy taken every night, kept for years
VM-SQL1Australia East
→snapshot
Backup policydaily 22:00
→incremental copy
Recovery Services vault30 daily, 12 monthly, 7 yearly points
→restore
Restored VMhours later, as it looked that night
Answers "give me how it looked last Tuesday"
- Data loss (RPO): up to a day
- Time to recover (RTO): hours
- Keeps history for years
- Cheap: pays for stored changes
- Restore in another region needs a GRS vault
Azure Site Recovery · a live copy in another region, ready to switch on
VM-SQL1Australia East
→continuous
Replicationdisk changes copied every few minutes
→kept current
Replica disksAustralia Southeast, no VM running yet
→Failover button
Failover VMrunning within minutes
Answers "keep it running somewhere else, now"
- Data loss (RPO): minutes
- Time to recover (RTO): minutes to an hour
- Test failover runs in an isolated network with no impact
- After the disaster: commit → re-protect → failback
- Pays for replica disks plus a per-VM fee
Which is better?
"Recoverable in another region within one hour" = Site Recovery. "Restore to how it was three weeks ago" or "keep copies for seven years" = Backup. Both can live in the same Recovery Services vault.
You, the admin: protect VM-SQL1 so it can run in Melbourne within the hour
- Use the same vault type, RSV-Prod › Site Recovery › Enable replication › Azure virtual machines. Source region Australia East, resource group RG-Prod, VM-SQL1.
- Target: region Australia Southeast (any region is allowed, not only the pair), target resource group RG-Prod-asr, target VNet, a cache storage account in the source region. Replication policy: recovery points kept 24 h, app-consistent snapshot every 4 h (crash-consistent points arrive every 5 min).
- Wait for initial sync. Then Replicated items › VM-SQL1 › Test failover into an isolated test VNet; log in, check, then Cleanup test failover. Production replication never stops during a test.
- Optional Recovery plan: group VMs and order them (database before web), add scripts.
- Real disaster: Failover, choose Latest or Latest app-consistent point. When happy, Commit. Once the primary is healthy: Re-protect (replicate back), then Failover again towards Australia East (the failback), then re-protect once more.
- Cost: the target disks, the cache account, and a per-VM Site Recovery fee after the first 31 days free.
- Also migrates on-prem VMware and Hyper-V servers into Azure, though Azure Migrate is now the front door for that.
| Question | Backup | Site Recovery |
|---|---|---|
| What it answers | "Give me how it looked at 22:00 last Tuesday" | "Keep it running somewhere else, now" |
| Data loss (RPO) | Hours to a day | Minutes |
| Time to recover (RTO) | Hours | Minutes to an hour |
| Long history | Years | Up to 15 days of points |
Trap wording. "Within 1 hour after a regional failure" = Site Recovery. "Test without affecting production" = test failover. "Return to the primary region" = commit → re-protect → failover (failback). "Only the paired region?" no, any region.