Home / Azure

AzureTroubleshootingAdvanced

Sev1: Azure Backup jobs failing across the fleet — no restorable recovery points

Triage a backup outage where many VM backup jobs fail at once. Group failures by error code, fix the common causes (VM agent, extension, snapshot limits, Key Vault access, policy changes) and confirm you have a restorable point again.

Deepak Bhardwaj3 min read

Applies toAzure Backup for Azure VMs, Recovery Services vaults, Azure CLI 2.50+

Why this is Sev1

A backup outage is silent until you need a restore. If the last good recovery point is days old, every other incident becomes riskier. Treat a fleet-wide failure as urgent.

1. Group failures by error

az backup job list -g rg-backup -v rsv-prod --status Failed --start-date 22-10-2026 \
  --query "[].{vm:properties.entityFriendlyName, op:properties.operation, err:properties.errorDetails[0].errorCode, start:properties.startTime}" -o table

AddonAzureBackupJobs
| where TimeGenerated > ago(2d) and JobStatus == "Failed"
| summarize failures = count() by JobFailureCode
| order by failures desc

The KQL needs vault diagnostics sent to Log Analytics in resource-specific mode.

2. Map codes to causes

Error code (examples) Cause Fix
UserErrorGuestAgentStatusUnavailable VM agent not running or outdated Restart/update the Windows or Linux agent
ExtensionSnapshotFailed..., VMSnapshot extension errors Snapshot extension broken Remove the extension; next backup reinstalls it
UserErrorKeyvaultPermissionsNotConfigured Encrypted VMs: Backup lost Key Vault access Grant Backup Management Service access to keys and secrets
UserErrorRequestDisallowedByPolicy A new Azure Policy blocks snapshot or restore point creation Exempt the backup resource group
ExtensionOperationFailedForManagedDisks / snapshot limits Too many disk snapshots or restore points Clean up stale restore point collections
Network errors from the agent NSG/firewall blocks outbound to Azure Storage and Entra ID Allow the required service tags

Exact codes change over time; read errorDetails for the message and recommended action.

3. Common fixes

VM agent:

az vm get-instance-view -g rg-app -n vm-app01 --query "instanceView.vmAgent.{version:vmAgentVersion, status:statuses[0].displayStatus}" -o table

Remove a broken snapshot extension (it is reinstalled at the next backup):

az vm extension list -g rg-app --vm-name vm-app01 -o table
az vm extension delete -g rg-app --vm-name vm-app01 -n VMSnapshot          # Windows
az vm extension delete -g rg-app --vm-name vm-app01 -n VMSnapshotLinux     # Linux

Policy blocking backup — check what was assigned recently:

az policy assignment list --query "[].{name:displayName, scope:scope}" -o table

4. Take an on-demand backup and verify

az backup protection backup-now -g rg-backup -v rsv-prod \
  --container-name "iaasvmcontainerv2;rg-app;vm-app01" --item-name vm-app01 \
  --backup-management-type AzureIaasVM --retain-until 30-11-2026

az backup recoverypoint list -g rg-backup -v rsv-prod \
  --container-name "iaasvmcontainerv2;rg-app;vm-app01" --item-name vm-app01 \
  --backup-management-type AzureIaasVM --query "[0].properties.recoveryPointTime"

Start with the most critical VMs. Then do a file-level or disk restore test on one of them — a successful job is not the same as a working restore.

Prevent it next time

  • Turn on Azure Monitor based alerts for backup failures (built into Backup center) and route them to on-call, not just email.
  • Add a daily report: every protected item with its last successful recovery point age.
  • Test new Azure Policy assignments against the backup resource groups before enforcing them.

Related fixes