Backup, DR & updates
Backup vs Site Recovery, update management.
A production system can fail in two very different ways, and each failure needs its own kind of safety net. Azure Backup is the fireproof safe in the basement: scheduled copies of your data, kept apart from the live system, so you can rebuild after something is deleted, corrupted, or encrypted by ransomware. Azure Site Recovery (ASR), a service that keeps a running copy of your machines in a second Azure region, is the furnished office across town: a replica of the live workload, updated minute by minute, that your team moves into when the whole building goes dark. In cloud terms, the building is an Azure region. Azure Update Manager is the maintenance crew that stops most fires from starting at all, patching operating systems on a schedule instead of by heroics at 2am.
Two numbers decide which tool a situation calls for, and the AZ-104 exam (Microsoft's certification for Azure administrators) leans on them constantly. Recovery Point Objective (RPO) is how much data you can afford to lose, counted backwards from the moment things broke. Recovery Time Objective (RTO) is how long you can afford to be down. Backup gives you an RPO measured in hours, because recovery points are taken daily, or as often as every four hours on an enhanced policy. Its RTO runs from minutes to hours, because you have to actually restore something. Site Recovery replicates continuously, so its RPO is minutes, and its RTO is minutes too in practice, because the replica boots in the second region (Microsoft's service level agreement commits to two hours). Translate exam wording like this: "recover a file someone deleted last Tuesday" means Backup, and "keep serving customers through a regional outage without losing much data" means Site Recovery. Anything critical needs both.
The Recovery Services vault: where the copies live
Both services keep their state in a Recovery Services vault. A vault is a management resource holding three things: *recovery points* (the restorable copies), backup policies, and replication settings. You never see the storage underneath it. Azure runs that storage outside your subscription, and that is the entire point. An attacker who takes over your subscription still cannot open the safe and shred what is inside. Two rules govern vaults. First, a vault protects resources in its own region only, so virtual machines (VMs) in East US 2 need a vault in East US 2. Second, every vault has a storage redundancy setting: the same LRS (locally redundant storage), ZRS (zone redundant storage) and GRS (geo redundant storage) tiers you met in the storage lessons. It defaults to geo redundant, and you can pair that with cross-region restore, which lets you restore into the paired region while the primary region is still down.
# A vault protects resources in ITS OWN region — create it where the VMs liveaz backup vault create \--resource-group prod-rg \--name prod-vault \--location eastus2# Redundancy defaults to GeoRedundant. Decide NOW — before the first backup.az backup vault backup-properties set \--resource-group prod-rg --name prod-vault \--backup-storage-redundancy GeoRedundant \--cross-region-restore-flag True# show returns a list: [0] is the storage config, [1] the vault configaz backup vault backup-properties show \-g prod-rg -n prod-vault \--query "[0].properties.{redundancy:storageModelType, state:storageTypeState}"# {# "redundancy": "GeoRedundant",# "state": "Unlocked"# }
"state": "Unlocked" in the output is a one-way gate. As soon as you protect the first item it flips to Locked, and you cannot change the vault's redundancy while it holds protected items. The default is GeoRedundant, which costs roughly double the storage of LRS, so teams tend to find the lock in one of two expensive ways: a dev vault quietly billing geo-redundant rates, or a production vault created as LRS that can never gain cross-region restore. Fixing it means building a new vault and re-protecting every item, and the old recovery points stay stranded in the old vault until they expire.Protect a VM, then watch the job run
A backup policy is two things bolted together: a schedule, and a set of retention rules. How often a recovery point is taken, and how long the dailies, weeklies, monthlies and yearlies are kept. (If you ever ran tape rotations, this is grandfather-father-son retention with nicer buttons.) When a backup fires, the backup extension running inside the virtual machine coordinates a disk snapshot. On Windows it pushes in-flight writes down to disk through VSS (Volume Shadow Copy Service, the built-in Windows machinery for snapshotting files that are open), which makes the copy application-consistent: the application starts from it cleanly. On Linux the default copy is file-system-consistent, and application consistency means writing your own pre and post scripts to pause the app for a moment. The snapshot stays in your own subscription for a couple of days, the *instant restore* tier, which is why recent restores are fast. After that, only changed blocks ship to the vault. The built-in DefaultPolicy runs once a day. EnhancedPolicy supports four-hour frequency, snapshot retention up to 30 days, and is *required* for Ultra Disks and Premium SSD v2. Trusted Launch VMs used to require it as well. Current tooling accepts a standard policy for them, but older exam questions still expect the answer "Trusted Launch needs Enhanced."
# The vault ships with built-in policiesaz backup policy list -g prod-rg -v prod-vault --query "[].name" -o tsv# DefaultPolicy# EnhancedPolicy# HourlyLogBackup# Enable protection for a VMaz backup protection enable-for-vm \-g prod-rg --vault-name prod-vault \--vm web-01 --policy-name EnhancedPolicy# Don't wait for the schedule — take a recovery point right nowaz backup protection backup-now \-g prod-rg -v prod-vault \--container-name web-01 --item-name web-01 \--backup-management-type AzureIaasVM \--retain-until 12-08-2026az backup job list -g prod-rg -v prod-vault -o table# Name Operation Status Item Name Backup Management Type Start Time UTC Duration# ------------------------------------ --------------- ---------- ----------- ------------------------ -------------------------------- --------------# ab52c99e-6a30-4f9e-9d0d-e478f21c0e92 Backup InProgress web-01 AzureIaasVM 2026-07-13T09:12:04.336510+00:00 0:06:12.277799# 77f0a2d1-40f3-4a1e-8c2f-5d6b1e9a3c47 ConfigureBackup Completed web-01 AzureIaasVM 2026-07-13T09:05:11.104223+00:00 0:00:31.191807
Restore: the drill nobody runs
Restores come in grades, and it pays to know the ordering cold. An application-consistent point restores an app that boots clean. A file-system-consistent point guarantees the files are whole, but the app may have to run its own crash recovery on startup. A crash-consistent point is what you get when someone yanks the power cord. When you do restore, put the disks into a *separate* resource group instead of overwriting the original VM. You keep the patient alive while you examine the copy, and a botched restore costs you nothing. The vault also has soft delete. If backup data gets deleted, by accident or by an attacker tidying up before setting off ransomware, the vault quietly holds on to it for 14 days at no charge (extendable to 180 days), and you can bring it back.
# List recovery points — note the consistency columnaz backup recoverypoint list \-g prod-rg -v prod-vault \--container-name web-01 --item-name web-01 \--backup-management-type AzureIaasVM -o table# Name Time Consistency# -------------- -------------------------------- -------------# 79345712909246 2026-07-13T02:01:44.919816+00:00 AppConsistent# 79338826101533 2026-07-12T02:00:59.436713+00:00 AppConsistent# Restore the disks into a clean resource group, staged via a storage accountaz backup restore restore-disks \-g prod-rg -v prod-vault \--container-name web-01 --item-name web-01 \--rp-name 79345712909246 \--storage-account restorestaging01 \--target-resource-group restored-rg# Backup item deleted? Soft delete holds the data for 14 days:az backup protection undelete \-g prod-rg -v prod-vault \--container-name web-01 --item-name web-01 \--backup-management-type AzureIaasVM --workload-type VM
An untested backup is a hope, not a plan. Put a restore drill on the calendar every quarter and time it with a stopwatch. That measured number is your real RTO, whatever the runbook claims.
Site Recovery: when the region is gone
Site Recovery copies a VM's disk writes into a second region *while the machine keeps running*. For Azure-to-Azure replication, an agent called the Mobility service forwards each write to a cache storage account in the source region, and Site Recovery ships it onward to the target, cutting a crash-consistent recovery point every five minutes. App-consistent points are available too, but they are off by default, because pausing the app costs guest performance. That is the RPO half of the story. Failover is the RTO half: Site Recovery builds a VM in the target region from the replicated disks and boots it. The one to remember is the test failover, which boots the replica into an isolated virtual network. Production keeps running, replication keeps flowing, customers notice nothing. After a real failover you re-protect (reverse the direction of replication) and later fail back, a controlled failover in the opposite direction that you run once the old region is healthy again. Applications spread across several machines use *Recovery Plans* to set the order of failover, databases before web tiers, and to fire Automation runbooks along the way. Day-to-day Site Recovery work mostly happens in the portal, though the az site-recovery CLI (command line interface) extension covers it when you want automation.
Patch at scale with Azure Update Manager
Azure Update Manager is the patch service that took over from Automation Update Management, which Microsoft retired in 2024. Worth knowing, because plenty of older study material still teaches the dead one. It needs no Log Analytics workspace and no Automation account. It talks to the VM agent directly, works out which patches are missing (periodic assessment can run every 24 hours), and installs them either on demand or on a repeating schedule. Two commands make patching concrete:
# What is this VM missing? Assessment runs inside the guest via the VM agentaz vm assess-patches -g prod-rg -n web-01 \--query "{status:status, critical:criticalAndSecurityPatchCount, other:otherPatchCount, reboot:rebootPending}"# {# "status": "Succeeded",# "critical": 9,# "other": 27,# "reboot": false# }# Patch it: security fixes only, 2-hour window, reboot only if requiredaz vm install-patches -g prod-rg -n web-01 \--maximum-duration PT2H \--reboot-setting IfRequired \--classifications-to-include-linux Critical Security \--query "{status:status, installed:installedPatchCount, failed:failedPatchCount, reboot:rebootStatus}"# {# "status": "Succeeded",# "installed": 9,# "failed": 0,# "reboot": "Completed"# }
For a fleet you do not patch machines one at a time. You define a maintenance configuration, which is a recurring window (say Sundays from 03:00 to 06:55), and attach machines to it. Name them explicitly, or use *dynamic scoping*, which matches machines by subscription, resource group, or tag. One prerequisite trips almost everyone: the machine's patch orchestration has to be set to *Customer Managed Schedules* (AutomaticByPlatform plus the bypass-platform-safety flag), or the window will skip it without a word.
# A maintenance configuration = a recurring patch windowaz maintenance configuration create \-g prod-rg --resource-name sunday-3am -l eastus2 \--maintenance-scope InGuestPatch \--maintenance-window-start-date-time "2026-07-19 03:00" \--maintenance-window-duration "03:55" \--maintenance-window-recur-every "Week Sunday" \--maintenance-window-time-zone "UTC" \--reboot-setting IfRequired \--extension-properties InGuestPatchMode="User"# Attach a VM to the window (dynamic scoping can do this by tag instead)az maintenance assignment create \-g prod-rg -l eastus2 \--resource-name web-01 \--resource-type virtualMachines \--provider-name Microsoft.Compute \--configuration-assignment-name sunday-3am \--maintenance-configuration-id $(az maintenance configuration show \-g prod-rg --resource-name sunday-3am --query id -o tsv)
Recoverability, replication and patching are habits you keep, not boxes you tick once, and every one of them carries a bill that arrives each month. GRS vault storage costs roughly double LRS. Every recovery point you retain is storage you pay for. Site Recovery charges a fee per protected instance, plus the disks it holds in the target region and the replication traffic leaving the source region. Azure Advisor will point out VMs *without* backup, but nothing points out a vault quietly billing geo-redundant rates to protect dev machines that a pipeline could rebuild in ten minutes. Reading that line item, and shrinking it, is core administrator work, which is exactly where the next lesson goes: Cost management.
Backup and disaster recovery are cousins, not twins. Azure Backup takes point-in-time recovery points into a vault: files, VMs, SQL databases, file shares. Azure Site Recovery replicates continuously so you can fail compute over into a second region when the first one is gone. Mixing the two words on an incident call confuses everybody, so say "restore from backup" or "fail over with Site Recovery" and mean it.
Update management closes a different gap. Unpatched machines are how an ordinary vulnerability turns into a ransomware event. Azure Update Manager schedules assessments and patch deployments across Azure VMs and Arc-enabled servers alike (Arc-enabled means a machine living outside Azure that you register with Azure so it can be managed the same way). Soft delete, immutability and resource locks on the vault finish the picture: guard the backups as carefully as you guard production.
Try this
Create a Recovery Services vault, turn on backup for a lab VM with a daily policy, then kick off a backup by hand. Keep listing jobs until one comes back Completed.
RG=rg-lab-bkaz backup vault create -g $RG -n rsv-drlab -l eastusaz backup policy list --vault-name rsv-drlab -g $RG -o table# After protecting a VM:az backup job list --vault-name rsv-drlab -g $RG --query "[0:3].{status:properties.status,op:properties.operation}" -o table
$ az backup policy list --vault-name rsv-drlab -g rg-lab-bk -o tableName Type---------------------- -----------------DefaultPolicy AzureVMEnhancedPolicy AzureVMHourlyLogBackup AzureSQL# Sample output$ az backup job list ... -o tableStatus Op--------- ------Completed Backup
Takeaway
Backup brings data back. Site Recovery brings whole machines and applications back by failing them over into another region. Update Manager keeps operating system patches from becoming the incident that Backup has to clean up after.
Next: write your RPO and RTO targets down where the team can see them, test a VM restore once a month, and put soft delete plus a resource lock on the vault so ransomware cannot erase your last good copies with a single API call (one scripted command against Azure's management interface).