Azure Backup should be enabled for virtual machines

What does the recommendation "Azure Backup should be enabled for virtual machines" check?

Flags any Azure virtual machine that is not registered for protection in a Recovery Services vault, so no scheduled recovery points are being taken. This is an audit-only check: it confirms a backup is configured for the VM, but it does not verify that the most recent job succeeded, that the retention period is adequate, or that the schedule matches your recovery objectives. It also covers only the VM disks captured by Azure Backup; it says nothing about application data on attached file shares, managed disks backed up separately, or workloads running inside the guest such as SQL Server, which need their own protection.

Why does "Azure Backup should be enabled for virtual machines" matter?

An unprotected VM has no clean restore point, so a ransomware hit, an accidental disk deletion, a botched in-place upgrade or a corrupted boot volume becomes unrecoverable. You are then left rebuilding from scratch, often without the data, which turns a contained incident into prolonged downtime and possible permanent data loss. Because the gap is silent until you actually need to restore, teams routinely discover a production server was never backed up at the worst possible moment. Enabling Azure Backup gives you isolated, off-host recovery points that survive compromise of the VM itself.

How do I fix "Azure Backup should be enabled for virtual machines"?

1. Enable protection for the VM against an existing Recovery Services vault: az backup protection enable-for-vm --resource-group <rg> --vault-name <vault> --vm <vm-name> --policy-name DefaultPolicy. The default policy takes one backup a day and retains recovery points for 30 days; create a custom policy first if you need longer retention.
2. To prevent the gap recurring, assign the built-in audit policy at the subscription or management group scope so future VMs are caught automatically. Look the definition up by display name rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='Azure Backup should be enabled for Virtual Machines'].name" -o tsv); then az policy assignment create --name require-vm-backup --policy "$pid" --scope <scope>.
3. In Bicep, model the protection so it is reproducible: deploy a Microsoft.RecoveryServices/vaults resource, then a vaults/backupFabrics/protectionContainers/protectedItems resource of type 'Microsoft.Compute/virtualMachines' referencing the VM ID and the backup policy ID, so new machines ship with backup wired in rather than added by hand.

# 1. Enable Azure Backup for an unprotected VM against a vault policy.
#    The vault and a backup policy (e.g. DefaultPolicy) must already exist.
az backup protection enable-for-vm \
  --resource-group rg-prod \
  --vault-name rsv-prod-backup \
  --vm orders-db-vm \
  --policy-name DefaultPolicy

# 2. PostgreSQL backup redundancy is fixed at creation. To remediate the
#    geo-redundancy finding, stand up a new Flexible Server with geo-redundant
#    backup, then migrate. (--geo-redundant-backup is create-only.)
az postgres flexible-server create \
  --resource-group rg-prod \
  --name orders-pg-geo \
  --location uksouth \
  --geo-redundant-backup Enabled \
  --backup-retention 14 \
  --tier GeneralPurpose --sku-name Standard_D2ds_v4

# 3. Ratchet it shut: audit any future VM that has no backup configured.
#    Look the built-in policy up by display name; never hardcode a GUID you
#    have not verified.
pid=$(az policy definition list \
  --query "[?displayName=='Azure Backup should be enabled for Virtual Machines'].name" \
  -o tsv)
az policy assignment create \
  --name audit-vm-backup \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"