Azure Backup & Site Recovery Deep Dive: Vaults, Policies, Restore & DR Failover

Two questions decide whether your career survives the worst day in the data centre. How much data can you afford to lose? (your RPO) and how fast must you be back? (your RTO). Azure answers them with two complementary services that learners — and exam writers — constantly confuse. Azure Backup keeps point-in-time copies so you can recover data after deletion, corruption, or ransomware. Azure Site Recovery (ASR) continuously replicates whole machines so you can fail over and keep running when a region, zone, or on-prem site goes dark. Backup is your time machine; Site Recovery is your spare engine. You need both, and an interviewer will probe exactly where one ends and the other begins.

This is the exhaustive lesson. We go setting by setting through the two vault types and the workloads each protects, backup policies down to GFS retention and instant-restore snapshots, the full restore matrix for VMs (whole-machine and file-level), Azure Files and SQL-in-VM, then the hardening controls every production tenant needs — cross-region restore, soft delete, immutable vaults, and multi-user authorization. Then we switch to Site Recovery — replication policies, recovery plans, the A2A and on-prem-to-Azure scenarios, and the critical distinction between test failover, failover, and failback — before pulling the estate together in Backup Center. By the end you can design a backup-and-DR posture from memory and answer the follow-ups AZ-104 and AZ-305 will throw at you.

In a nutshell

Imagine you run a small shop. Azure Backup is the safe-deposit box where you drop a dated photocopy of every ledger each night — and keep last week’s, last quarter’s, and last year’s copies too. If a page gets torn, spilled on, or stolen (deleted, corrupted, or encrypted by ransomware), you walk to the box and fetch a clean older copy. Azure Site Recovery (ASR) is a second, fully-staffed shop across town that mirrors your every move minute-by-minute — so if your building burns down (a region, zone, or on-prem site goes dark) you unlock the other shop and keep serving customers within minutes. Backup is your dated photocopies; Site Recovery is your spare shop. Serious businesses keep both, because a mirror faithfully copies a mistake, and a photocopy can’t serve customers.

Two numbers decide which lever you pull and how hard. RPO (“how many receipts can I afford to lose?”) is set by how often you copy. RTO (“how long can the shutters stay down?”) is set by how fast you can restore or fail over. Backup gives you an RPO of hours and an RTO of a restore; Site Recovery gives you an RPO of seconds-to-minutes and an RTO of minutes.

Level: Intermediate · Time: ~48 min

Before you start: an Azure subscription, one resource group, at least one VM you can protect, and the az CLI (Cloud Shell is fine) — the resource-group and region basics from the Fundamentals and Compute lessons. Every term (RPO, RTO, GFS, vault) is defined below, so you can start cold.

After this you can: tell RPO from RTO in a sentence; pick the right vault (Recovery Services vs Backup) for any workload; back up and restore an Azure VM — including recovering a single file; harden a vault against ransomware with soft delete, immutability, and multi-user authorization; and rehearse a real disaster with a test failover that never touches production.

Learning objectives

• Choose correctly between a Recovery Services vault and a Backup vault, and name which workloads each one protects.
• Author backup policies with the right frequency, GFS retention (daily/weekly/monthly/yearly), and instant-restore snapshot tuning.
• Back up and restore Azure VMs (whole-VM, replace-disks, and file-level recovery), Azure Files (snapshot and vaulted), and SQL Server running in an Azure VM.
• Harden backups against ransomware and rogue admins with cross-region restore, soft delete, immutable vaults, and multi-user authorization (MUA).
• Configure Azure Site Recovery — replication policy, recovery plans, the Azure-to-Azure (A2A) and on-prem-to-Azure scenarios — and run a test failover, a real failover, and a failback, reasoning about RPO and RTO throughout.
• Operate the estate centrally with Backup Center, backup reports, jobs, and alerts.

Prerequisites & where this fits

You need an Azure subscription, a resource group or two, at least one VM you can protect, and the az CLI (Cloud Shell is fine) from the earlier Fundamentals and Compute lessons. This is the Operations deep-dive of the Azure Zero-to-Hero course — it builds directly on the compute and storage deep-dives (Azure Virtual Machines Deep Dive and Azure Managed Disks Deep Dive), because the things you back up here are exactly the VMs, disks, and file shares you created there, and uses the same monitoring pipeline as Azure Monitor Deep Dive for alerts. If “RPO” and “RTO” are brand new, this lesson defines them in full; if you want the ransomware-hardening angle in more depth afterwards, the companion lesson Azure Backup Hardening goes deeper still.

Core concepts

Backup and disaster recovery solve different problems, and the single most important mental model is why two services exist:

• Azure Backup = recover data to a point in time. It periodically copies data into a vault and keeps many historical recovery points (yesterday, last week, last quarter, last year). You use it when something was deleted, encrypted, or corrupted and you need a clean older copy. RPO is hours (one or a few backups a day, or every few hours for in-guest SQL logs); RTO is however long a restore takes.
• Azure Site Recovery = keep the machine running through a disaster. It continuously replicates a VM’s disks to another region (or zone, or to Azure from on-prem) so that within minutes you can boot an identical machine elsewhere. RPO is seconds to a couple of minutes; RTO is minutes. ASR is not a substitute for backup — it replicates corruption and ransomware just as faithfully as good data, and it keeps only a short window of recovery points.

Anchor terms you will see throughout:

• RPO (Recovery Point Objective) — the maximum data loss you can tolerate, measured in time. “RPO = 15 minutes” means you can lose at most the last 15 minutes of changes. Backup frequency and replication continuity set your RPO.
• RTO (Recovery Time Objective) — the maximum time you can be down. Restore speed and failover automation set your RTO.
• GFS (Grandfather-Father-Son) — the retention scheme where short-interval backups roll up into longer-lived ones (daily → weekly → monthly → yearly), so you keep granularity recently and sparse copies for years cheaply.
• Recovery point — a single restorable snapshot/backup taken at a moment in time.
• Instant restore (snapshot tier) — a local managed-disk snapshot taken before data is copied to the vault, giving near-instant restores for recent points without reading from vault storage.
• Vault — the Azure resource that holds backup data and/or replication configuration, governs redundancy, and is the unit for soft delete, immutability, and RBAC.

Recovery Services vault vs Backup vault: every workload

Azure has two vault resource types, and they are not interchangeable. Choosing the wrong one means re-onboarding workloads later, so this is a day-one decision and a guaranteed exam question.

The rule of thumb:

• Recovery Services vault — the classic and broadest vault. Use it for Azure VMs, SQL/SAP-HANA-in-VM, Azure Files (snapshot), on-prem via MARS/MABS/DPM, and all of Azure Site Recovery. If you remember one thing: VMs and ASR live in a Recovery Services vault.
• Backup vault — the newer vault for managed-data-store workloads: Blobs, Disks, PostgreSQL Flexible Server, AKS, and vaulted Azure Files. It introduced the modern data-protection control plane (Microsoft.DataProtection).

Many platform teams run both — that is expected and correct; they are governed the same way for redundancy, soft delete, immutability, and MUA. The seam is purely about which workloads each supports.

Creating a Recovery Services vault: every setting

When you create a Recovery Services vault the portal walks Basics → Networking → Tags → Review + create. After creation, two vault-wide Properties (redundancy and security) are the load-bearing settings.

Storage redundancy controls how durable your backup data is — and you cannot change it once items are protected:

Gotcha: GRS is the default for new vaults, but if you switch a vault to LRS to save money, you permanently forfeit cross-region restore and can’t switch back once items are protected. Decide based on your DR requirement, not the monthly bill.

# Recovery Services vault + redundancy (set redundancy BEFORE any backups)
az group create -n rg-backup-lab -l eastus

az backup vault create \
  --resource-group rg-backup-lab \
  --name rsv-lab-eastus \
  --location eastus

# Geo-redundant + cross-region restore enabled (prerequisite for CRR)
az backup vault backup-properties set \
  --resource-group rg-backup-lab \
  --name rsv-lab-eastus \
  --backup-storage-redundancy GeoRedundant \
  --cross-region-restore-flag true

resource rsv 'Microsoft.RecoveryServices/vaults@2024-04-01' = {
  name: 'rsv-lab-eastus'
  location: 'eastus'
  sku: { name: 'RS0', tier: 'Standard' }
  properties: {}
}

resource rsvConfig 'Microsoft.RecoveryServices/vaults/backupstorageconfig@2024-04-01' = {
  parent: rsv
  name: 'vaultstorageconfig'
  properties: {
    storageModelType: 'GeoRedundant'
    crossRegionRestoreFlag: true
  }
}

Creating a Backup vault

The Backup vault create flow is similar (Basics → Redundancy → Tags → Review + create), but redundancy values are named LocallyRedundant / ZoneRedundant / GeoRedundant, and you choose the soft-delete mode at creation. Use it only for the workloads in the table above.

az dataprotection backup-vault create \
  --resource-group rg-backup-lab \
  --vault-name bvault-lab-eastus \
  --location eastus \
  --storage-settings datastore-type="VaultStore" type="GeoRedundant" \
  --soft-delete-state On --retention-duration-in-days 14

Backup policies: frequency, GFS retention, instant restore

A backup policy answers two questions for a workload: how often do we back up, and how long do we keep each kind of recovery point. The same policy can protect many items.

Schedule (frequency)

GFS retention (Grandfather-Father-Son)

Retention is where GFS lives. You keep frequent points for a short window and progressively sparser points for longer — granular recently, cheap for years:

Gotcha: retention is per recovery point, and reducing retention in a policy shrinks existing points’ lifetimes at the next cleanup — which is exactly the destructive operation immutability and MUA (below) are designed to block. Lengthening retention is always safe.

Instant-restore snapshots

For Azure VMs, Azure Backup first takes a local managed-disk snapshot (the instant restore / snapshot tier), then copies the data into the vault. The snapshot tier gives near-instant restores of recent points (no vault read) and is configurable from 1 to 5 days (default 2).

# Show the default VM policy, then create a custom daily policy from JSON
az backup policy show -g rg-backup-lab -v rsv-lab-eastus -n DefaultPolicy -o json > vmpolicy.json
# (edit vmpolicy.json: schedule time, daily/weekly/monthly/yearly retention,
#  instantRpRetentionRangeInDays 1-5)
az backup policy set -g rg-backup-lab -v rsv-lab-eastus --policy @vmpolicy.json --name DailyGfsPolicy

Backing up & restoring Azure VMs

VM backup is agent-light: enabling protection installs the VM Backup extension (VMSnapshot) which coordinates an application-consistent snapshot (via VSS on Windows / pre-post scripts on Linux), then ships the snapshot to the vault.

Consistency levels (know these for the exam):

Enable and trigger a backup

# Enable VM backup against a policy
az backup protection enable-for-vm \
  --resource-group rg-backup-lab \
  --vault-name rsv-lab-eastus \
  --vm myVm \
  --policy-name DefaultPolicy

# On-demand backup with an explicit retention for this point
az backup protection backup-now \
  --resource-group rg-backup-lab \
  --vault-name rsv-lab-eastus \
  --container-name myVm --item-name myVm \
  --retain-until 15-07-2026 \
  --backup-management-type AzureIaasVM

Restore options for an Azure VM

# Restore disks from the latest recovery point to a staging account
RP=$(az backup recoverypoint list -g rg-backup-lab -v rsv-lab-eastus \
  --container-name myVm --item-name myVm \
  --backup-management-type AzureIaasVM --query "[0].name" -o tsv)

az backup restore restore-disks \
  --resource-group rg-backup-lab --vault-name rsv-lab-eastus \
  --container-name myVm --item-name myVm \
  --rp-name $RP --storage-account mystagingsa \
  --target-resource-group rg-restore-lab

File-level (item-level) recovery — the mechanism

File recovery is exam-favourite because the mechanism is unusual: you download a small executable script from the recovery point, run it on any machine with network line-of-sight, and it mounts the recovery point’s volumes locally over iSCSI. You then copy the files you need with normal file tools and unmount to release the mount.

# Generate the file-restore script + credentials for a recovery point
az backup restore files mount-rp \
  --resource-group rg-backup-lab --vault-name rsv-lab-eastus \
  --container-name myVm --item-name myVm --rp-name $RP
# -> download/run the returned script; it mounts the volumes locally.
# When finished:
az backup restore files unmount-rp \
  --resource-group rg-backup-lab --vault-name rsv-lab-eastus \
  --container-name myVm --item-name myVm --rp-name $RP

Gotcha: the file-restore mount has a 12-hour lifetime and you should always unmount when done — a forgotten mount holds the recovery point open. On Linux you may need the open-iscsi package; on Windows the script needs to run as administrator.

Backing up & restoring Azure Files

Azure Files has two protection tiers:

Snapshot backup is fast and cheap and covers the common “someone deleted the folder” case; vaulted backup is the insurance for storage-account-level loss. Enable Azure Files backup from a Recovery Services vault (snapshot) and/or a Backup vault (vaulted).

# Snapshot-based Azure Files backup via Recovery Services vault
az backup protection enable-for-azurefileshare \
  --resource-group rg-backup-lab --vault-name rsv-lab-eastus \
  --storage-account mystorageacct --azure-file-share myshare \
  --policy-name DefaultPolicy

# Item-level restore of a single folder back to the original share
az backup restore restore-azurefileshare \
  --resource-group rg-backup-lab --vault-name rsv-lab-eastus \
  --container-name "StorageContainer;Storage;rg-backup-lab;mystorageacct" \
  --item-name myshare --rp-name <recovery-point> \
  --restore-mode OriginalLocation --resolve-conflict Overwrite

Backing up & restoring SQL Server in an Azure VM

For SQL running inside an Azure VM, Azure Backup is a workload-aware backup (not the same as VM-level backup). The Azure Backup workload extension runs inside the guest, discovers databases, and performs native SQL backups (Full, Differential, Transaction-log). This gives:

• 15-minute RPO through frequent transaction-log backups.
• Point-in-time restore to any moment within the log chain.
• Auto-protection of new databases on an instance.

# Register the SQL-in-VM instance with the vault, then enable protection
az backup container register \
  --resource-group rg-backup-lab --vault-name rsv-lab-eastus \
  --workload-type MSSQL --backup-management-type AzureWorkload \
  --resource-id $(az vm show -g rg-backup-lab -n sqlvm --query id -o tsv)

Gotcha: SQL-in-VM backup needs the VM to reach the Azure Backup service (network) and a SQL account/permissions for the extension. It backs up databases, so restore targets are databases (overwrite, alternate location, or as files) — not the whole VM. To protect the whole machine and the databases, run both VM backup and SQL backup.

Cross-region restore, soft delete, immutability & MUA

These four controls turn a backup vault from “a copy of your data” into “a copy an attacker or a rogue admin cannot destroy.” This is the ransomware-resilience core of AZ-104/AZ-305.

Cross-region restore (CRR)

CRR lets you restore in the geo-paired region on demand, without waiting for Microsoft to declare a regional outage — invaluable for DR drills and region-down recovery.

• Requires GRS storage redundancy and the Cross Region Restore flag enabled (set both before onboarding).
• Works for Azure VMs, SQL/SAP-HANA-in-VM, and selected Backup-vault workloads.
• You restore from the secondary region recovery points to resources in that region.

Soft delete

Soft delete keeps deleted backup data recoverable for a retention window even after someone stops protection and deletes backups — defeating the classic “delete the backups, then encrypt” ransomware play.

# Inspect / set soft delete on a Recovery Services vault
az backup vault backup-properties show -g rg-backup-lab -n rsv-lab-eastus \
  --query "{soft:softDeleteFeatureState}"
az backup vault backup-properties set -g rg-backup-lab -n rsv-lab-eastus \
  --soft-delete-feature-state Enable

Immutable vault

Immutability blocks operations that would reduce protection of existing recovery points — deleting data before retention expires, shortening retention, or disabling soft delete. It does not block creating new backups or extending retention.

Gotcha: lock immutability only after a soak period. Once locked it is permanent for the life of the vault; if a policy genuinely needs shorter retention later, you cannot shorten it.

Multi-user authorization (MUA)

MUA puts destructive operations behind a second person’s approval using a Resource Guard — typically owned in a different subscription/tenant so the backup admin alone cannot both request and approve. Protected operations (disable soft delete, reduce retention, delete a protected item, disable MUA itself) require a Just-In-Time approval against the Resource Guard before they proceed.

The defence-in-depth order to enable these is: soft delete → cross-region restore → immutability (unlocked, then locked after soak) → MUA.

Azure Site Recovery: replication, plans & failover

Switch gears: Azure Site Recovery (ASR) continuously replicates whole machines so you can fail over and keep running. ASR config lives in a Recovery Services vault.

Scenarios

Replication policy (the RPO/retention knobs)

A replication policy controls how recovery points are generated and kept:

ASR keeps only a short window (hours) of recovery points — it is not a backup. Use Azure Backup for long-term/point-in-time data recovery and ASR for keeping the machine running.

Recovery plans

A recovery plan orchestrates the failover of many VMs into an ordered, repeatable runbook:

• Groups and ordering — boot tier-1 (DB) before tier-2 (app) before tier-3 (web).
• Manual actions — pause for an operator step (e.g. validate DNS).
• Automation runbooks (Azure Automation) — script post-failover tasks (reassign public IPs, update DNS, open NSGs).

A recovery plan is what turns “fail over 30 VMs” from a frantic afternoon into one button with predictable ordering.

Test failover vs failover vs failback

This three-way distinction is the single most-asked ASR exam question:

The full lifecycle is: enable replication → (let it reach a healthy RPO) → test failover (drill) → [disaster] → failover → commit → reprotect (reverse replication) → failback → re-enable original-direction replication.

# A2A is most reliably scripted via PowerShell/templates; the az CLI surface
# is limited. Validate replication health for a protected item:
az site-recovery replication-protected-item show \
  --resource-group rg-asr --vault-name rsv-asr \
  --fabric-name <primary-fabric> --protection-container-name <pc> \
  --replicated-protected-item-name myVm-asr \
  --query "{state:properties.protectionState, rpo:properties.providerSpecificDetails}"

Gotcha: A2A is most robustly configured via the portal, ARM/Bicep, or Az.RecoveryServices PowerShell; the az CLI coverage for ASR is partial. For exam answers, know the concepts and order; for production, drive ASR from templates/PowerShell and rehearse with test failover on a schedule.

Backup Center, reports & alerts

As the estate grows you stop managing vault-by-vault and move to Backup Center — a single pane across all vaults, subscriptions, and workload types:

• Overview & Backup instances — every protected item and its last-backup health in one list.
• Jobs — every backup/restore job, success/failure, durations (also az backup job list).
• Policies — author and govern policies centrally; spot items on weak policies.
• Backup reports — a Log-Analytics-backed workbook for storage consumed, retention, job trends, and optimization (e.g. items with excessive retention). Requires routing vault diagnostic settings to a Log Analytics workspace.
• Alerts — built-in Azure Monitor alerts for backup failures and security events (e.g. disable-soft-delete), surfaced via action groups to email/SMS/webhook/ITSM. Wire these to the same action groups you built in the Azure Monitor Deep Dive.

# Recent backup jobs across a vault (the Backup Center "Jobs" view, in CLI)
az backup job list -g rg-backup-lab -v rsv-lab-eastus \
  --query "[].{op:operation, status:status, start:startTime}" -o table

# Route vault diagnostics to Log Analytics so Backup Reports populate
az monitor diagnostic-settings create \
  --name to-law \
  --resource $(az backup vault show -g rg-backup-lab -n rsv-lab-eastus --query id -o tsv) \
  --workspace <log-analytics-workspace-id> \
  --logs '[{"categoryGroup":"allLogs","enabled":true}]'

The diagram above ties the whole picture together: one Recovery Services vault feeding both the recover-data path (Backup, hardened by soft delete, immutability, and MUA) and the keep-running path (Site Recovery replication with its failover lifecycle), unified under Backup Center.

Hands-on lab

Enable backup on a small VM, take an on-demand backup, perform a file-level restore, then clean everything up. All az CLI; the only billable pieces are tiny and removed at the end.

1. Resource group, vault, and a small VM

LOC=eastus
RG=rg-backup-lab
az group create -n $RG -l $LOC

# Recovery Services vault (LRS for the lab to minimise cost)
az backup vault create -g $RG -n rsv-lab-eastus -l $LOC
az backup vault backup-properties set -g $RG -n rsv-lab-eastus \
  --backup-storage-redundancy LocallyRedundant

# Tiny Linux VM to protect
az vm create -g $RG -n bkpVm -l $LOC \
  --image Ubuntu2204 --size Standard_B1s \
  --admin-username azureuser --generate-ssh-keys

2. Enable backup and trigger an on-demand backup

az backup protection enable-for-vm \
  -g $RG -v rsv-lab-eastus --vm bkpVm --policy-name DefaultPolicy

# On-demand backup, retained ~30 days from today
az backup protection backup-now \
  -g $RG -v rsv-lab-eastus \
  --container-name bkpVm --item-name bkpVm \
  --backup-management-type AzureIaasVM \
  --retain-until $(date -v+30d +%d-%m-%Y 2>/dev/null || date -d "+30 days" +%d-%m-%Y)

3. Verify the job and list recovery points

# Wait for the backup job to complete (Status -> Completed)
az backup job list -g $RG -v rsv-lab-eastus -o table

# List recovery points and capture the newest
RP=$(az backup recoverypoint list -g $RG -v rsv-lab-eastus \
  --container-name bkpVm --item-name bkpVm \
  --backup-management-type AzureIaasVM --query "[0].name" -o tsv)
echo "Recovery point: $RP"

Expected: a Backup job with Status = Completed, and $RP populated with a recovery-point name.

4. File-level restore (mount the recovery point)

# Generate the file-restore script + iSCSI credentials
az backup restore files mount-rp \
  -g $RG -v rsv-lab-eastus \
  --container-name bkpVm --item-name bkpVm --rp-name $RP

Run the returned script on a machine with network access (it mounts the recovery point’s volumes locally over iSCSI). Browse the mounted volume, copy any file you need, then release the mount:

az backup restore files unmount-rp \
  -g $RG -v rsv-lab-eastus \
  --container-name bkpVm --item-name bkpVm --rp-name $RP

Read the result: you recovered individual files without restoring the whole VM — the everyday “I deleted one file” scenario, and a classic exam question.

Cleanup

# Stop protection AND delete backup data, then remove the RG
az backup protection disable -g $RG -v rsv-lab-eastus \
  --container-name bkpVm --item-name bkpVm \
  --backup-management-type AzureIaasVM --delete-backup-data true --yes

az group delete -n $RG --yes --no-wait

If az group delete fails because the vault “contains backup items,” it’s because soft delete is holding deleted data. Undo/disable soft delete or wait out the soft-delete window, then delete — this is the soft-delete safety net doing its job.

Cost note

The vault and policies are free to define; you pay for protected-instance fees (per backed-up instance, by source size band) plus backup storage consumed (LRS in this lab). A single tiny B1s VM with one on-demand backup for an hour is a few rupees of storage plus a small instance fee — round to ₹5–₹30 if cleaned up promptly. The genuinely expensive accidents are GRS storage on large VMs with long retention and forgotten ASR replication (which bills continuously per replicated VM plus target-region storage). Always disable protection with --delete-backup-data and az group delete your labs.

Common mistakes & troubleshooting

Best practices

• Pick the vault redundancy and CRR on day zero. GRS + cross-region restore for anything you’d need after a region outage — you cannot change redundancy once items are protected.
• Use GFS deliberately. Short daily retention for granularity, plus weekly/monthly/yearly only as compliance requires — over-long retention quietly dominates the bill.
• Match RPO to the workload. Daily VM backup for stateless tiers; Enhanced/hourly or SQL log backups (15-min RPO) for transactional data; ASR for “must keep running.”
• Back up the machine and the database. VM backup plus SQL-in-VM backup gives both whole-machine recovery and point-in-time database restore.
• Harden in order: soft delete → CRR → immutability (soak, then lock) → MUA. Treat the backup control plane as the highest-value ransomware target.
• Rehearse with test failover on a schedule. A DR plan you’ve never run is a hypothesis; isolated test failovers prove RTO without touching production.
• Centralize in Backup Center with diagnostics to Log Analytics so reports populate and you catch unprotected/weakly-protected items.
• Don’t treat ASR as backup. It replicates corruption too and keeps only hours of points — keep Azure Backup for long-term/point-in-time recovery.

Security notes

• Enable enhanced soft delete (always-on) so deleted backups survive an admin compromise — the core anti-ransomware control.
• Lock immutability on production vaults after a soak period; it stops retention-shortening and early deletion even by Microsoft.
• Turn on multi-user authorization (MUA) with a Resource Guard owned in a separate subscription/tenant so no single admin can both request and approve destructive operations.
• Scope RBAC tightly. Backup Contributor / Backup Operator are powerful — separate who can configure backups from who can delete them, and audit changes.
• Use private endpoints on the vault to keep the backup data plane off the public internet.
• Encrypt backups with customer-managed keys (CMK) where compliance requires control of the key; platform-managed keys protect data at rest by default.
• Alert on security events (disable-soft-delete, MUA changes) via action groups — early warning of a control-plane attack.

Cost & sizing

The levers that move a backup/DR bill, roughly in order of impact:

Sizing rules of thumb: redundancy and retention are the big multipliers — GRS on large VMs with multi-year retention is where surprise bills come from. Right-size GFS to the actual compliance need, keep the snapshot tier at the default 2 days unless you need faster recent restores, and never leave ASR replication running on machines you no longer need to protect — it’s the most common forgotten recurring charge in this space.

Going deeper

The sections above teach the what. This one is for the engineer who has to run backup and DR at scale, pass AZ-305, and defend the design in a review. It goes under the hood — data movement, identity, RBAC, and the edges that only show up in production.

How a VM backup actually moves: snapshot phase, then transfer phase

Enabling VM protection installs the VM Backup extension (VMSnapshot on Windows, VMSnapshotLinux on Linux). A backup then runs in two phases, and understanding the split explains most of the cost and timing behaviour:

1. Snapshot phase. Azure takes a managed-disk snapshot of every included disk and stores it in a resource group in your own subscription named AzureBackupRG_<geo>_<n>. This is the instant-restore tier — recent points restore from here without ever touching vault storage, which is why the snapshot-retention knob (1–5 days) is a managed-disk storage cost, not a vault cost. The snapshot phase is what makes the point “available” quickly; the job shows the snapshot completing well before the transfer does.
2. Transfer phase. Changed blocks are copied from the snapshot into the vault as incremental-forever data — the first backup is a full and is the slowest; every later backup ships only what changed since the last recovery point. There is no periodic re-full, so vault storage tracks churn, not calendar time.

Two practical levers fall out of this model. Selective disk backup lets you exclude scratch/data disks you don’t need to protect (fewer blocks, lower cost), and it is set at enable time:

# Protect the OS disk (always included) + data disks at LUN 0 and 1; skip the rest
az backup protection enable-for-vm \
  -g rg-backup-lab -v rsv-lab-eastus --vm myVm \
  --policy-name DailyGfsPolicy \
  --disk-list-setting include --diskslist 0 1

And because the snapshot phase writes into your subscription, a VM with many large, high-churn disks needs the Enhanced policy (it raises the supported per-day data-change ceiling that the older Standard policy could choke on).

Vault identity, encryption, and private networking

Backup data is encrypted at rest with platform-managed keys by default. For regulated workloads you switch a Recovery Services vault to a customer-managed key (CMK): the vault authenticates to Key Vault through a managed identity (system- or user-assigned) that holds get/wrapKey/unwrapKey, and you can layer infrastructure encryption for a second, platform-held layer (double encryption at rest). Two edges bite people here:

• CMK is close to a day-zero choice. Enabling it and enabling infrastructure encryption is far cleaner on an empty vault; the key’s Key Vault needs soft delete + purge protection, or you risk locking yourself out of your own backups.
• CMK and cross-region restore must agree. When you restore in the paired region, the key has to be reachable there too — plan key availability/replication before you rely on CRR with CMK.

For the network plane, a Private Endpoint on the vault keeps backup and restore traffic off the public internet. Note the nuance: the private endpoint covers the backup data flow for Azure VM and in-guest workloads, but MARS-agent and some management calls still resolve Azure dependencies — validate the full dependency list before declaring the vault “fully private.”

RBAC: separate who configures backups from who can delete them

“Scope RBAC tightly” is easy to say; the exam and a real review want the role names. The split that matters is configure/operate vs destroy:

The trap: Backup Contributor is powerful — it can stop protection and delete data. Hand out Backup Operator for routine work and reserve deletion power for a small group, then gate that group with MUA (below). This is the identity half of ransomware resilience.

Multi-user authorization internals: Resource Guard, roles, and the legacy PIN

MUA is more than “a second approver.” Mechanically it inserts a Resource Guard — a real Azure resource, ideally in a different subscription and tenant — in front of protected operations (disable soft delete, reduce retention, delete a protected item, disable MUA). The role model enforces separation of duties:

• The security admin owns the guard with Backup MUA Admin and does not have day-to-day backup rights.
• The backup admin is granted Backup MUA Operator on the guard — but only just-in-time, typically via PIM elevation with an approval, so standing access is zero. Cross-tenant guards are wired with Azure Lighthouse.

The older control you may still meet is the Security PIN: a portal-generated PIN required for critical operations when a vault’s security features were enabled. It protects a single operator’s mistake but not a compromised admin; MUA supersedes it because the approver is a different identity in a different blast radius.

Beyond VMs: how Blob, Disk, and AKS backup really work

The vault table earlier says which vault protects Blobs, Disks, and AKS; here is how, because the mechanisms differ sharply from VM backup:

The two mental hooks: operational backup keeps data local for speed and cheap PITR (and protects against edits/deletes, not account loss), while vaulted backup pays to move data off the source so it survives losing the account itself. That is the same “snapshot tier vs vaulted tier” split you saw for Azure Files, generalised across the Backup vault.

Azure Site Recovery under the hood

A2A is “agentless” only in the sense that you don’t hand-install anything: ASR pushes the Mobility service extension into the VM, which tracks disk writes and ships them to a cache (log) storage account in the source region. That cache account matters — it buffers replication before the data reaches the target, so an undersized or throttled cache shows up as replication lag / high RPO. Replication runs in two stages: initial replication (seed every disk) then continuous delta replication.

When you actually fail over, you choose which recovery point to boot — this is a frequently-missed exam nuance:

After a real failover you reprotect (reverse replication — a cache account now forms in the new source region), and failback is simply a failover in the reverse direction followed by a commit. Two scale edges: ASR enforces documented per-disk / per-VM churn limits (on the order of tens of MB/s per disk) — a very high-write disk may be unsupported and will trip RPO alerts — and the target region must have capacity at failover. For tier-1 DR, back the target with capacity reservations so a regional surge can’t starve your recovery.

Scale, quotas, and the cost edges that surprise people

• Vault fan-out. A single vault has datasource limits (on the order of a couple of thousand protected VMs) and there are per-subscription vault limits; large estates shard across vaults and regions rather than piling everything into one. Confirm current numbers against Azure’s published subscription limits before you design.
• Schedule ceilings. A Standard VM policy is one backup/day; Enhanced allows multiple per day (every 4–12 h). SQL-in-VM log backups reach every 15 minutes. On-demand backups are always available on top.
• Archive tier for long retention. Years-long GFS is the quiet budget killer. Moving eligible recovery points (Azure VM, SQL/SAP-HANA-in-VM) to the Archive tier cuts long-term cost sharply — but points must meet eligibility rules, and archived points carry an early-deletion / minimum-stay charge, so archive only what genuinely needs multi-year retention.

# Move an eligible recovery point to the archive tier (illustrative)
az backup recoverypoint move \
  -g rg-backup-lab -v rsv-lab-eastus \
  --container-name myVm --item-name myVm --rp-name $RP \
  --source-tier VaultStandard --destination-tier VaultArchive \
  --backup-management-type AzureIaasVM

• Restore flexibility. Beyond cross-region restore, cross-subscription restore (CSR) and cross-zone restore let you land a recovery point in a different subscription or a chosen zone — useful for rebuilding into a clean subscription after a compromise. For predictable large estates, backup storage reservations trade commitment for a lower per-GB rate.

Practice challenges

Work these in order — they climb from “read a scenario” to “design a multi-tier DR.” Each has a worked solution; try it before you open the toggle. Commands are illustrative (no live run assumed); every ID is a placeholder.

1. (Beginner) Name the RPO and the RTO. A team says: “We can lose at most 15 minutes of orders, and we must be serving customers again within 30 minutes of an outage.” Which number is the RPO, which is the RTO, and which service (Backup or ASR) primarily sets each?

<details><summary>Solution</summary>

RPO = 15 minutes (maximum data loss) — set by backup/replication frequency. RTO = 30 minutes (maximum downtime) — set by restore/failover speed. A 15-minute RPO with a 30-minute RTO points at Azure Site Recovery (continuous replication, minute-scale RPO/RTO); pure daily Azure Backup could not meet a 15-minute RPO.

Why: RPO/RTO are the two requirements every BCDR design starts from — mislabel them and you pick the wrong service. </details>

2. (Beginner) Pick the vault for each workload. Assign the correct vault type to: (a) an Azure VM, (b) Azure Blobs, © an AKS cluster, (d) Azure Site Recovery replication.

<details><summary>Solution</summary>

(a) Azure VM → Recovery Services vault. (b) Blobs → Backup vault. © AKS → Backup vault. (d) ASR → Recovery Services vault. Memory hook: VMs and ASR live in a Recovery Services vault; the modern managed-data-store workloads (Blob, Disk, AKS, PostgreSQL Flex) live in a Backup vault.

Why: Choosing the wrong vault type means re-onboarding the workload later — this is a day-one, exam-favourite decision. </details>

3. (Intermediate) Create a DR-ready vault. Write the CLI to create a Recovery Services vault, set it to GRS, and enable cross-region restore — in the right order — then confirm the redundancy.

<details><summary>Solution</summary>

az backup vault create -g rg-backup-lab -n rsv-prod-eastus -l eastus
az backup vault backup-properties set -g rg-backup-lab -n rsv-prod-eastus \
  --backup-storage-redundancy GeoRedundant --cross-region-restore-flag true
az backup vault backup-properties show -g rg-backup-lab -n rsv-prod-eastus \
  --query "{redundancy:storageModelType, crr:crossRegionRestoreFlag}"

Do this before onboarding any item — redundancy is fixed once protected items exist.

Why: GRS + the CRR flag are the two prerequisites for restoring in the paired region; set after onboarding, they can’t be applied. </details>

4. (Intermediate) Author a GFS policy. Design a daily VM policy that keeps 30 daily / 12 weekly / 12 monthly / 7 yearly points with a 3-day instant-restore window, and enable it on a VM. Outline the steps.

<details><summary>Solution</summary>

Export the default policy, edit the retention and instantRpRetentionRangeInDays, re-import, then enable:

az backup policy show -g rg-backup-lab -v rsv-prod-eastus -n DefaultPolicy -o json > pol.json
# edit pol.json: daily=30, weekly=12, monthly=12, yearly=7, instantRpRetentionRangeInDays=3
az backup policy set -g rg-backup-lab -v rsv-prod-eastus --name GfsProd --policy @pol.json
az backup protection enable-for-vm -g rg-backup-lab -v rsv-prod-eastus \
  --vm myVm --policy-name GfsProd

Why: GFS keeps granularity recent and compliance points cheap — and instant-restore days are managed-disk cost, so 3 (not 5) unless you need faster recent restores. </details>

5. (Advanced) Design the ransomware-hardening stack and prove it blocks. State the order to enable the four controls, and for each name one destructive operation it stops. Then predict what happens when a compromised backup admin tries to shorten retention on an immutability-locked, MUA-protected vault.

<details><summary>Solution</summary>

Order: soft delete → cross-region restore → immutability (soak unlocked, then lock) → MUA.

• Soft delete — recovers backups an attacker deleted after stopping protection.
• CRR — gives an out-of-region copy if the primary region is lost.
• Immutable vault (locked) — blocks shortening retention and early deletion of existing points, irreversibly.
• MUA (Resource Guard) — gates disable-soft-delete / reduce-retention / delete-item / disable-MUA behind a second identity.

The compromised admin’s “shorten retention” call is rejected twice: locked immutability refuses the retention reduction outright, and even an unlocked op would need Backup MUA Operator approval on the Resource Guard (which they don’t hold standing). The recovery points survive.

Why: Defence-in-depth assumes the admin account itself is the attacker — each layer removes a different single point of failure. </details>

6. (Advanced) Design A2A DR for a 3-tier app. A web → app → SQL stack in East US must fail over to West US as a consistent unit, boot in the right order, and be rehearsable. Specify the ASR features you’d use and the failover recovery-point choice, then how you’d validate without downtime.

<details><summary>Solution</summary>

• Multi-VM consistency group across the interdependent tiers so they share a single crash/app-consistent recovery point (fail over to the same moment).
• A recovery plan with ordered groups — boot SQL (tier-1) → app (tier-2) → web (tier-3) — plus a manual action or Automation runbook to reassign public IPs / update DNS after boot.
• Choose the Latest (lowest RPO) recovery point at failover for least data loss (accepting slightly longer RTO), or Latest app-consistent if the app needs a clean VSS point.
• Validate with a test failover into an isolated VNet on a schedule — zero production impact — and back the target region with a capacity reservation so a regional surge can’t starve the real failover.

Why: Ordering + multi-VM consistency turn “fail over 3 machines” into one predictable, rehearsed button — and a test failover proves the RTO without betting production on an untested plan. </details>

Common beginner mistakes

These are misconceptions, not symptoms — the wrong mental model that leads to a bad design. (For symptom → cause → fix, see the troubleshooting table above.)

“Site Recovery is my backup.” Reality: ASR replicates everything faithfully — including corruption, an accidental delete, and ransomware — and keeps only a short window (hours) of recovery points. It keeps the machine running; it does not give you a clean copy from last Tuesday. Right model: ASR for keep-running, Azure Backup for recover-data. You need both.

“I’ll pick a cheaper redundancy now and switch to GRS later.” Reality: vault storage redundancy is locked once any item is protected. There is no “upgrade to GRS later” — you’d create a new vault and re-onboard everything. Right model: decide LRS/ZRS/GRS and the cross-region-restore flag on day zero, driven by your DR requirement, not the first month’s bill.

“Backups sit in the vault, so ransomware can’t reach them.” Reality: the classic attack is stop protection, delete the backups, then encrypt production. A backup admin (or a stolen admin token) can do exactly that. Right model: the backup control plane is the highest-value target — enable soft delete, immutability, and MUA so deletion is recoverable, retention can’t be shortened, and destructive ops need a second identity.

“A test failover will briefly take production down.” Reality: a test failover spins the replica up in an isolated network with zero impact on the source — production keeps running and replicating. Right model: run test failovers often; the disruptive operation is a real failover, not a drill.

“One VM backup also protects my databases for point-in-time restore.” Reality: VM-level backup captures a crash/app-consistent image of the whole machine on a daily-ish cadence — it is not a 15-minute-RPO, point-in-time database restore. Right model: run VM backup and SQL-in-VM (workload-aware) backup — the machine from one, transaction-log PITR from the other.

“Shortening retention is harmless cleanup; long retention is the risky setting.” Reality: it’s the opposite. Extending retention is always safe; reducing it destroys existing recovery points at the next cleanup — which is precisely the operation immutability and MUA are built to block. Right model: treat retention reduction as a destructive, gated action.

“A vault can back up a VM in another region.” Reality: a Recovery Services vault protects resources in its own region — a VM in East US cannot be backed up to a vault in West US. Right model: one vault per region per environment, co-located with what it protects (cross-region recovery comes from GRS + CRR, not from a remote vault).

“Enhanced vs Standard policy is just a naming choice.” Reality: the Enhanced policy is required for Trusted Launch / Gen2 / Ultra-disk VMs and for multiple backups per day — and you cannot downgrade Enhanced → Standard on an already-protected item. Right model: choose Enhanced when the VM type or a sub-daily RPO demands it, up front.

Interview & exam questions

1. What’s the difference between Azure Backup and Azure Site Recovery? Backup keeps point-in-time copies so you can recover data after deletion/corruption/ransomware (RPO hours, many historical points). Site Recovery continuously replicates whole machines so you can fail over and keep running (RPO seconds-minutes, short retention). Backup is a time machine; ASR is a spare engine. You use both.

2. When do you use a Recovery Services vault vs a Backup vault? Recovery Services vault for Azure VMs, SQL/SAP-HANA-in-VM, Azure Files (snapshot), on-prem (MARS/MABS/DPM), and all of ASR. Backup vault for Blobs, Disks, PostgreSQL Flexible Server, AKS, and vaulted Azure Files. VMs and ASR ⇒ Recovery Services vault.

3. Explain GFS retention. Grandfather-Father-Son: keep daily points for a short window, roll up to weekly, monthly, and yearly (up to 99 years). Granular recently, sparse and cheap for long-term compliance.

4. What is instant restore / the snapshot tier? A local managed-disk snapshot taken before data is copied to the vault, giving near-instant restores of recent points without reading vault storage. Configurable 1–5 days (default 2); more days = more snapshot storage cost.

5. What are the consistency levels for VM backup, and which is best? Application-consistent (VSS/pre-post scripts flush app buffers — best), file-system-consistent (on-disk files consistent), crash-consistent (like pulling the power). Aim for application-consistent on running VMs.

6. How does file-level (item-level) restore work for an Azure VM? You download a script from the recovery point and run it; it mounts the recovery point’s volumes locally over iSCSI. You copy the files you need, then unmount. The mount has a ~12-hour lifetime.

7. How do you achieve a 15-minute RPO for SQL running in an Azure VM? Use SQL-in-VM (workload-aware) backup with transaction-log backups every 15 minutes, on top of Full + Differential — enabling point-in-time restore within the log chain.

8. What’s required for cross-region restore, and why would you use it? GRS redundancy and the Cross Region Restore flag, set before onboarding. It lets you restore in the paired region on demand — for DR drills or a region outage — without waiting for Microsoft to declare an outage.

9. How do the four ransomware controls fit together, and in what order? Soft delete keeps deleted backups recoverable; cross-region restore gives an out-of-region copy; immutable vault blocks retention-shortening/early-deletion; MUA (Resource Guard) gates destructive ops behind a second approver. Enable soft delete → CRR → immutability (soak then lock) → MUA.

10. What is the difference between an unlocked and a locked immutable vault? Unlocked: immutability is active but a vault admin can disable it (use as a soak period). Locked: irreversible — not even Microsoft can unlock it; retention can only be extended, never shortened.

11. Test failover vs failover vs failback — what’s the difference? Test failover spins the replica up in an isolated network with no impact on production (your DR drill). Failover brings the machines up in the target region for real during a disaster. Failback reverse-replicates and returns to the original site once it’s healthy.

12. What does a recovery plan add over failing over VMs individually, and what is multi-VM consistency? A recovery plan orders failover into groups (e.g. DB before app before web), adds manual actions and automation runbooks. Multi-VM consistency groups interdependent VMs so they share the same recovery point — essential for multi-tier apps that must come back to the same moment.

13. Why is ASR not a substitute for backup? ASR replicates everything faithfully — including corruption and ransomware — and keeps only a short window of recovery points (hours). For clean, long-term, point-in-time recovery you need Azure Backup.

Quick check

1. Which vault type backs up Azure VMs and hosts Azure Site Recovery?
2. What two things must be true for cross-region restore to work?
3. What is the default (and max) instant-restore snapshot retention?
4. Which backup type gives SQL-in-VM a 15-minute RPO?
5. True or false: a test failover briefly takes your production VM offline.

Answers

1. The Recovery Services vault (Microsoft.RecoveryServices/vaults).
2. GRS storage redundancy and the Cross Region Restore flag enabled — both set before onboarding.
3. Default 2 days, maximum 5 days.
4. Transaction-log backups every 15 minutes (workload-aware SQL-in-VM backup).
5. False — a test failover runs in an isolated network with no impact on production; it’s the non-disruptive DR drill.

Exercise

Design and build (in CLI) a hardened single-VM backup: create a GRS Recovery Services vault with the cross-region-restore flag enabled and enhanced soft delete on, protect one B-series VM with a custom policy (daily schedule, 14-day daily / 6-week weekly / 12-month monthly retention, instant-restore = 3 days), and trigger an on-demand backup. Then prove two things: (a) attempt to shorten retention or delete a recovery point and observe what soft delete / immutability would gate, and (b) confirm in az backup recoverypoint list that your point exists. Write one short paragraph explaining why you’d enable MUA with a Resource Guard in a separate subscription before considering this production-ready, and what destructive operation it would block. Clean up with az backup protection disable --delete-backup-data true then az group delete.

Certification mapping

Glossary

• Azure Backup — Service that takes and retains point-in-time copies of data for recovery after loss/corruption.
• Azure Site Recovery (ASR) — Service that continuously replicates whole machines to enable failover/DR.
• Recovery Services vault — Vault (Microsoft.RecoveryServices) for VMs, SQL/SAP-HANA-in-VM, Azure Files, on-prem, and ASR.
• Backup vault — Vault (Microsoft.DataProtection) for Blobs, Disks, PostgreSQL Flexible Server, AKS, vaulted Files.
• RPO (Recovery Point Objective) — Maximum tolerable data loss, measured in time.
• RTO (Recovery Time Objective) — Maximum tolerable downtime.
• GFS (Grandfather-Father-Son) — Retention rolling daily→weekly→monthly→yearly points.
• Recovery point — A single restorable snapshot/backup at a moment in time.
• Instant restore (snapshot tier) — Local managed-disk snapshot for near-instant recent restores (1–5 days, default 2).
• Application-consistent backup — Backup with app buffers flushed via VSS/pre-post scripts (best consistency).
• Cross-region restore (CRR) — On-demand restore in the geo-paired region; needs GRS + the CRR flag.
• Soft delete — Retention of deleted backup data (basic 14 days; enhanced 14–180, can be always-on).
• Immutable vault — Vault that blocks retention-reducing/early-deletion operations; can be locked (irreversible).
• Multi-user authorization (MUA) — Destructive operations gated by a second approver via a Resource Guard.
• Replication policy — ASR settings for recovery-point retention, app-consistent frequency, RPO threshold, multi-VM consistency.
• Recovery plan — Ordered ASR runbook grouping VMs with manual actions and automation.
• Test failover — Non-disruptive ASR drill in an isolated network.
• Failover / Failback — Real switch to the target region, and the reverse-replication return to the source.
• Backup Center — Single-pane management across all vaults, workloads, jobs, policies, reports, and alerts.
• Incremental-forever — After the first full backup, Azure Backup transfers only changed blocks on every subsequent run; there is no periodic re-full, so storage grows with churn, not with time.
• Instant-restore snapshot RG — The resource group in your subscription (named AzureBackupRG_<geo>_<n>) where the local managed-disk snapshots for the instant-restore tier are held before/while data copies to the vault.
• Selective disk backup — A VM-backup option to include or exclude specific data disks (by LUN) so throwaway or scratch disks are not backed up or restored.
• Customer-managed key (CMK) — Encryption of backup data at rest with a key you hold in Key Vault (instead of the platform-managed key); the vault reads the key via a managed identity. Infrastructure encryption adds a second, platform-managed layer (double encryption).
• Resource Guard — A standalone Azure resource, ideally in a separate subscription/tenant, that multi-user authorization places in front of destructive backup operations; the backup admin must clear it to proceed.
• Security PIN — The older per-operation control that required a portal-generated PIN for critical actions (stop-protection-with-delete, disable soft delete); superseded by MUA for real separation of duties.
• Mobility service — The ASR replication agent (auto-installed for A2A) that tracks and ships disk writes from a protected machine to the target region.
• Cache / log storage account — A storage account in the source region that buffers ASR replication logs before they are sent to the target region; its throughput affects replication health.
• Reprotect — After a failover, reversing the replication direction (source ⇄ target) so you can later fail back to the original site.
• Operational vs vaulted backup — Operational backup keeps recovery data local to the source (no copy leaves the account/region) for fast point-in-time restore; vaulted backup copies data off into the vault to survive loss of the source account/region.
• Archive tier — A low-cost storage tier for long-retention recovery points (Azure VM, SQL/SAP-HANA-in-VM); recovery points must meet eligibility rules and carry an early-deletion minimum-stay charge.
• Cross-subscription / cross-zone restore — Restoring a recovery point into a different subscription (CSR) or a chosen availability zone, complementing cross-region restore (CRR).
• Trusted Access — The vault-to-cluster authorization AKS backup requires so the Backup Extension in the cluster can snapshot persistent volumes and capture cluster resources.

Next steps

• Microsoft Entra ID & Governance Admin Deep Dive — the natural sequel: lock down who can configure and delete backups with RBAC, policy, locks, and tags across the management-group hierarchy.
• Azure Backup Hardening: Immutable Vaults, MUA, Soft Delete & Cross-Region Restore — go deeper on the four ransomware controls and the exact order to wire them.
• Azure Site Recovery: Zone-to-Zone & Region Failover with Runbooks — the advanced ASR playbook: zone-to-zone DR, recovery-plan automation, and failover runbooks.
• Azure Monitor Deep Dive — wire backup and DR alerts into action groups and dashboards for end-to-end operational visibility.