Azure Backup vs Azure Site Recovery: Data Protection vs Disaster Recovery

Azure Backup and Azure Site Recovery both fall under Azure’s business continuity and disaster recovery umbrella, and they both use a vault as their management container, which is exactly why the AZ-104 exam likes to blur them together in scenario questions. They solve different problems. Azure Backup protects against data loss or corruption: someone deletes a file, ransomware encrypts a disk, an application update corrupts a database, and you need to restore to a specific point in time before the damage happened. Azure Site Recovery protects against a regional disaster: an entire Azure region or on-premises site becomes unavailable, and you need the whole workload running somewhere else, fast, with minimal data loss. One restores data; the other relocates a running workload. Knowing which problem a scenario is describing is most of what this domain tests.

Azure Backup: point-in-time recovery points

Azure Backup takes scheduled, application-consistent (or crash-consistent, depending on configuration) snapshots of a protected resource and retains them as recovery points according to a backup policy you define, how often backups run, and how long each recovery point is kept. When something goes wrong, you restore from the most appropriate recovery point rather than rebuilding from scratch. It supports Azure VMs, SQL Server and SAP HANA running in Azure VMs, Azure Files shares, Azure Blobs, Azure Database for PostgreSQL, and on-premises servers through the MARS agent or Azure Backup Server.

Where the backup data actually lives depends on what you’re protecting. A Recovery Services vault holds backup data for Azure VMs, SQL and SAP HANA workloads on Azure VMs, and on-premises machines backed up through System Center DPM, Azure Backup Server, or the MARS agent, the same vault type Site Recovery also uses. A Backup vault is the newer, separate container used for workloads Azure Backup added more recently, such as Azure Database for PostgreSQL and operational backup of Blob storage. Both vault types support Azure RBAC, encryption with either platform-managed or customer-managed keys, and the storage redundancy options (LRS, ZRS, or GRS) common to Azure storage generally. Which vault a given scenario needs comes down entirely to which resource type is being protected, not a difference in what the vault itself does.

Soft delete: no longer a flat 14-day setting

Azure Backup’s soft-delete behavior changed materially in the last couple of years, and it’s worth verifying you’re not carrying an outdated mental model into the exam. Soft delete means that when a backup item is deleted, whether by an admin, a script, or a malicious actor, the underlying recovery points aren’t immediately purged. They move into a soft-deleted state and stay recoverable for a retention period, after which they’re permanently removed.

The current, “secure by default” behavior:

• Retention is configurable from 14 to 180 days, not fixed at 14. The 14-day default costs nothing extra; retention beyond 14 days incurs standard backup storage charges for the additional days.
• Soft delete is enforced, not optional, in regions where secure-by-default assurance has rolled out. In those regions you can’t disable soft delete from the portal, PowerShell, CLI, or the REST API, on any API version, which is a deliberate design choice to stop a compromised account or malicious actor from disabling the safety net and then deleting backups outright.
• A small set of preview regions still allow disabling soft delete for Backup vaults specifically (not Recovery Services vaults), an exception that’s shrinking as the rollout continues rather than a durable configuration option to plan around.
• Vault-level soft delete exists too. Deleting a Recovery Services vault or Backup vault that still contains soft-deleted items moves the vault itself into a soft-deleted state instead of removing it outright, and it can be recovered within the configured retention window.

If a scenario asks how to protect backup data against a malicious insider who has Contributor-level access and might try to delete backups to cover their tracks, the answer today is that soft delete is enforced by default in most regions and can’t be turned off by that same user, not a manual configuration step you’d need to remember to enable.

Azure Site Recovery: continuous replication and failover

Site Recovery works on an entirely different mechanism. Instead of periodic point-in-time snapshots, it sets up continuous replication of a VM’s disk writes from a primary location to a secondary one, whether that’s Azure region to Azure region, on-premises VMware or Hyper-V to Azure, or physical servers to Azure. Replication frequency can run as low as 30 seconds for Hyper-V, and Azure VM-to-VM replication is continuous, which keeps the recovery point objective (RPO) tight compared to a backup schedule measured in hours.

When an outage hits the primary location, Site Recovery performs a failover, spinning up VMs in the secondary location from the replicated data. Failovers can be planned (for a known, scheduled event, with zero data loss) or unplanned (for an actual disaster, with minimal data loss bounded by replication frequency). Multi-tier applications spanning several VMs can be sequenced and orchestrated together using a recovery plan, which groups machines and can trigger scripts or Azure Automation runbooks as part of the failover sequence, rather than failing machines over independently and hoping the dependency order works out. Once the primary location is healthy again, failback moves the workload back.

Site Recovery uses a Recovery Services vault exclusively, the same vault type Azure Backup uses for VM and on-premises workloads, but it stores replication configuration and orchestration state there, not recovery points. This is a frequent point of confusion: seeing “Recovery Services vault” in a question doesn’t tell you by itself whether the scenario is about Backup or Site Recovery, since both services can use the same vault type for different purposes, and a single vault can hold both Backup and Site Recovery configuration for the same set of VMs.

Backup vs. Site Recovery at a glance

Aspect	Azure Backup	Azure Site Recovery
Protects against	Data loss, corruption, accidental or malicious deletion	Regional or site-wide disaster
Mechanism	Scheduled point-in-time recovery points	Continuous replication
Recovery unit	A file, disk, database, or VM restored to a point in time	An entire workload failed over to run in a new location
Vault type	Recovery Services vault or Backup vault, depending on resource type	Recovery Services vault only
Typical RPO	Hours (based on backup schedule)	Seconds to minutes (based on replication frequency)
Soft delete	14–180 days, enforced by default in most regions	Not applicable (it’s not a point-in-time recovery-point service)

How the AZ-104 exam tests this

• A scenario describes recovering a single accidentally deleted file or a corrupted database to a point before the damage occurred. That’s Azure Backup and a recovery point, not Site Recovery, which doesn’t keep discrete restorable snapshots the same way.
• A scenario describes an entire region becoming unavailable and needing the application running elsewhere within minutes. That’s Site Recovery’s continuous replication and failover, not Backup, whose restore process is built around recovery points, not spinning up a live secondary environment.
• A scenario has an admin trying to disable soft delete to immediately purge a backup, and the exam wants you to recognize that in most regions this isn’t possible anymore. Soft delete is enforced by default, with retention configurable from 14 to 180 days, not a togglable setting an attacker or a rushed admin can simply switch off.
• A scenario names the vault type for protecting an Azure Database for PostgreSQL server or Blob storage. That’s a Backup vault, distinct from the Recovery Services vault used for VM and on-premises backup as well as Site Recovery.
• A scenario mentions a multi-tier application across several VMs needing an orchestrated, sequenced disaster-recovery failover. That’s Site Recovery’s recovery plans, not individual VM-level backup restores.

Backup and Site Recovery sit in the same domain but answer opposite questions: “how do I undo damage to my data” versus “how do I keep the application running when a whole location goes down.” For related resiliency concepts this domain builds on, see Availability Sets vs Availability Zones and Azure VM Disk Encryption Options, or return to the AZ-104 study guide for how this fits the rest of the exam.