Start with the failure, not the product name
Azure Backup protects recoverability. It creates and retains recovery points so an administrator can restore data, files, disks, databases or a protected workload after deletion, corruption, ransomware or another data-loss event. Its design questions include backup frequency, retention, vault redundancy, security controls and tested restores.
Azure Site Recovery protects workload continuity for supported physical and virtual machines. It replicates workloads from a primary location to a secondary location, monitors replication health, and orchestrates test failover, planned or unplanned failover, reprotection and failback. Its design questions include recovery point objective (RPO), recovery time objective (RTO), target region, networking and application start order.
High availability keeps a service running through local component failures. Availability zones, availability sets, scale sets and load balancing belong here. They can reduce downtime, but they do not create historical recovery points and are not a complete regional disaster-recovery plan.
Restore an earlier copy after data loss → Azure Backup. Run the workload in another location during an outage → Site Recovery. Survive an instance or zone failure with minimal interruption → availability architecture. Mature systems often combine all three.
Azure Backup vs Site Recovery vs availability design
RPO is the acceptable amount of data loss measured in time. RTO is the acceptable time to restore service. A replication design can target a low RPO and fast failover, while a backup policy may retain many older points. Neither metric can be proven by a portal configuration alone; exercises and restore evidence matter.
Recovery Services vault vs Backup vault
Azure Backup stores protected data in vaults, but the vault type depends on the data source. A Recovery Services vault is used for Azure VM backups and established workloads such as SQL Server or SAP HANA in Azure VMs, Azure Files, MARS, DPM and Azure Backup Server. It also stores replication data and management information for Azure Site Recovery.
A Backup vault is the Azure Data Protection vault used for certain newer workloads. Microsoft currently gives examples such as Azure Database for PostgreSQL and other newer supported sources. The safest operational rule is to select the workload first and check the current support matrix; the two vault types are not interchangeable containers.
VM and established workload protection
Think Azure VM backup, traditional hybrid agents and Site Recovery. Configure storage redundancy and security before protecting workloads because some choices become constrained after protection begins.
Newer data-protection workloads
Think workload-specific Azure Data Protection support. Policies and backup instances are managed through the vault and centrally through Backup center.
Backup center is a centralized management experience, not a third vault type. It helps operators discover data sources, review jobs, monitor protection, apply policies and investigate alerts across vaults and subscriptions.
Scenario 1: a VM file was deleted yesterday
A business application is healthy, but a user deleted a required file and needs yesterday's version. Failing the entire workload into another region is unnecessary and may reproduce the same deletion. Select a valid Azure Backup recovery point and use the supported file or workload restore operation. Validate the recovered file with its owner before closing the incident.
The requirement is point-in-time data recovery, not workload continuity. The result is successful, usable restored data—not merely a completed backup job.
Scenario 2: the primary Azure region is unavailable
A multi-VM application must run in a secondary region. Site Recovery should already be replicating the supported VMs, and a tested recovery plan should sequence database, application and web tiers. During failover, validate target networking, DNS, security dependencies and the application itself. When the primary region is ready, re-protect and follow the tested failback process.
The goal is to continue the workload in another location within the required RTO and RPO. A vault containing backups can restore systems, but it does not by itself orchestrate a multi-tier failover.
Scenario 3: one frontend VM can fail without interruption
Deploy multiple instances across suitable fault boundaries and place them behind the appropriate load-balancing service. This is an availability problem. Still add Backup where the workload has recoverable state and Site Recovery when regional continuity is required.
These are original learning scenarios, not customer incidents or recalled Microsoft exam questions.
Build a recovery workflow an administrator can prove
Set recovery requirements
List protected data, failure modes, RPO, RTO, retention, compliance boundaries and recovery owners before choosing services.
Configure the right control
Create the supported vault, policy and protection instance, or enable replication with the correct target region, storage and network mappings.
Exercise recovery
Run restores and isolated test failovers. Record duration, data validity, dependency failures, corrective actions and approved results.
For Backup, inspect policy compliance, latest recovery points, failed jobs, alerts and restore results. For Site Recovery, inspect replication health, RPO, configuration issues, recovery plans and test-failover cleanup. Send alerts to the operational team and treat repeated warnings as protection gaps, not dashboard noise.
Security is part of recoverability. Apply least-privilege Azure RBAC, protect administrative actions, review soft delete and immutability options for the selected workload, and separate routine operators from people who can weaken protection. Confirm current feature support before relying on any control.
Production-style failure: the backup job says failed
- Identify the protected item and vault type. Do not troubleshoot the wrong provider or assume every workload uses Recovery Services.
- Read the job's exact error and timestamp. Correlate it with resource health, maintenance, extensions and recent changes.
- Check prerequisites. Validate permissions, connectivity, VM agent or extension health, storage state and workload-specific requirements.
- Check policy and protection state. Confirm the intended item is registered and the policy schedule and retention are correct.
- Retry only after correcting the cause. A successful retry is useful, but follow it with a restore test when the incident may have created a recovery gap.
- Update alerts and the runbook. The same silent failure should not recur without ownership.
Production-style failure: Site Recovery test failover cannot reach the app
First confirm that replication is healthy and the selected recovery point is appropriate. Then inspect the isolated test network, subnet mapping, NSGs, routes, DNS, load balancer or private endpoint dependencies and application startup order. A VM booting successfully does not prove that the application is recoverable. Clean up the test failover only after recording findings and corrective actions.
Common AZ-104 exam mistakes
- Choosing Site Recovery for a request to restore an older copy of one file.
- Assuming backup alone provides rapid multi-tier regional failover.
- Calling availability zones a backup or historical recovery mechanism.
- Creating the wrong vault type without checking the protected workload.
- Confusing Backup center with a vault that stores recovery points.
- Checking only that a backup job completed, without proving a restore works.
- Running a Site Recovery test failover into a production-connected network.
- Ignoring DNS, network mappings and dependency order during recovery planning.
- Assuming replication protects against every logical corruption or malicious change.
- Treating RPO and RTO as product defaults instead of business requirements to test.
Frequently asked questions
What is the main difference between Azure Backup and Azure Site Recovery?
Azure Backup creates recovery points used to restore data or a protected workload. Azure Site Recovery replicates supported machines to another location and orchestrates failover and failback so workloads can continue during an outage.
Does Site Recovery replace Azure Backup?
No. Replication supports continuity, but it can also reproduce unwanted changes or corrupted data. Backup provides separate recovery points and retention. Important workloads commonly need both controls for different failure modes.
When does AZ-104 require a Recovery Services vault?
The current AZ-104 outline includes creating both Recovery Services vaults and Backup vaults. A Recovery Services vault supports Azure VM and traditional workload backup scenarios and stores Site Recovery replication data. Always confirm the supported workload before choosing a vault.
What does an Azure Backup vault protect?
Microsoft describes Backup vaults as the vault type for certain newer Azure Backup workloads, including Azure Database for PostgreSQL and newer supported data sources. Workload support changes, so use the current Azure Backup support matrix rather than assuming every source uses the same vault.
How should I practise backup and recovery for AZ-104?
Create the appropriate vault, configure a policy, run an on-demand backup, inspect jobs and alerts, and perform a test restore. For Site Recovery, review replication health, recovery points, test failover, planned or unplanned failover, reprotection and failback.
Official Microsoft references
Confirm changing support details in Microsoft Learn: the current AZ-104 study guide, Azure Backup overview, Azure Site Recovery overview and vault selection guidance.