Recommend a Backup and Recovery Solution for Compute — Lesson

A small bank wakes up Tuesday morning to find half its transaction-processing VMs crippled by ransomware. The incident commander asks the architect three questions in rapid succession: what can we restore, how recent is it, and how long will recovery take. The answer is not in the runbook on her screen — it was decided eighteen months ago, when somebody chose a vault redundancy, set a backup policy, and either did or did not enable soft-delete. This lesson is about making those upstream decisions deliberately so that downstream incidents have one obvious path through them.

We will work through Azure's compute backup story as the AZ-305 exam expects you to: distinguishing Azure Backup from disaster-recovery siblings, choosing between three backup paths (VM-native, MARS, MABS), and configuring a Recovery Services Vault that survives both human error and adversarial action. Reference: the AZ-305 exam study guide, particularly the modules on backup, recovery, and Recovery Services Vault design.

Why This Matters

Compute is rarely the data, but compute hosts the apps that produce the data. When VMs vanish — corruption, ransomware, accidental tenant cleanup, region failure — restoring them quickly is the difference between a one-day incident and a multi-week recovery that ends up in the press. Backup design is also exam-favourite territory because it forces you to integrate three loose ends at once: storage redundancy choices, RBAC and security posture, and recovery objectives expressed as RPO and RTO. If you can confidently pick LRS vs GRS for a vault, recommend Multi-User Authorization for a tier-1 workload, and explain when application-consistency matters, you will pass this slice of the exam and design backup like a senior architect.

The career payoff is more concrete than "reliability theatre." Many AZ-305 candidates report this LO as their highest-confidence design conversation in customer interviews — backup is one of the few topics where the architect's recommendation is immediately auditable and operationally testable.

Prerequisites

Before you continue, make sure you can answer each of the following without looking up:

• ARM resource model (subscriptions, resource groups, locations) — Self-check: at which scope is a Recovery Services Vault created, and can you move it to another subscription after items are protected?
• Storage redundancy options (LRS, ZRS, GRS, RA-GRS) — Self-check: which redundancy is required for cross-region restore?
• Azure VM agent and extensions — Self-check: which extension does Azure Backup install on a Windows VM to take application-consistent snapshots?
• RBAC for backup — Self-check: which built-in role lets a user trigger a restore but not delete backup items?
• RPO and RTO — Self-check: if backup runs once daily at 02:00, what is the maximum RPO?
• Region pairs — Self-check: what is the paired region of northeurope?

If any answer feels uncertain, pause and review before you continue. Backup design is unforgiving when you misjudge prerequisites — a wrong redundancy choice on day one cannot be reversed later without destroying and rebuilding the vault.

Learning Objectives

By the end of this lesson you will be able to:

1. Analyse a workload's RPO, RTO, application-consistency, and retention requirements and translate them into Azure Backup configuration.
2. Evaluate trade-offs between Azure VM backup, MARS agent, and Azure Backup Server (MABS), including when each is the wrong tool.
3. Design a Recovery Services Vault with appropriate replication, soft-delete duration, Multi-User Authorization, and Cross-Region Restore.
4. Recommend backup policies for tiered VM workloads (tier-1 production vs dev/test) with grandfather-father-son retention schedules.
5. Justify the right restore strategy from the menu of options (instant restore, file-level recovery, full-VM restore, cross-region restore) given an incident scenario.
6. Detect misconfigurations that auditors and exam scenarios target: disabled soft-delete, mismatched vault region, missing application-consistency, and over-permissioned backup contributors.

Building Blocks

Before the deep dive, lock in the vocabulary. Each term gets an analogy first, the formal definition next, and a one-sentence reason it matters.

Recovery Services Vault (RSV) — Analogy: a fireproof safe-deposit box at a separate bank vault. Formal: an Azure resource that holds backup data, recovery points, policies, and credentials for Azure VM, MARS, MABS, and SQL Server in Azure VM workloads. Why it matters: the vault is the protection boundary — soft-delete, replication, and MUA settings live there, and they are difficult to change once items are protected.

Backup vault (newer) — Analogy: a sibling vault designed for newer workloads. Formal: a separate Azure resource introduced for Azure Disks, Azure Blob, Azure Database for PostgreSQL, AKS, and Azure Files (vaulted tier). Why it matters: a Recovery Services Vault and a Backup vault are not interchangeable; the exam tests which workload uses which.

MARS agent — Analogy: a backup courier installed on each server. Formal: the Microsoft Azure Recovery Services agent runs inside Windows (and select Linux distros) to back up files, folders, and system state directly to a vault. Why it matters: the right tool when you need granular backup of a fileserver or hybrid Windows host that is not best served by a whole-VM snapshot.

Azure Backup Server (MABS) — Analogy: a centralized DPM appliance for application-aware backup. Formal: a Windows server running Microsoft Azure Backup Server software (a fork of System Center DPM) that performs app-consistent backups of SQL Server, Exchange, SharePoint, and Hyper-V VMs to a vault. Why it matters: needed when application-consistency requires app-specific writers (Exchange) and central scheduling.

Snapshot — Analogy: a freeze-frame of a hard drive. Formal: a point-in-time copy of a managed disk created via Azure storage. Why it matters: Azure VM backup uses snapshots as the source of recovery points, and the "Instant Restore" tier keeps those snapshots locally for 1–5 days for fast recovery.

Application-consistent backup — Analogy: pausing the chef before snapping the photo so nothing is mid-pour. Formal: a backup taken with VSS writers on Windows or pre/post-scripts on Linux so transactions are flushed and queues are drained. Why it matters: file-system consistency alone is not enough for databases, message brokers, or any in-memory work.

Soft-delete — Analogy: the recycling bin in front of the shredder. Formal: deleted backup items are retained 14 days by default (configurable up to 180 days, or always-on / immutable) before permanent purging. Why it matters: it is the single control that absorbs accidental and malicious delete operations.

Multi-User Authorization (MUA) — Analogy: a two-key launch system. Formal: a vault feature that requires a second principal — bound to a Resource Guard in a separate subscription — to approve sensitive operations such as disabling backup, modifying policy, or stopping protection. Why it matters: it raises the bar on attackers who phish a single admin account.

Cross-Region Restore (CRR) — Analogy: a duplicate set of keys held at a second branch. Formal: an opt-in vault feature that exposes the GRS-replicated secondary region as a restore endpoint. Why it matters: it is required when you need cross-region recoverability without invoking Azure Site Recovery.

Deep Dive

Recovery Services Vault — design choices that lock in

The first design decision for the vault is replication. You set it at vault creation, and it becomes effectively immutable once protected items exist. The choice cascades into every later capability.

[!IMPORTANT] The vault region must match the resource region for Azure VM backup. You cannot back up a VM in eastus to a vault in westus2. Pick the vault region first, then place workloads.

A second decision sits next to replication: the soft-delete duration. Default is 14 days; you can extend to a maximum of 180 days, or set the vault to immutable so soft-delete cannot be turned off. Together with MUA, immutability creates a posture where ransomware that compromises a single admin account cannot wipe backups.

What gets backed up — three distinct paths

Three native paths exist; the exam tests your ability to pick between them based on workload characteristics, not on price.

For Azure SQL inside an Azure VM, the recommended path is the AzureBackupWindowsWorkload extension — a hybrid model that is part of Azure VM backup but adds SQL-aware features such as transaction-log backup (RPO of 15 minutes), differential backup, and database-level granular restore.

Backup policies — frequency, retention, and the snapshot tier

A policy bundles three things: frequency, retention, and the Instant Restore tier (the local snapshot kept on managed disks for fast recovery).

A typical tier-1 policy uses Instant Restore 5 days + Vault-Standard 30 daily + monthly 12 + yearly 7. Long-term retention (LTR) builds on this with a grandfather-father-son schedule that pushes the oldest copies to the archive tier for compliance.

The Bicep below provisions a vault, enables soft-delete and CRR, and creates a daily VM backup policy.

Application-consistent snapshots — VSS and pre/post scripts

Without VSS writers (Windows) or pre/post scripts (Linux), the snapshot is at best file-system-consistent and at worst crash-consistent. The exam wants you to recognize when consistency matters:

• Stateless web tier — file-system consistency is sufficient.
• SQL Server, Oracle, MongoDB, MySQL — application consistency is mandatory.
• Active Directory domain controllers — application consistency is mandatory; otherwise you risk USN rollback after restore.
• Message brokers (RabbitMQ, Kafka) — application consistency is required to avoid losing in-flight messages.

For Linux workloads with a database, you provide a pre-script that flushes and locks the database, and a post-script that releases it. The Azure Backup extension hands the snapshot off between the two scripts.

Restore options — pick the smallest blast radius

Backup design is half about taking backups and half about restoring them. The restore menu, ordered roughly by blast radius:

File-level recovery is the most-asked feature on the exam: you mount the recovery point as iSCSI on a temporary host, copy what you need, and unmount. It does not require the source VM to be online.

The PowerShell below enables backup on an existing VM using a previously defined policy.

RBAC — who can do what

Three built-in roles cover the backup lifecycle. Pair them with MUA so that destructive actions also require a second principal.

[!TIP] Day-to-day operators should be granted Backup Operator, not Backup Contributor. A break-glass account holds Backup Contributor and is required only when the policy itself must change.

Monitoring and alerting

Azure Backup writes job records to the vault and emits diagnostic logs to a Log Analytics workspace. The KQL below finds VMs whose last successful backup is older than 48 hours — a signal that something is wrong.

Pair this with an Azure Monitor alert and a webhook into your SRE channel.

Networking and cost — two often-missed levers

Backup traffic between the VM and the vault traverses Azure's backbone by default, but compliance-sensitive environments often require this to never touch the public internet. The lever is Azure Backup Private Endpoint: a Private Endpoint deployed into your VNet that gives the vault a private IP. The VM agent then routes backup traffic privately, never resolving public Azure Backup FQDNs. Two gotchas appear on the exam: a Private Endpoint is per-vault (not per-policy), and existing protected items must be re-registered after enabling the Private Endpoint for the change to take effect.

On cost, Azure Backup is billed on two axes: per protected instance (a flat fee scaling with instance size band) and per gigabyte stored (with separate rates for Vault-Standard hot and Vault-Archive cold tiers). The architect's main cost lever is moving older monthly and yearly recovery points to the archive tier, which can reduce long-term storage cost by roughly 80% relative to the standard tier. The trade-off is that archive restores take hours rather than minutes — perfectly acceptable for compliance-only retention. Use Azure Cost Management with the Microsoft.RecoveryServices resource provider filter to see this breakdown.

Worked Examples

Example 1 — Easy: a tier-1 SQL VM

Problem. Contoso runs a Standard_E16s_v5 SQL Server VM in westeurope carrying production workload. Requirements: RPO of 15 minutes or less, RTO of 4 hours or less, retention 30 days daily plus 7 years annually, application-consistent. Recommend a backup design.

Solution.

1. Create a Recovery Services Vault in westeurope, replication GRS, immutable soft-delete, MUA enabled.
2. Install the SQL workload extension on the VM (AzureBackupWindowsWorkload).
3. Configure a SQL backup policy: full backup daily, differential every 12 hours, transaction log backup every 15 minutes.
4. Configure a parallel Azure VM backup policy on the same vault for OS-level recovery, daily at 02:00 UTC, 30-day retention, 5-day Instant Restore.
5. Long-term retention: monthly archive for 12 months, yearly archive for 7 years (Vault-Archive tier).

[!NOTE] The VM-level backup gives you OS recovery; the SQL-extension backup gives you point-in-time database recovery. Both belong on a tier-1 SQL VM.

Example 2 — Medium: regional resilience without ASR

Problem. A web tier in northeurope must be restorable to westeurope if northeurope becomes unavailable. Budget rules out Azure Site Recovery. RTO of several hours is acceptable.

Solution.

1. Recovery Services Vault in northeurope with replication GRS.
2. Enable Cross-Region Restore (CRR) under vault Properties → Replication settings.
3. Daily backup, 30-day retention, 5-day Instant Restore.
4. Document the runbook: in a regional failure, trigger CRR from the secondary region (westeurope) and create new VMs from the recovery points.

[!WARNING] CRR is asynchronous and the secondary recovery point can lag the primary by up to 12 hours. If your RPO is tighter than that, this design is not sufficient — choose Azure Site Recovery instead.

Example 3 — Hard: ransomware-resilient backup

Problem. After a sector-wide ransomware wave, the auditor requires that compromise of any single admin account cannot result in immediate destruction of backup data. Pick the right Azure features and explain how each maps to the audit control.

Solution.

1. Multi-User Authorization (MUA) on the Recovery Services Vault, scoped to a Resource Guard placed in a separate subscription under a different Microsoft Entra ID tenant where possible. The Resource Guard owner is a different identity to the vault owner.
2. Always-on (immutable) soft-delete so the soft-delete duration cannot be reduced by the vault owner.
3. Vault-archive tier for monthly recovery points so the most ancient copies are immutable for compliance.
4. Backup Operator day-to-day; Backup Contributor restricted to a small Privileged Identity Management (PIM) eligible role with 1-hour activation and approval workflow.
5. Diagnostic logs streamed to a separate, write-once Log Analytics workspace owned by SecOps.

The kill chain that this design stops: an attacker phishes the cloud admin, then tries to disable soft-delete (MUA denies the request), then tries to delete protected items (soft-delete absorbs the deletion), and meanwhile alerts fire to SecOps.

Visual Explanations

V1 — Decision tree for backup path

Caption. Two questions narrow the path: what is being backed up, and whether cross-region restore is needed. The exam expects you to land on the same leaf nodes from a scenario question.

V2 — Vault topology with MUA and Resource Guard

Caption. A vault hardened with MUA via an external Resource Guard, GRS replication to the paired region, and diagnostics streamed to a write-once SecOps workspace.

V3 — Restore options ordered by RTO

Caption. The restore menu sorted by typical recovery time. The exam often hides the right answer in the constraint that the source VM still exists.

Common Mistakes

❌ Myth: Azure Backup and Azure Site Recovery are interchangeable. ✅ Reality: Azure Backup is point-in-time recovery (RPO hours/days). Azure Site Recovery is replication for region/site failure (RPO seconds/minutes). They solve different problems and are usually deployed together on tier-1 workloads, not as alternatives. Why it's tricky: Both store data in vaults and both can recover VMs across regions. The key tell is the RPO in the requirements.

❌ Myth: Soft-delete is a recoverability feature you can switch off to save money. ✅ Reality: Soft-delete is a security control. There is no per-item charge for soft-deleted items during the retention window. Disabling it removes the recycling bin in front of the shredder. Why it's tricky: Operations teams sometimes treat soft-delete as clutter; auditors and incident responders treat it as the last line of defence.

❌ Myth: You can enable Cross-Region Restore on an existing LRS vault when needed. ✅ Reality: CRR requires GRS replication. The replication setting is locked once protected items exist. If you started with LRS, you must rebuild the vault to switch. Why it's tricky: GRS and CRR are two separate switches. GRS replicates the data; CRR exposes the secondary restore endpoint. Forgetting either one breaks the design.

❌ Myth: The MARS agent is just a slower version of Azure VM backup. ✅ Reality: MARS backs up files, folders, and system state from inside the OS — useful for fileserver-style workloads, on-prem servers, and selective backup. Azure VM backup is whole-machine snapshot via the Azure fabric, faster for entire-VM recovery but coarser-grained. Why it's tricky: Both write to the same Recovery Services Vault. The exam often tests granularity vs speed.

❌ Myth: Application-consistent snapshots happen automatically on every VM. ✅ Reality: Application consistency requires VSS writers on Windows and pre/post-scripts on Linux. Without them you get crash-consistent at best — fine for stateless tiers, dangerous for databases. Why it's tricky: The Azure portal does not always surface a clear warning that the snapshot was crash-consistent until restore time.

Practice Exercises

🟢 E1 — Vault redundancy for a stateless web tier. A Standard_DS3_v2 IIS tier in eastus needs daily backup with 30-day retention. The workload is stateless and replicated globally. Recommend the vault and policy.

▶💡 Hint

Stateless tier — application consistency is not required, and a single-region vault may suffice if the global front door already handles regional failover.

▶✅ Solution

Recovery Services Vault in eastus, LRS replication, daily 02:00 backup, 30-day retention, 2-day Instant Restore. If the team later needs cross-region restore, they must build a new GRS vault and re-protect.

🟡 E2 — SQL log backup cadence. A SQL VM uses the AzureBackupWindowsWorkload extension. The DBA wants log backups every 15 minutes. Is that supported, and what is the configuration path?

▶💡 Hint

The SQL workload supports a finer RPO than crash-consistent VM backup.

▶✅ Solution

Yes. The SQL workload backup supports full (1/day or 1/week), differential (1/day), and log backup as frequent as every 15 minutes. Configure under the SQL backup policy on the vault. The extension uses the NT Service\AzureWLBackupPluginSvc account inside the VM and requires db_backupoperator rights on each database.

🟡 E3 — Two-principal control. An auditor requires that no single account can both delete backup data and approve the deletion. Which feature delivers this, and what additional resource must you create?

▶💡 Hint

The feature pairs with a separate guard resource.

▶✅ Solution

Multi-User Authorization (MUA), paired with a Resource Guard placed in a different subscription (and ideally a different AAD tenant). The vault owner cannot modify or delete the Resource Guard, so destructive ops require a second principal who is Contributor on the Resource Guard.

🔴 E4 — Cross-region restore not working. A team has a GRS vault but cannot trigger restore in the secondary region. What is missing?

▶💡 Hint

GRS is replication; the secondary restore endpoint requires another switch.

▶✅ Solution

Cross-Region Restore (CRR) is opt-in. Enable under vault Properties → Backup Configuration → Cross Region Restore. CRR cannot be disabled once enabled, and it can take up to 48 hours to surface the first restore points in the secondary region.

🔴 E5 — VM and backup both deleted. A VM was deleted. Twenty minutes later, an admin deleted the backup item too. Soft-delete is on default. What is recoverable, and how?

▶💡 Hint

Soft-delete catches the second deletion.

▶✅ Solution

The deleted backup item is recoverable for 14 days from Backup Items → Soft-deleted items → Undelete. After undelete, you can restore to a new VM. After 14 days the data is permanently gone. If the vault had immutable soft-delete enabled, 14 days could be configured up to 180 days; if MUA were on, the second deletion would have required approval.

🟢 E6 — File-level recovery on Linux. A user accidentally deleted a 50 MB log file from a Linux VM. The whole VM is fine. How do you recover just the file from yesterday's backup point?

▶💡 Hint

Mount the recovery point as a drive on a temporary machine.

▶✅ Solution

In the recovery point details, choose File Recovery. Azure generates a one-time script that mounts the recovery point as iSCSI on a Linux machine of your choice (typically a small jumpbox). Copy the file, run the unmount script. The mount expires after 12 hours.

🟡 E7 — Maximum retention. What is the maximum daily and yearly retention for Azure VM backup?

▶💡 Hint

Long-term retention is measured in years.

▶✅ Solution

Daily up to 9999 days; yearly up to 99 years. Most production policies use daily 30 + monthly 12 + yearly 7, with archive tier for the older yearly recovery points to control cost.

🔴 E8 — Backup not running. A team gets an alert that vm-prod-01 has not had a successful backup in 48 hours. Walk through the troubleshooting order.

▶💡 Hint

Three layers: agent, network, vault.

▶✅ Solution

(1) Check the VM agent is running and the VMSnapshot extension is healthy. (2) Confirm outbound network to the *.backup.windowsazure.com and storage endpoints (Private Endpoint or Service Tag). (3) Confirm vault soft-delete state is not blocking new items because of a quota issue. (4) Look at AddonAzureBackupJobs in Log Analytics for the failure reason; common causes include VSS writer failure, Linux pre-script timeout, and disk lease conflicts.

Summary & Concept Map

Five takeaways to carry into the exam and into customer conversations:

• Pick the backup path by what you back up. Azure VM backup for whole-VM, MARS for granular files, MABS for application-aware central scheduling. The exam tests this distinction often.
• The Recovery Services Vault is your protection boundary. Replication, soft-delete, MUA, and CRR all live there, and most settings become hard to change once items are protected.
• Application consistency is mandatory for stateful workloads — VSS writers on Windows, pre/post-scripts on Linux. Crash-consistent is fine only for stateless tiers.
• Cross-region restore needs both GRS replication and the CRR opt-in. They are two switches, not one.
• Soft-delete and MUA are security controls, not luxury features. Tier-1 production almost always wants always-on soft-delete plus MUA via a Resource Guard in a separate subscription.

Caption. The four pillars of compute backup design — vault, path, restore, and hardening — and the cross-cutting dependency between GRS replication and Cross-Region Restore.