Azure Backup vs Site Recovery: restore the data, or move the whole workload

Two services live under the same "business continuity" umbrella, share a portal, and are constantly mixed up in interviews. But they answer completely different questions. One asks "how do I get my data back?" The other asks "how do I keep running when the whole site is gone?" Knowing which is which is the difference between a clean recovery and a very bad afternoon.

Azure groups both under BCDR — business continuity and disaster recovery — and that shared label is exactly why people conflate them. Let us separate them by the question each one answers. Azure Backup keeps your data safe and restorable. Azure Site Recovery keeps your workloads running through an outage. Data recovery versus workload continuity. Everything else follows from that.

Azure Backup: point-in-time copies you can restore

Microsoft's definition is plain: Azure Backup provides "simple, secure, and cost-effective solutions to back up your data and recover it from the Microsoft Azure cloud." It takes recovery points — snapshots at points in time — of VMs, files and folders, Azure Files, blobs, managed disks, and databases like SQL Server and SAP HANA running in VMs, storing them in a Recovery Services vault. When something goes wrong — a file is deleted, a database is corrupted, ransomware encrypts a disk, or a bad deploy scrambles your data — you restore from a recovery point. Backup answers "give me back the good version of this data from before it broke." It is your time machine.

Azure Site Recovery: a warm copy of the whole workload, ready to take over

Site Recovery is a different beast. In Microsoft's words, it "helps ensure business continuity by keeping business apps and workloads running during outages," and it does so by replicating workloads from a primary site to a secondary location. It continuously mirrors your running machines — Azure VMs between regions, or on-premises servers into Azure — so that if the primary site goes down, you fail over to the secondary and keep serving, then fail back once the primary recovers. Site Recovery answers "the whole region/datacenter just died — bring my application up somewhere else, now." It is not a copy of your data to restore; it is a standby copy of your running workload to switch to.

Backup is a time machine for your data. Site Recovery is a spare engine that keeps the application running when the first one dies.

RPO and RTO: the numbers that separate them

Two terms make the distinction concrete. RPO (recovery point objective) is how much data you can afford to lose — how far back your last good copy is. RTO (recovery time objective) is how long you can afford to be down. Backup typically has a coarser RPO (recovery points taken daily, or a few times a day) and a slower RTO (a restore takes time to run), which is fine for "I lost some data, give it back." Site Recovery is built for tight numbers: it offers continuous replication with recovery points and can support failover measured in minutes, because the workload is already replicated and standing by. If your requirement is "we cannot lose more than a few seconds and must be back in minutes," that is a Site Recovery requirement, not a Backup one.

Why you usually need both

Here is the trap: Site Recovery is not a backup. Because it replicates continuously, a logical disaster — corruption, an accidental mass-delete, ransomware — gets mirrored to your secondary almost immediately. Fail over and you are now running the corrupted copy. Backup, with its history of discrete recovery points, is what lets you go back to before the corruption. Conversely, Backup alone will not keep you online through a regional outage — restoring everything from a vault into a new region is slow, and your RTO blows past what the business can stand. So the mature answer is layered: Backup for the "get my data back" failures, Site Recovery for the "the whole site is gone" failures. This pairs naturally with the reliability ideas in zones vs regions — zones and Site Recovery cover infrastructure outages, Backup covers data loss.

The takeaway

Azure Backup and Azure Site Recovery both live under BCDR, but they solve opposite problems. Backup stores point-in-time recovery points so you can restore data that was deleted, corrupted, or encrypted — a time machine. Site Recovery replicates whole running workloads to a secondary location so you can fail over when a site or region goes down — a standby engine. Because Site Recovery faithfully replicates corruption and Backup can't meet a minutes-long RTO for a whole region, serious estates run both. "Backup for data recovery, Site Recovery for site-level failover, and never mistake one for the other" is the answer of someone who has actually had to recover something under pressure.