Azure Backup vs Site Recovery explained

Azure Backup keeps point-in-time copies of data so you can restore something that was lost or damaged, while Azure Site Recovery continuously replicates running machines to another location so you can fail over when a site is down. The decision rule is that “restore data from before the problem” means Backup, and “keep the workload running elsewhere” means Site Recovery. Large designs use both, because replication copies corruption and deletion just as faithfully as good data.

Start from the two numbers every question hides

Recovery questions are solved from two objectives in the scenario.

• RPO (recovery point objective): how much data you may lose, measured in time. “No more than 15 minutes of data” is an RPO.
• RTO (recovery time objective): how long the service may be down. “Back within one hour” is an RTO.

Backup gives restore points at the schedule you set, so the RPO is as long as the gap between backups, and the RTO is the time to restore. Site Recovery replicates continuously, so the RPO is small, and the RTO is the time to start the replicated VMs, which you shorten with recovery plans.

Layer 1: what Azure Backup protects and where it lives

Backup data sits in a vault, and the vault type is the most tested detail.

A backup policy holds the schedule and the retention for daily, weekly, monthly and yearly points. One policy can protect many items, and changing it changes all of them. The vault must be in the same region as the data it protects. For VMs the first step is a snapshot kept locally for quick restore, then the data moves to the vault.

Protection features that appear in questions:

• Soft delete: deleted backup data is kept for 14 additional days at no extra cost. Enhanced soft delete lets you extend that period to as much as 180 days (days beyond 14 are charged) and make it always-on so an attacker cannot disable it; newly created vaults have soft delete permanently enabled.
• Storage redundancy of the vault: locally redundant, zone-redundant or geo-redundant; see storage redundancy for what those mean.
• Cross Region Restore: with geo-redundant vaults you can restore VMs in the paired region on demand, without waiting for Microsoft to declare a disaster.
• RBAC on the vault: Azure Backup has built-in roles for managing recovery points, so the person who runs the VM need not be the person who can delete its backups. See Azure RBAC vs Entra roles.

Layer 2: what Site Recovery does

Site Recovery replicates machines, Azure VMs to another Azure region or on-premises VMware, Hyper-V and physical servers to Azure. The pieces to know:

• Continuous replication for Azure VMs, with application-consistent recovery points available.
• Failover and failback: planned failover, for an expected outage, can be done with zero data loss; unplanned failover loses whatever had not replicated. After the primary recovers, you fail back.
• Test failover: a disaster-recovery drill that does not interrupt ongoing replication. This is the right answer whenever a question asks how to validate a plan without affecting production.
• Recovery plans: an ordered group of machines, so a database starts before the application tier, with optional scripts and manual steps.

Worked example: one order system, three requirements

An order system runs on three VMs in North Europe. The business states: an operator may delete data by mistake, the service may be down at most 2 hours if the region fails, and no more than a few minutes of orders may be lost in that case.

1. Operator mistake. Azure Backup in a Recovery Services vault with daily points and 30 days retention; soft delete protects against deletion of the backup itself. A restore of a file or a VM covers this. Site Recovery cannot help: the deletion was replicated within minutes, and its recovery points cover only a short window (one day by default).
2. Region failure, RTO 2 hours, RPO minutes. Site Recovery replicating to West Europe, with a recovery plan that starts the database VM first. A daily backup would lose up to a day of orders, so it fails the RPO.
3. Proof it works. A scheduled test failover into an isolated network.

The answer uses both services, each for the requirement the other cannot meet.

A lock can break your backups

A cannot-delete lock on the resource group that Azure Backup creates for restore points stops the service from cleaning up old points, and backups start failing. A cannot-delete lock on a VM also complicates removing Site Recovery protection later. Governance and recovery interact; see Azure Policy vs RBAC vs locks.

Which exams test this

How exam questions are built around this

• “Accidentally deleted”, “ransomware”, “restore a file”, “retain for seven years” mean Backup. Retention and point-in-time restore are backup vocabulary.
• “Fail over”, “secondary region”, “minutes of data loss”, “recovery plan”, “test without affecting production” mean Site Recovery.
• The vault trap: a question names a workload and asks which vault; Azure VMs need a Recovery Services vault, and an Azure Disks or blob scenario points to a Backup vault.
• “Without waiting for Microsoft to declare a disaster” points to Cross Region Restore on a geo-redundant vault.
• Availability versus recovery: zones or sets keep a VM up through a localised failure; they do not restore data. Compare with availability sets vs zones.

Practice questions

Go deeper

• Overview of Recovery Services vaults, for soft delete and Cross Region Restore.
• About Azure Site Recovery, for scenarios, recovery plans and failover types.
• Lock your Azure resources, for the lock side effects on Backup and Site Recovery.
• On this site: availability sets vs zones, storage redundancy, and the AZ-305 cheat sheet.