Skip to main content
azuredown

Azure Backup and Site Recovery: A Practical DR Guide

AzureDown Research · Resilience engineeringPublished June 26, 2026Updated July 18, 20269 min read
A hard disk drive mechanism

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:

ObjectiveAzure BackupAzure Site Recovery
RPO driverTime since last backupContinuous replication lag (seconds)
RTO driverRestore speed (slower)Rehearsed failover + boot (minutes)
Protects againstCorruption, ransomware, deletionRegional 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.

Frequently asked questions

What is the difference between Azure Backup and Azure Site Recovery?

Azure Backup takes point-in-time copies of data and machines so you can restore after corruption, ransomware, accidental deletion, or a bad change. Azure Site Recovery replicates running workloads to another region and orchestrates failover so you can keep operating through a regional outage. Backup is about recovering data; Site Recovery is about continuity of service. Many workloads need both.

How do RTO and RPO map to Azure DR services?

RPO, how much data you can lose, is set by replication and backup frequency: Site Recovery replicates continuously for a low RPO, while Backup RPO equals the time since the last backup. RTO, how long recovery takes, is set by how fast you can fail over and boot: a rehearsed Site Recovery recovery plan hits minutes to tens of minutes, whereas a full restore from backup is slower.

Can I test Azure Site Recovery without disrupting production?

Yes. Site Recovery provides a test failover that spins up your replicated workloads in an isolated network, so you can validate that machines boot, applications come up, and RTO/RPO targets are met without affecting the live environment or the ongoing replication. Regular test failovers are the only honest proof that your DR plan works.

Does Azure back up my data automatically?

Not comprehensively. Some services offer built-in redundancy like geo-redundant storage, but application-consistent backup with a tested restore is your responsibility through Azure Backup and service-native features. Redundancy gives you availability; it does not protect against data corruption, ransomware, or a bad deployment. That is what backup is for.

See the patterns in practice in the outage post-mortems, or get instant outage alerts.