Monitor and maintain Azure resources
Backup, Restore, Vaults, and Site Recovery
CoreSelect vault, policy, restore, reporting, or regional failover operations from workload, RPO, and RTO requirements.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
Administrators must protect the right data source in a compatible vault and distinguish historical recovery from continuity in another region.
Must Know
- A Recovery Services vault supports Azure VM backup and Site Recovery plus other documented workloads; a Backup vault supports a different set of newer backup data sources.
- Vault choice depends on workload support, region, subscription, redundancy, identity, and protection requirements rather than which name sounds newer.
- A backup policy sets schedule and retention, determining available recovery points and influencing the achievable recovery-point objective.
- Azure Backup creates recovery points for restore; Site Recovery replicates supported workloads for test failover, failover, and reprotection.
- RPO measures acceptable data loss in time, while RTO measures acceptable time to restore service.
- Resiliency in Azure (formerly Azure Business Continuity Center) and Azure Monitor provide job, health, report, and alert visibility across protected resources; the older Backup Center remains available from the Resiliency Help menu.
Compare and Distinguish
- Recovery Services vault vs Backup vault: vault for supported VM backup and Site Recovery workloads vs vault for its own supported newer data-source families.
- Backup vs Site Recovery: retained recovery points for data or workload restore vs replicated workload continuity and failover.
- Restore vs failover: reconstruct selected state from a recovery point vs start replicated resources in a recovery location.
- RPO vs RTO: maximum acceptable data-loss interval vs maximum acceptable service-restoration time.
Scenario examples
- Scenario: An Azure VM must recover yesterday’s files after corruption. Think: Use an Azure Backup recovery point and perform the appropriate restore.
- Scenario: A critical VM must resume in a secondary region within minutes. Think: Configure Site Recovery replication and a tested failover plan aligned to RPO and RTO.
- Scenario: Operations needs trends across failed backup jobs and immediate failure notifications. Think: Configure reports and Azure Monitor alerts at the appropriate monitoring scope.
Exam traps
- A Backup vault is not a universal replacement for a Recovery Services vault; data-source support decides.
- A backup does not provide the same ready-to-fail-over secondary workload as Site Recovery.
- A test failover validates recovery without becoming the production failover, and cleanup is a distinct step.
Key takeaways
- Start with workload support and recovery requirement, then select vault, policy, restore, or Site Recovery action.
- Use backup for point-in-time recovery and Site Recovery for orchestrated continuity in a secondary region.
How it works
- Azure Backup transfers or snapshots protected state into managed recovery points according to policy and restores selected data from a chosen point.
- Site Recovery continuously replicates supported workload changes and orchestrates startup at the target during test or actual failover.
Objects and administrative surfaces
- Vault — region, subscription, storage redundancy, identity, security settings, protected items, policies, jobs, and alerts.
- Protected data source — backup policy, recovery points, restore operations, health, and retention state.
- Site Recovery replicated item and recovery plan — source, target region, replication health, test failover, failover, commit, reprotect, and failback path.
When to use it
- Use Azure Backup for accidental deletion, corruption, and historical restore requirements.
- Use Site Recovery when a supported workload needs regional continuity with a planned failover and failback lifecycle.
Security and governance implications
- Enable vault protections appropriate to the workload, tightly control destructive backup operations, and separate backup administration where practical.
- Test restores and Site Recovery failovers regularly because a successful replication or backup job alone does not prove application recovery.
How to reason about this
- For backup failure, inspect vault compatibility, policy, protected-item state, agent or extension, snapshot and network dependencies, permissions, job error, and available recovery points.
- For Site Recovery failure, inspect replication health, target quota and networking, dependency readiness, recovery-plan step, failover state, and reprotection direction.
More detail
- Create the compatible vault, configure its security and redundancy, define backup frequency and retention, enable protection, and run or monitor restore jobs.
- For Site Recovery, configure source and target dependencies, replication policy, test failover network, recovery plan, failover, commit, and reprotection as required.
Ready for the quiz?
- Which vault supports the named data source and protection operation?
- Does the requirement describe a recovery point or a running secondary-region copy?
- How do policy frequency and retention affect recovery choices?
- What evidence confirms backups are healthy across many vaults?
Related objectives
- D5.2.S1 — Create a Recovery Services vault
- D5.2.S2 — Create an Azure Backup vault
- D5.2.S3 — Create and configure a backup policy
- D5.2.S4 — Perform backup and restore operations by using Azure Backup
- D5.2.S5 — Configure Azure Site Recovery for Azure resources
- D5.2.S6 — Perform a failover to a secondary region by using Site Recovery
- D5.2.S7 — Configure and interpret reports and alerts for backups