Azure Backup & Site Recovery: Vaults, Policies & Failover (AZ-104)

Everything in Azure Backup and Azure Site Recovery lives inside a vault, and the exam expects you to know that two kinds now exist. A Recovery Services vault is the original, well-established container. It holds backup data and recovery points for classic workloads — Azure virtual machines, Azure Files, SQL Server and SAP HANA running inside a VM, and on-premises servers — and it is also the container that Azure Site Recovery uses to manage replication and failover. If a question mentions backing up a VM or configuring Site Recovery, the Recovery Services vault is the answer.

The newer Azure Backup vault supports a growing set of modern workloads that the Recovery Services vault does not, such as Azure Database for PostgreSQL, Azure Blobs, and Azure managed disks. It represents Azure's forward-looking backup platform, and Microsoft continues to add supported datasources to it.

Both vault types are managed together in Backup center, a single pane for monitoring and governing backups across a subscription or tenant. A vault also defines the storage redundancy for its data — locally redundant, zone-redundant, or geo-redundant — which you set before the first backup runs. On the exam, remember the split: Recovery Services vault for VMs, Azure Files, and Site Recovery; Azure Backup vault for newer datasources like databases, blobs, and disks. Knowing both exist and which workloads each targets is enough for AZ-104.

A backup policy defines when backups run and how long the recovery points are kept — in other words, a schedule plus a retention rule. You attach a policy when you enable backup for a resource, and you can reuse one policy across many items so protection stays consistent.

The schedule sets the backup frequency and time. For Azure VMs you can back up daily or, with the enhanced policy, multiple times a day, choosing the hour that suits your maintenance window. Each run produces a recovery point — a point-in-time snapshot you can later restore from.

Retention controls how long each recovery point is kept, and it is usually tiered with a grandfather-father-son pattern: keep daily points for a few weeks, weekly points for some months, and monthly or yearly points for long-term compliance. Longer retention means more stored recovery points and more cost, so you balance recovery needs against storage.

For example, a policy might take a backup every day at 2 a.m., keep daily recovery points for 30 days, weekly points for 12 weeks, and monthly points for 12 months. That gives you a month of fine-grained restore choices and a year of coarser ones. On the exam, remember the formula: a backup policy is schedule (how often) plus retention (how long you keep each recovery point).

Azure Backup is the service that creates and manages those recovery points, and it protects several workload types you should recognize. The most common on the exam is the Azure virtual machine: Backup takes snapshots of the VM's disks on the policy schedule, with no agent to install for the standard extension-based VM backup.

Beyond VMs, Azure Backup can protect Azure Files shares (snapshot-based, so you can roll a share back to an earlier point), SQL Server and SAP HANA databases running inside an Azure VM, and on-premises files, folders, and system state through the Microsoft Azure Recovery Services (MARS) agent installed on the machine. The MARS agent is the concept to remember for protecting individual on-premises servers directly to a vault.

All of this data is stored in the vault using the redundancy you selected — geo-redundant storage, for instance, copies your backups to a paired region so they survive a regional storage failure. Because Backup keeps multiple recovery points, it is your defence against accidental deletion, corruption, and ransomware: you restore from a point in time before the problem occurred. On the exam, if a scenario asks how to protect against data loss or to recover a clean copy from before an incident, the answer is Azure Backup and its recovery points.

Backups only matter if you can restore, and Azure Backup gives you several restore granularities for a virtual machine. Understanding the options is a favorite exam theme because the right choice depends on what went wrong.

• Restore an entire VM — create a brand-new virtual machine from a chosen recovery point, useful when the original is lost, corrupted, or hit by ransomware.
• Restore or replace disks — recover the managed disks from a recovery point and swap them onto an existing VM, or create disks you attach yourself, when only the storage is affected.
• File-level recovery — mount a recovery point as a temporary drive and copy back individual files or folders, ideal when a user simply deleted a document.

You choose a recovery point — one of the point-in-time snapshots your policy retained — and Azure restores from it. Recovery points can be restored to the same region or, if the vault uses geo-redundant storage with cross-region restore enabled, to the paired region.

For example, if a single spreadsheet is deleted you use file-level recovery to grab just that file rather than rebuilding the whole machine; if the entire VM is encrypted by ransomware, you restore a full VM from a recovery point taken before the attack. On the exam, match the scope of the problem to the restore type: whole VM, disks, or individual files.

Azure Site Recovery (ASR) is a business continuity and disaster recovery service. Instead of taking periodic recovery points, it continuously replicates a virtual machine's disks to a secondary region, keeping a near-current copy ready to run. Its job is not to recover a deleted file but to keep an entire workload available when a whole region or site becomes unavailable.

You configure replication from the source VM or the vault by choosing a target region, a target resource group and virtual network, and a replication policy that sets how often app-consistent snapshots are taken and how long recovery points are retained. ASR then provisions the needed resources in the target region and streams changes from the source, so the secondary copy stays only seconds to minutes behind.

Because replication is ongoing, Site Recovery achieves a low Recovery Point Objective (RPO) — the amount of data you could lose is small — and a fast Recovery Time Objective (RTO) — you can bring the workload up in the second region quickly. ASR can protect Azure VMs replicating to another Azure region, as well as on-premises VMware and Hyper-V machines replicating into Azure. On the exam, when a scenario needs a workload to keep running in another region during an outage, the service is Azure Site Recovery, not Azure Backup.

Once replication is healthy, you exercise Site Recovery through a failover — bringing the workload up in the secondary region from a chosen recovery point. There are three kinds, and the exam expects you to tell them apart.

A test failover spins the replicated VMs up in an isolated network in the target region without affecting production or stopping replication. It is how you validate your disaster-recovery plan safely, on a schedule, and you clean up the test resources afterward. A planned failover is used when you know an outage is coming — you shut the source down cleanly first, so no data is lost before switching over. An unplanned failover is for a sudden, unexpected outage where the source is already gone; you fail over from the latest available recovery point, accepting whatever small amount of data was not yet replicated.

After the incident passes, a failback returns the workload to the original region. Two terms tie it together: RPO (how much data you can afford to lose, driven by replication frequency) and RTO (how quickly you must be running again, driven by failover speed). On the exam, the phrase test failover always signals Site Recovery, and a non-disruptive validation of your DR plan is exactly what a test failover provides.

This is the single most tested distinction in the domain, so commit it to memory. Azure Backup protects against data loss and corruption — it keeps point-in-time recovery points you restore from after an accidental deletion, a bad change, or ransomware. Azure Site Recovery protects against a region or site outage — it replicates your workload so you can fail over and keep running elsewhere. Backup brings your data back; Site Recovery keeps your service up.

Scenario: A production application on Azure VMs must survive both a fat-fingered deletion and a full regional outage. You enable Azure Backup with a daily policy so you always have recent recovery points to restore individual files or whole machines, and you configure Azure Site Recovery to replicate the same VMs to a second region so you can fail the workload over and keep it running if the primary region goes down. The two services are complementary, not alternatives.

Operating backups at scale means watching them, and Azure centralizes this in Backup center — a single management view across Recovery Services vaults and Backup vaults in your subscription or tenant. From there you can see every protected item, trigger on-demand backups and restores, and check backup jobs to confirm each run succeeded or investigate why one failed.

Backup alerts notify you when something needs attention, such as a failed backup job, a restore failure, or a machine that has stopped backing up. Built-in alerts appear in Backup center, and you can route them through Azure Monitor and an action group so the right people are emailed or paged — the same alerting mechanism used across Azure Monitor. For reporting and trends, Backup reports (built on a Log Analytics workspace) show usage, job history, and policy adherence over time, helping you prove compliance and forecast storage.

For example, you might configure an alert so any failed VM backup emails the operations team the same day, and review a weekly Backup report to confirm every protected VM met its policy. On the exam, remember that Backup center is the unified place to monitor and manage backups, and that backup alerts can flow through Azure Monitor action groups to notify your team.