Managed disks with no Azure Disk Backup protection
What does ZopNight detect here?
Managed disks with no standalone Azure Disk Backup instance are flagged by RC-1327 via the discoverer's backup_enabled flag, resolved from Microsoft.DataProtection backup vaults. Disks protected only through their VM's Recovery Services backup are a known false-positive gap, and an absent flag makes the rule abstain.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1327 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | disk_backup.go |
Where it applies
What “no backup” means in this finding
The discoverer answers a narrow question: does a standalone Azure Disk Backup instance exist for this disk? It runs a secondary Resource Graph lookup across Microsoft.DataProtection backup vaults, filters the backup instances to the managed-disks datasource type, and stamps backup_enabled on each disk accordingly. RC-1327 fires only when that flag is an explicit “false”. An unprotected disk is one incident (accidental deletion, filesystem corruption, ransomware) away from unrecoverable data loss, which is the whole exposure here: not a leak, but an absence of any road back.
List what a backup vault actually protects
az dataprotection backup-instance list \ --vault-name <vault> -g <rg> \ --query "[].{name:name, datasource:properties.dataSourceInfo.datasourceType}" -o tableDisks missing from every vault’s instance list are the ones this rule sees as unprotected.
The VM-backup blind spot, stated plainly
There is a known false-positive class you should check before acting. The lookup covers standalone Disk Backup only. It does not cross-reference Recovery Services vaults, where whole-VM backup lives. A disk attached to a VM that is backed up at the VM level is genuinely protected, but this rule still stamps it “false” and fires. The gap is producer-side and tracked separately; until it closes, triage each finding by asking whether the attached VM already has a backup policy. The inverse error does not happen: when the discovery lookup fails transiently, the flag is simply absent and the rule abstains rather than firing on unknown state.
Choosing a protection mechanism
For disks attached to VMs, VM-level backup in a Recovery Services vault is usually the simpler answer: one policy covers the OS disk and data disks together, and it silences the underlying risk even while this rule’s blind spot mis-flags it. Standalone Disk Backup fits disks that outlive or float between VMs, and supports incremental snapshots without an agent. Automation-driven periodic snapshots are the fallback where neither service fits. Whichever you choose, a backup nobody has restored from is a hypothesis: schedule a test restore before you need a real one.
Detection is read-only under the built-in Reader role, there is no savings figure, and severity sits at medium, a real risk but contingent on data value rather than active exposure.