# Azure Managed Disk Without Backup

> 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.

Source: https://zop.dev/integrations/azure/recommendations/azure-managed-disk-without-backup
Updated: 2026-08-19

---

## 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

```bash
az dataprotection backup-instance list \
  --vault-name <vault> -g <rg> \
  --query "[].{name:name, datasource:properties.dataSourceInfo.datasourceType}" -o table
```

Disks 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.