Where backup cost comes from
| Component | Driven by |
|---|---|
| Protected instance fee | Number and size of protected items |
| Backup storage | Data changed × retention, vault redundancy |
| Snapshot storage (instant restore) | Snapshot retention days for VMs |
| Archive tier storage | Long-term points moved to archive |
1. Inventory
// Azure Resource Graph
recoveryservicesresources
| where type == "microsoft.recoveryservices/vaults/backupfabrics/protectioncontainers/protecteditems"
| extend vault = tostring(split(id, "/")[8]), policy = tostring(properties.policyName),
workload = tostring(properties.workloadType), item = tostring(properties.friendlyName)
| summarize items = count() by vault, policy, workload
Then check each policy's retention and which environments use it. Usually one "Default" policy with long retention protects dev and prod alike.
2. Retention by need, not by habit
| Environment / data | Example policy |
|---|---|
| Production with compliance needs | Daily 30d, weekly 12w, monthly 12m, yearly as required |
| Production without long-term requirement | Daily 30d, weekly 8w |
| Dev/test | Daily 7–14d |
| Rebuildable servers (stateless app tier from IaC/images) | Maybe no VM backup at all, protect the data and config instead |
Agree retention with data owners and compliance, document it, and map each policy to a tag (backupTier=gold/silver/bronze).
3. Archive tier for long-term points
Monthly and yearly recovery points (VMs, SQL in VM) that are kept for months or years can move to the vault archive tier, which costs less to store but takes hours to rehydrate and has minimum retention rules. Check which points are eligible:
az backup recoverypoint list -g rg-bkp -v rsv-prod --container-name "<container>" --item-name "<item>" \
--backup-management-type AzureIaasVM --is-ready-for-move true --target-tier VaultArchive \
--query "[].name" -o tsv
Or set it in the policy ("smart tiering" / move recommended points automatically), where supported for the workload.
4. Snapshot retention for VMs
Instant-restore snapshots speed up restores but are billed as snapshot storage. Standard policy allows 1–5 days, Enhanced policy longer. Two days covers most "restore yesterday" requests:
az backup policy show -g rg-bkp -v rsv-prod -n vm-silver --query properties.instantRpRetentionRangeInDays
5. Exclude disks that don't need backup
Temp data, page-file disks, SQL data disks already protected by SQL backup, or large scratch disks:
az backup protection update-for-vm -g rg-bkp -v rsv-prod -c sql01 -i sql01 \
--disk-list-setting exclude --diskslist 2 3 # LUNs to exclude
When SQL Server in Azure VM backup is used, back up the VM's OS disk (and system state) and let the SQL backup protect databases. Don't pay twice for data disks.
6. Vault redundancy per environment
| Vault | Redundancy |
|---|---|
| Production, cross-region restore needed | GRS (with Cross Region Restore if required) |
| Production, single-region tolerance | ZRS or LRS per risk decision |
| Dev/test | LRS |
Storage redundancy can only be changed before the first item is protected; otherwise create a new vault and re-protect (old points stay in the old vault until they expire).
7. Remove what's no longer needed
- Items for deleted VMs still in "stop protection, retain data" state. Decide on deletion with owners.
- Duplicate protection (VM backup plus a third-party agent backing up the same data).
- Old vaults from migrations.
Keep soft delete and immutability on; clean-up must go through the normal delete process, not by disabling protections.
Caution
Cost tuning must not reduce recoverability without sign-off. After any change, run a test restore from each policy tier (see the "Restoring an Azure VM from Azure Backup" post) and keep the evidence.
Checklist
- Protected items by vault, policy and workload
- Retention tiers agreed and mapped to tags
- Archive tier for eligible long-term points
- Snapshot retention reviewed
- Unneeded disks excluded; no double protection
- Redundancy matched to environment
- Orphaned items cleaned up; test restores done