Backup failures page someone. Backup absence pages no one. The VM that a teammate spun up six months ago and never enrolled in Azure Backup produces no failed jobs, no alerts, and no red icons anywhere, right up until you need to restore it or an auditor asks the question every audit eventually reaches: "show me proof everything is backed up." Azure has no native alert for "this VM or file share is not in any backup policy," so coverage silently drifts as new resources are created.
Why Azure cannot tell you this out of the box
- Azure Backup alerting is scoped to protected items. Alerts fire on failed backup jobs, restore problems, and deletions, all events on resources that are already in a vault. A resource in no policy generates no jobs, so it generates no alerts.
- Vaults report inward, not outward. Each Recovery Services vault can list what it protects. Nothing computes the complement: everything in the subscription that no vault protects. That answer requires joining the full resource inventory against every vault, and no built-in view does that continuously and tells you about it.
- Coverage drifts by default. Enrollment happens per resource. Unless every creation path (portal clicks, pipelines, one-off scripts) reliably enrolls what it creates, the gap between "exists" and "protected" grows quietly, and there is no daily report saying how wide it has become.
The DIY approach: cross-reference inventory against vaults
The fix is a scheduled anti-join: list everything backupable, list everything protected, and report the difference somewhere people actually look.
- Inventory backupable resources with Azure Resource Graph: virtual machines and Azure Files shares (via their storage accounts).
- List protected items across every Recovery Services vault in the
subscription. Resource Graph exposes these in the
RecoveryServicesResourcestable, so both sides of the join can come from one API. - Anti-join and classify. Anything in the inventory with no matching protected item is unprotected. While you are there, check the protected side too: an item whose last backup is unhealthy is failing, and one whose newest recovery point is older than your threshold is stale. All three are coverage gaps; only the first is invisible to native alerting.
- Run it on a schedule (a timer-triggered Function or an Automation runbook) and post the gaps to a Teams channel, because a report nobody reads protects nothing.
Three details will bite you if you skip them. Resource Graph paginates, so follow the results to the end or large subscriptions silently truncate. Azure Files protection is registered against the parent storage account, so match shares to their account rather than looking for the share itself. And Azure SQL databases are covered by built-in point-in-time restore rather than Recovery Services vaults, so do not flag them as unprotected just because no vault claims them.
A ready-made option: Backup Auditor
Backup Auditor is that pattern packaged. Every day at 07:00 UTC it inventories backupable resources through Azure Resource Graph, reads protected items across all Recovery Services vaults in the subscription, classifies each resource as unprotected, failing, or stale, and posts a coverage percentage plus the itemised gaps to your Teams channel as an Adaptive Card. That daily report is the compliance artifact auditors ask for. It is read-only, running with Reader and Backup Reader roles only, so it never changes backup configuration.
Key facts
- Native alert for "not in any backup policy": none. Azure Backup alerts cover protected items, not never-enrolled resources.
- Durable fix: a scheduled anti-join of the resource inventory against every vault's protected items, delivered to a channel people read.
- Three gap types: unprotected (in no policy), failing (last backup not healthy), stale (newest recovery point too old).
- Edge cases: Azure Files protection lives on the storage account; Azure SQL uses built-in point-in-time restore, not vaults.
- Least privilege: the whole check needs Reader plus Backup Reader, both read-only.
Related reading: find orphaned Azure resources still costing you money.
Written by the team at Katabarwa Labs. We build small, single-purpose Azure tools that run entirely inside your own tenant. Questions: abaho@llmgraph.ai.