# Azure VM Backup Not Enabled > RC-267 fires when a running Azure VM is absent from the protected-items set of every Recovery Services vault the discoverer enumerated, stamping backup_enabled false. A ransomware event or accidental deletion then has zero restore points to fall back on. When the lookup set could not be fetched, the rule abstains instead of guessing. Source: https://zop.dev/integrations/azure/recommendations/azure-vm-backup-not-enabled Updated: 2026-08-19 --- ## The gap only shows up on restore day Nobody notices a missing backup until the moment they need one: a deleted VM, a corrupted OS disk, an encrypted filesystem after a ransomware run. At that point the difference between "restore last night's recovery point" and "rebuild from documentation" is whether Azure Backup was configured months earlier. A VM outside every Recovery Services vault has no recovery points at all, and snapshots someone took manually don't count unless a policy keeps taking them. ## Protected items, and how absence is proven Azure Backup models each backed-up VM as a protected item inside a Recovery Services vault. ZopNight's discoverer fetches the protected-items lookup set across the subscription and stamps `backup_enabled` per VM: `"false"` is emitted only when the set was actually fetched and the VM was missing from it. The rule fires on that authoritative false alone, and only for VMs whose provisioning state is Succeeded, so a deallocated relic doesn't generate backup findings. An earlier tag-based contract had no producer writing it, which left the rule dead on real data; the metadata rewrite is what made it fire. ## When the rule refuses to speak Two abstain paths matter. If the VM is not running, nothing fires. If the protected-items lookup never completed (credentials missing the vault read, or a transient error) the metadata key is simply absent and the rule stays quiet. A credential gap therefore produces missing coverage, never fabricated findings, which is the difference between an inventory tool you can audit against and one you have to second-guess. ## Interrogate backup state for one VM ```bash az backup protection check-vm \ --vm $(az vm show -g -n --query id -o tsv) ``` An empty response means no vault protects the VM; a vault resource ID means one does. ## Enabling protection without over-spending Pick or create a vault in the VM's region, apply a daily policy, and verify the first recovery point completes. Backup storage does bill, so pair enablement with a sane retention window rather than the maximum. Detection here is Reader-only; ZopNight never enrolls VMs into vaults itself.