Site Reliability

Turn on Azure Backup for your virtual machines

One capability for the whole VM estate: make sure every business-critical virtual machine has a scheduled backup landing in a Recovery Services vault, so a deleted disk, a bad deployment or a corrupted boot volume is a restore, not an outage.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Backing up your VMs: the basics

What does an unprotected virtual machine actually expose you to?

A virtual machine without a backup is a single copy of state with no undo. The disks hold the operating system, the application binaries, the local data and the configuration that took weeks to get right, and if any of that is deleted, corrupted or encrypted by ransomware, there is nothing to restore from. Azure Advisor flags exactly this: its reliability recommendation 'Enable Backup on your virtual machines' lists every VM in the estate that has no protected backup configured, because an unbacked machine is a reliability gap waiting to become an outage.

Azure Backup closes that gap by taking scheduled, application-consistent snapshots of a VM's disks and storing the recovery points in a Recovery Services vault. The vault is a managed container that lives outside the VM, so even if the machine, its disks or its resource group are deleted, the recovery points survive. From a recovery point you can restore the whole VM, swap in individual disks, or pull back single files, which turns most data-loss scenarios from a rebuild into a routine restore.

Most unprotected machines are drift, not a decision. A VM spun up for a quick test that became load-bearing, a machine deployed by a module that never wired up backup, a workload migrated in a hurry. The work is to find every VM Advisor has flagged, decide which genuinely need protection, attach each to a Recovery Services vault with a backup policy that matches how much data loss the workload can tolerate, and then make backup the default for everything created next.

In this lesson you will learn what Azure Advisor's 'Enable Backup on your virtual machines' recommendation is actually checking, how to find every unprotected VM in a subscription, and how to bring them under a Recovery Services vault with a backup policy that matches each workload, without over-spending on machines that do not need it. You will see the exact az CLI to enable protection and a Bicep block that makes backup part of the deployment rather than an afterthought.

Fun fact

The machine that was load-bearing by accident

The VMs that hurt most when they fail are rarely the ones anyone planned to depend on. They are the test box that quietly became the licence server, the migration staging machine that ended up serving live traffic, the one-off that nobody put a backup on because it was 'temporary'. Azure Advisor exists partly to surface exactly these: it scans the estate regularly and lists every VM with no protected backup, so the machine that became load-bearing by accident does not stay unprotected by accident too. New vaults also enable soft delete by default, which retains deleted backup data for an extra recovery window, so even a deletion of the backup itself has a grace period.

Finding unprotected VMs across a subscription

Priya runs the platform team at a SaaS company whose estate grew faster than its guardrails. Azure Advisor's reliability tab shows the 'Enable Backup on your virtual machines' recommendation listing fourteen machines across two subscriptions with no protected backup.

Rather than enable backup blindly on all fourteen, Priya starts by listing every VM in the subscription and cross-checking which ones already appear as protected items in the Recovery Services vault, so the genuinely unprotected business-critical machines stand out from the throwaway ones before anything is configured.

List the VMs already protected in the vault, so you can subtract them from the full estate and see what Advisor is really flagging.

$ az backup item list --resource-group rsv-prod --vault-name rsv-prod-vault --backup-management-type AzureIaaSVM --query "[].{vm:properties.friendlyName, lastBackup:properties.lastBackupStatus}" -o table

Vm LastBackup

--------------- ------------

orders-db-prod Completed

web-frontend-01 Completed

# Only 2 VMs protected. Advisor flagged 14. The order DB is covered; the rest are not.

The protected-item list is the source of truth for what is actually covered. Subtract it from the full VM list to see exactly which flagged machines still have no recovery point.

How Azure Backup actually protects a VMdeep dive

Enabling backup on a VM creates a protected item that links three things: the VM, a Recovery Services vault, and a backup policy. The policy defines when the backup job runs and how long each recovery point is kept. The default policy runs a backup once a day and retains recovery points for 30 days, which is a sensible starting point that you tune per workload rather than accept blindly. When the scheduled job runs, Azure Backup takes a snapshot of the VM's disks, and for supported workloads it coordinates with the guest to get an application-consistent point rather than just a crash-consistent one.

The recovery points live in the vault, which is deliberately separate from the VM's own resource group and disks. That separation is the whole point: deleting the VM, its disks or even its resource group does not delete the recovery points, so you can restore the machine afterwards. The first backup is a full copy; every job after that is incremental, transferring only the blocks that changed, which keeps both the time and the storage cost down. By default a new vault uses geo-redundant storage, replicating recovery points to a paired region, and you can switch it to locally redundant where cross-region durability is not required and you want to lower the storage cost.

The strongest position pairs the per-VM protection with a deployment default, so new machines arrive backed up instead of relying on someone remembering. That is the difference between checking that today's estate is protected and guaranteeing that tomorrow's machines are protected the moment they exist. Advisor will keep listing any VM without a protected backup, so it doubles as an ongoing check that the default is holding.

What is the impact of leaving a VM unbacked?

The direct impact is recovery time. An unprotected VM that is deleted, corrupted, encrypted by ransomware or wrecked by a bad patch has no recovery point to restore from, so the only path back is to rebuild it: provision a new machine, reinstall and reconfigure everything, and recover whatever data can be found elsewhere. For a machine that was set up carefully over weeks, that rebuild is measured in hours or days, and the service it backs is down for all of it.

The second-order impact is the data you cannot rebuild. Configuration drift, local state, application data that never made it into a database: none of that is reproducible from a template. A backup captures the machine as it actually was, so a restore brings back the real state rather than an approximation. Without it, even a successful rebuild can leave you reconstructing data from memory and partial copies, which is exactly when mistakes compound.

On the resilience side, every modern operational standard expects recoverability to be designed in, not improvised. A Recovery Services vault with recent recovery points across the business-critical estate is the cheapest, most defensible evidence that a lost machine is a restore rather than an outage. Advisor flagging an unprotected production VM is a direct signal that a single accident on that machine becomes a full outage with no clean path back.

How do you protect the estate without over-spending?

Work the capability as one loop rather than enabling backup machine by machine in a panic. The order matters: decide what each machine is worth before you choose its policy, so you neither leave a critical VM exposed nor pay rich retention for a scratch box.

1. Inventory every VM against what is already protected

Pull Advisor's flagged list and the vault's protected-item list, and subtract one from the other. Treat that as the source of truth for what is genuinely unprotected, because a machine can be running fine for months and still have no recovery point behind it.

2. Classify each VM by cost-of-downtime

For each unprotected machine, decide what an hour of it being down costs and how much data loss the workload can tolerate. Customer-facing production machines justify a richer policy and frequent recovery points; internal tools are usually fine on a standard daily policy; genuine throwaways can be left unprotected on the record.

3. Attach each machine to a vault and a matching policy

Enable backup on the machines that need it, choosing or creating a policy whose schedule and retention match the workload's recovery expectation rather than defaulting every machine to the same setting. Each machine becomes a protected item in the vault immediately, and you can trigger an initial backup so there is a recovery point straight away.

4. Make backup a deployment default

Bake the protected item into the infrastructure template so new business-critical machines arrive backed up rather than relying on anyone remembering. Let Advisor keep flagging any VM that slips through, so the default is continuously checked rather than assumed.

# Enable a daily backup on a business-critical VM using the vault's default policy.
# DefaultPolicy backs up once a day and retains recovery points for 30 days.
az backup protection enable-for-vm \
  --resource-group rsv-prod \
  --vault-name rsv-prod-vault \
  --vm orders-db-prod \
  --policy-name DefaultPolicy

# Take an initial backup now so there is a recovery point immediately,
# rather than waiting for the first scheduled run.
az backup protection backup-now \
  --resource-group rsv-prod \
  --vault-name rsv-prod-vault \
  --container-name orders-db-prod \
  --item-name orders-db-prod \
  --backup-management-type AzureIaaSVM \
  --retain-until 31-12-2026

# Confirm the job is running.
az backup job list \
  --resource-group rsv-prod \
  --vault-name rsv-prod-vault \
  --output table

# --- Make backup a deployment default (Bicep) ---
# Register the VM as a protected item so new machines arrive backed up.
#
# resource protectedItem 'Microsoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protectedItems@2026-02-01' = {
#   name: '${vaultName}/Azure/IaasVMContainer;iaasvmcontainerv2;${resourceGroup().name};${vm.name}/VM;iaasvmcontainerv2;${resourceGroup().name};${vm.name}'
#   properties: {
#     protectedItemType: 'Microsoft.Compute/virtualMachines'
#     policyId: backupPolicy.id
#     sourceResourceId: vm.id
#   }
# }

Quick quiz

Question 1 of 5

Azure Advisor's reliability tab flags fourteen VMs under 'Enable Backup on your virtual machines'. What is the most efficient way to act on them?

Keep learning

Go deeper on how Azure Backup protects virtual machines and how to bring the estate under a Recovery Services vault.

You can now treat VM backup as one capability rather than a scatter of Advisor flags: inventory the unprotected machines against what the vault already covers, classify each by cost-of-downtime, attach the ones that matter to a Recovery Services vault with a policy that fits, and bake protection into your deployment templates so new critical machines arrive backed up. The result is an estate where a lost machine is a restore in a known window, not an open-ended outage.

Back to the library

Backing up your VMs: the cost and downtime view

A small, predictable monthly cost that caps a large, unpredictable outage cost

The whole case for VM backup is the asymmetry between what it costs and what it prevents. Azure Backup is billed per protected instance plus the storage the recovery points consume, so the cost is small, recurring and easy to forecast per VM. The thing it caps is the cost of an outage: the hours a revenue-generating service is down while the team rebuilds a machine from scratch, recreates configuration from memory and hopes the data was reproducible.

Frame each unprotected VM as a line on the downtime risk register rather than a backup checkbox. A machine running the production order database has a far higher cost-of-outage than an ephemeral build agent, yet both surface as a single Advisor finding. Map the flagged VMs to the revenue and the recovery-time expectation behind each one, and prioritise by what an hour of that machine being down actually costs the business.

The arithmetic is one-sided. Protection is a small, bounded monthly charge per machine plus its storage. The downside of skipping it is the cost of an extended outage with no clean restore path: lost transactions, idle staff, missed delivery commitments, and the slow recovery of a machine rebuilt by hand under pressure.

This lesson is for the finance partner who sees a list of VMs flagged for backup and wants to know what protecting them costs, what an outage on an unprotected one would cost instead, and how to turn the flag list into a downtime-ordered plan. It covers why backup is a small predictable charge, which VMs justify a richer policy, and how to size protection to the cost of the machine being down.

Fun fact

The machine that was load-bearing by accident

How a finance partner frames the backup decision

Priya is the finance partner supporting the platform team's resilience push. The reliability report lands with fourteen VMs flagged for backup across two subscriptions. The instinct is not to wave through protecting all fourteen at the richest retention setting; it is to ask what each machine actually does and what it would cost the business if it were down. Azure Backup is billed per protected instance plus the storage its recovery points use, so the spend question is real but small and predictable: a modest recurring charge per machine, scaled by how much history each one keeps.

Priya asks the team to map each flagged VM to the revenue or service behind it and the longest outage that service could tolerate. Three machines run customer-facing production workloads where an hour down is measured in lost transactions and breached commitments, four run internal tools where a same-day restore is fine, and the rest are build agents and scratch boxes that are cheaper to recreate than to protect. The list is reframed on the downtime risk register: the three production machines get a richer policy and are protected today, the internal tools get a standard daily policy, and the throwaways are documented as deliberately unprotected. The finance pack reads: 'Protection for the machines that matter is a small, forecastable monthly line; the alternative for those same machines is an outage with no ceiling on its cost.'

Why an unbacked VM belongs on the downtime risk register

The cost model here is asymmetric in the way that makes resilience spend easy to justify. Protecting a machine costs a small, predictable amount per month: a per-instance charge plus the storage its recovery points use. Leaving it unprotected creates an unbounded tail risk, because the cost of an outage on that machine is not capped by anything. The probability of any single machine failing in a given month is low, but across a whole estate over years it is not, and the machines that fail are rarely the ones you would have chosen to lose.

The cost of an outage with no restore path includes the revenue lost while the service is down, the staff time burned rebuilding a machine by hand under pressure, the commitments missed to customers, and the data that has to be reconstructed because it was never captured. Against that, the remediation is a modest monthly line per machine, tunable by how much history each workload keeps. The finance role is to attach a cost-of-downtime to each flagged VM so protection is prioritised by what an hour of that machine being down actually costs, not by the order Advisor lists them.

What finance can do about the backup gap

Finance cannot enable a backup, but it owns the framing that turns a flat list of flagged VMs into a downtime-ordered plan with a small, forecastable cost and a clearly recorded set of deliberate exceptions. Three levers.

1. Price protection per machine, not per finding

Make explicit that Azure Backup is billed per protected instance plus the storage its recovery points use, so the cost scales with how many machines you protect and how much history each keeps, not with the raw count of Advisor findings. Budget the business-critical machines as discrete, forecastable lines and let the team tune retention down where a workload does not need a long history, so protection is right-sized rather than uniform.

2. Order the work by cost-of-downtime, not by finding count

A production order database and an ephemeral build agent both show up as a single Advisor flag, but the cost of each being down differs by orders of magnitude. Ask the team to map every flagged VM to what an hour of its outage costs the business and protect the highest-cost machines first. The metric that belongs on the cost-and-resilience review is flagged VMs weighted by cost-of-downtime, not the raw count.

3. Require documented exceptions for deliberately unprotected machines

Any VM left unbacked on purpose, the build agents, the scratch boxes that are cheaper to recreate than to protect, should carry a recorded, finance-visible reason. The distinction between 'we decided this machine is disposable and recorded it' and 'nobody noticed it had no backup' is exactly what makes the posture defensible when a machine is lost and someone asks why it was not protected.

Quick quiz

Question 1 of 5

A reliability report flags fourteen VMs for backup. As the finance partner, what is the right starting assumption about the Azure cost to protect them?

Keep learning

Go deeper on how Azure Backup protects virtual machines and how to bring the estate under a Recovery Services vault.

You have finished the finance view of VM backup. You know the cost model is one-sided: protection is a small, forecastable per-machine charge, and the alternative for a critical machine is an outage with no ceiling on its cost. Next time a list of backup flags lands, you will order them by cost-of-downtime, right-size retention to each workload, record the deliberately disposable machines as exceptions, and ask for protection on the machines that matter rather than asking whether backup is worth it.

Back to the library

Backing up your VMs: the headline

Whether a business-critical machine going wrong is a restore or an outage

An unbacked virtual machine is the kind of risk that stays invisible right up until it causes a headline outage. A deleted disk, a failed patch, a corrupted volume or a ransomware hit on an unprotected machine means the service is down until it can be rebuilt, and the report shows this only as a quiet list of VMs Advisor has flagged.

The leadership question is not 'do we take backups somewhere?' It is 'if a critical machine is lost tomorrow, how long are we down and how much data do we lose?' The defensible end state is that every business-critical VM has a scheduled backup in a Recovery Services vault with a known recovery point and recovery time, so the answer is measured in a restore window rather than an open-ended rebuild.

This is a resilience decision with a small, predictable price tag. Protecting the estate costs a modest, forecastable amount per machine. Skipping it trades that certainty for the open-ended cost of an outage that nobody can put a ceiling on until it happens.

A short read for the leader who needs to know what an unbacked VM exposes the business to, why protecting the estate is a resilience decision with a small price tag rather than a major investment, and what a defensible end state looks like in terms of recovery time and data loss.

Fun fact

The machine that was load-bearing by accident

What it looks like when an outage is a restore, not a rebuild

After a peer company lost a day of trading because a production VM was deleted in a botched change and there was no backup to restore from, the CEO asked the obvious question at the next review: if that machine were ours, how long would we be down? The honest answer at the time was that it depended on which machine, because backup across the estate was governed by whoever happened to set it up rather than by policy.

The team's response was to stop treating backup as a per-machine afterthought and start treating it as a property of every business-critical workload. They pulled Advisor's flagged list, mapped each machine to a recovery-time expectation, attached the production and internal workloads to a Recovery Services vault with policies that matched, documented the throwaways as deliberately unprotected, and then baked backup into the deployment templates so new machines arrive protected. The next time the CEO asked the question, the answer had changed from 'it depends' to 'every critical machine has a recovery point within the last day and restores in a known window.' That shift, from hoping a lost machine is reproducible to knowing it is recoverable, is the confidence signal this capability delivers, and its price is a small, predictable monthly charge.

Why this is a resilience decision for the board

Almost every avoidable extended outage that came down to a lost machine traces back to the same root cause: a business-critical workload that had no backup, so a single accident turned into a rebuild. Enabling backup is the capability that converts that root cause into a routine restore, and baking it into deployment templates makes the gap close to impossible to reintroduce.

The cost of getting this wrong is an outage whose length and price nobody can predict until it happens, while the cost of getting it right is a small, forecastable monthly charge per machine. This is the rare class of decision where the risk of inaction is open-ended and the cost of action is bounded and known, which is exactly the trade leadership should be quickest to approve.

The leadership move on backup

The executive handle is not to approve protection machine by machine; it is to require that every business-critical workload has a known recovery point and recovery time, and that the deliberately unprotected machines are recorded as such, on the record.

1. Set a recovery-time target the estate must meet

Ask for the maximum acceptable data loss and recovery time for each tier of workload, and a date by which every business-critical machine is protected by a vault policy that meets it. A target that the estate is measured against is the difference between hoping a lost machine is recoverable and knowing how long its restore takes.

2. Ask for proof, not assurance

The proof that this is closed is not 'we take backups.' It is the vault's protected-item list showing a recent successful recovery point for every business-critical machine, and ideally a test restore that confirms the recovery time is real. Ask for that evidence on a cadence, because a backup nobody has restored from is a hope, not a guarantee.

3. Treat the unprotected machines as named, owned exceptions

A number of machines are genuinely disposable and protecting them would be waste. The leadership requirement is that each is a deliberate, documented decision with an owner, not a machine that slipped through. The goal is not zero unprotected VMs; it is zero unintentionally unprotected business-critical ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a competitor's lost-machine outage could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure Backup protects virtual machines and how to bring the estate under a Recovery Services vault.

Two takeaways. VM backup is the rare resilience control where the cost of inaction is an open-ended outage and the cost of action is a small, predictable monthly charge, so it is the trade you should be quickest to approve. And the defensible end state is not 'we take backups somewhere'; it is a recent recovery point for every business-critical machine in a Recovery Services vault, a known recovery time confirmed by a test restore, and backup as a deployment default so the gap cannot quietly reopen.

Back to the library

Part of the learning path Build in Azure resilience

Turn on Azure Backup for your virtual machines

Backing up your VMs: the basics

The machine that was load-bearing by accident

Finding unprotected VMs across a subscription

How Azure Backup actually protects a VMdeep dive

What is the impact of leaving a VM unbacked?

How do you protect the estate without over-spending?

1. Inventory every VM against what is already protected

2. Classify each VM by cost-of-downtime

3. Attach each machine to a vault and a matching policy

4. Make backup a deployment default

Quick quiz

Keep learning

Backing up your VMs: the cost and downtime view

The machine that was load-bearing by accident

How a finance partner frames the backup decision

Why an unbacked VM belongs on the downtime risk register

What finance can do about the backup gap

1. Price protection per machine, not per finding

2. Order the work by cost-of-downtime, not by finding count

3. Require documented exceptions for deliberately unprotected machines

Quick quiz

Keep learning

Backing up your VMs: the headline

The machine that was load-bearing by accident

What it looks like when an outage is a restore, not a rebuild

Why this is a resilience decision for the board

The leadership move on backup

1. Set a recovery-time target the estate must meet

2. Ask for proof, not assurance

3. Treat the unprotected machines as named, owned exceptions

Quick quiz

Keep learning

Related site reliability lessons