Running VMs protected by no Recovery Services vault
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-267 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | vm_backup.go |
Where it applies
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
az backup protection check-vm \ --vm $(az vm show -g <rg> -n <vm> --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.