Azure Backup: retention policies that quietly compound

Someone protects a VM, picks the retention a compliance document asked for, and moves on: 30 dailies, 12 weeklies, 12 monthlies, 7 yearlies. The first month's invoice line looks like nothing. Backups are cheap. Seven years of daily backups are not, and that policy is closer to that than it looks: up to 61 recovery points per VM held at the same time, in a vault that was geo-redundant by default, and that keeps billing after the VM is gone.

This is how the bill is actually built: the meters behind it, and why the storage line keeps growing long after the VM count stopped.

Three meters, and one isn't in the vault

Azure Backup charges a protected instance fee for each item and backup storage for what the vault holds. Microsoft's pricing estimator takes used disk size, daily churn, the four retention ranges and the storage redundancy as inputs. There is a third meter that never shows up as vault storage: Instant Restore snapshots. They are stored with the disks and billed as snapshot storage. They can't be turned off, only shortened to one day.

The policy type changes that third meter a lot. Microsoft's own example is a 100 GB VM with 2% daily churn and five days of snapshots. On the Standard policy that's 10 GB of incremental blob snapshots. On the Enhanced policy the first snapshot is a full copy, so the same VM is billed for 108 GB. Enhanced keeps snapshots for 7 days by default and up to 30. And the garbage collector always keeps the latest recovery point, so a policy set to n snapshots can hold n+1, sometimes more. That extra retention is billed too.

Retention is a stack, not a number

The first backup of a VM is full. Every one after it holds only the blocks that changed, and a block counts in full even if only 1 KB of it changed. The storage cost is the sum of all the blocks across all retained recovery points. When a point expires, Azure Backup frees only the blocks that a later retained point has overwritten. Everything else is carried forward. Microsoft says it directly: storage reduction "might not map 1:1 to the number of expired recovery points".

That's the compounding. Each weekly, monthly and yearly point holds that day's version of every block it references, and holds it for as long as the point lives. With high churn, each long-term point is close to a full copy of whatever changed since the last one. A yearly point pins its blocks for seven years, whatever happens to the dailies around it.

Two details make the stack taller than it reads in the policy blade. A 12-month retention is 372 days, not 365: every month counts as 31 days. And shortening retention to save money doesn't save anything for a while. Recovery points removed by a policy change go into soft-deleted state. That's free for the default 14 days, but the soft-delete window can be set as high as 180 days, and every day beyond 14 is billed at normal backup rates.

GRS is the default, and it's frozen

A new Recovery Services vault is geo-redundant by default, and the replication setting is locked once the first backup is configured. Every block in the stack above is copied to a second region and billed at the geo-redundant rate, which costs more than LRS. That includes the dev VM that someone protected with the default vault because it was there.

Moving an existing workload from GRS to LRS isn't a toggle. It's a new LRS vault and a choice: delete the GRS backups, or stop protection with retained data and keep paying for the GRS recovery points until you decide they can go. For a VM, the documented route even involves moving it to another resource group so the new vault treats it as a different machine. The first backup in the new vault is a full copy again.

Archive can make it more expensive

The usual answer to long-term retention is the archive tier. For VMs it has a catch that the tier name hides: only monthly and yearly points qualify, they must be at least 3 months old with at least 6 months of retention left, and moving them converts them from incremental to full. On a low-churn VM the full copies can outweigh the cheaper per-GB rate, and total storage goes up. That's why the portal moves a recommended set of points rather than every eligible one. Once moved, a point can't return to standard permanently, and deleting it before 180 days in archive is billed for the remaining days.

The vaults nobody can delete

This is where most of the waste comes from: VMs decommissioned years ago, each with a backup that Microsoft's own docs say to delete to avoid any additional cost. And the vault holding them is hard to delete on purpose. Protected items, registered servers, storage accounts or anything in soft-deleted state all block the deletion. Soft delete itself is now enforced and can't be disabled on Recovery Services vaults. That's the right call against ransomware, but it means cleaning up takes at least two weeks and a second visit.

That's the implication. The backup bill isn't set by how many machines you protect today. It's set by every retention choice made since the first vault was created, including the ones made by default. On the invoice it shows up as one line that grows a little every month, with no event anyone would notice.

The vault blade shows one vault at a time. It won't tell you which subscription's backup line has been creeping up for a year. GraphPaaS reads Azure spend for each tenant and breaks it down by resource, resource type and resource group, with a month-by-month drill-down, so a vault that grows every month shows up as its own trend. It's the same exercise as hunting orphaned resources, except that these ones are protected from deletion by design.