Recovery Services vault review, a rule that deliberately never fires
What does ZopNight detect here?
RC-1379 evaluates Recovery Services vaults and always abstains: Azure Backup bills a per-protected-instance fee plus per-GB vault storage, and a generic review has no data to split those into a real saving. Three sibling rules deliver the concrete dollars: empty-vault deletion, GRS-to-LRS downgrade, and retention tuning.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1379 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | recovery_vault_idle.go |
Where it applies
The honest thing a review rule can say is nothing
Azure Backup charges on two independent axes: a per-protected-instance fee that stops only when protection is disabled, and a per-GB backup-storage fee that continues until recovery points expire or are deleted. A vault-level “review this” finding has no telemetry to split those axes or to say how much of either is recoverable, so any dollar figure it printed would be invented. ZopNight’s rule keeps its applicability gates but returns nothing, by design. An earlier version emitted $0 findings; the pipeline’s minimum-savings filter silently dropped every one, so the rule was dead in practice. The abstain makes that explicit.
Where the real vault dollars live
Three sibling rules each own one concrete, priceable lever:
- Empty-vault deletion (RC-1392) fires when a vault protects 0 items, saving the vault’s full cost.
- Storage-redundancy downgrade (RC-1393) prices the GRS-to-LRS rate delta from real SKU rates.
- Retention tuning (RC-1382) prices reduced retention as a share of vault storage cost.
Those siblings also share a $50-a-month floor: vaults below it are not worth a disruptive recommendation.
What the rule still watches
The evaluation keeps fetching the BackupHealthEvent series over 30 days as corroborating
context, and vault discovery continues, so if a per-vault waste signal ever reaches the
recommender the gates are already wired. Until then, presence on this page means the vault was
examined and no defensible saving exists at the vault-review level.
Review a vault manually in two commands
az backup item list --vault-name <vault> -g <rg> \ --query "length([])" -o tsvaz backup vault backup-properties show --name <vault> -g <rg> \ --query storageModelType -o tsvZero protected items points at the orphan-vault case; a GRS answer on a dev/test vault points at the redundancy downgrade.
Permissions and posture
Reader covers vault discovery and properties; Monitoring Reader covers the health-event series. Nothing here is auto-remediable: disabling protection and deleting recovery points are data-loss decisions that stay with a human, which is a second reason the generic review declines to nag about them.