Availability primitives keep you running when a datacenter or region fails. They do nothing when a bad deployment corrupts a database, ransomware encrypts your files, or an operator deletes the wrong resource. Disaster recovery on Azure is two services solving two different problems, and conflating them leaves a hole exactly where the worst incidents land. This guide covers Azure Backup and Azure Site Recovery, and the RTO/RPO thinking that decides how you use each.
Backup and DR are not the same thing
The first thing to get straight:
- Azure Backup takes point-in-time copies so you can restore after corruption, ransomware, accidental deletion, or a bad change. It answers "get the data back to how it was."
- Azure Site Recovery (ASR) replicates running workloads to a second region and orchestrates failover so you keep operating through a regional event. It answers "keep the service up."
Redundancy such as geo-redundant storage is availability, not recovery. It will faithfully replicate your corruption to the paired region. Backup is what protects you from yourself, and many workloads need both services, not one.
Set RTO and RPO before you touch a policy
DR configuration is meaningless without targets. RTO (how long recovery takes) and RPO (how much data you can lose) are business decisions and must be signed off by the business, then set per workload rather than defaulting everything to one policy. The two services map to these numbers differently:
| Objective | Azure Backup | Azure Site Recovery |
|---|---|---|
| RPO driver | Time since last backup | Continuous replication lag (seconds) |
| RTO driver | Restore speed (slower) | Rehearsed failover + boot (minutes) |
| Protects against | Corruption, ransomware, deletion | Regional and infrastructure outage |
A mission-critical tier usually wants ASR for a low RTO and Backup for the corruption case; a deferrable workload might need only a nightly backup. Pull these tiers straight from your business continuity planning.
Configure replication and make backups immutable
Enable ASR replication to the target region at a frequency that meets RPO, and schedule Azure Backup to match its RPO. Then close the door that ransomware walks through: turn on immutability and soft delete so recovery points cannot be tampered with or purged, even by a compromised admin account. A backup an attacker can delete is not a backup. This is also where identity matters, since a stolen admin identity is a common path to the backups themselves, which ties back to identity resilience.
Build a recovery plan with the right order
A multi-tier application does not recover by booting every machine at once. Group machines into an ASR recovery plan with the correct boot order, plus any scripted steps such as re-pointing a connection string or warming a cache. The database comes up before the app tier, the app tier before the front end. A recovery plan that ignores dependency order fails over successfully and still leaves you with a broken application.
Test without touching production
The single most valuable ASR feature is the test failover. It spins your replicated workloads up in an isolated network, so you can prove that machines boot, applications come up healthy, and your RTO/RPO targets are actually met, all without disrupting production or interrupting replication. Do it on a schedule. A DR plan that has never been test-failed-over is an assumption, and the July 2024 Central US outage showed what happens to workloads that assumed instead of rehearsing: they waited on Microsoft's recovery timeline rather than their own.
Where this fits
Backup and Site Recovery are the recovery half of resilience; multi-region failover and global routing are the availability half. Together they cover the ladder your continuity plan tiers against. Add outage alerts so detection is automatic, track outage history across providers at clouddowntime.com/data, recover SLA credits after a qualifying Microsoft outage at cloudslacredit.com, and let nextsignal.io watch your bill for both outage credits and silent billing drift.