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.

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.

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.

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.