Dev and test MySQL Flexible Servers keeping more than 7 days of backups

When MySQL backup storage stops being free

The backup and restore docs give every Flexible Server a backup retention period between 1 and 35 days, with 7 as the default. Backup storage up to 100% of the server’s provisioned storage is included at no extra cost, and anything above that is billed per GB per month. Microsoft’s own example: a 250 GB server gets 250 GB of free backup storage, which at 25 GB of daily backup usage covers about 10 days.

Longer retention means more snapshots and more transaction log backups kept, and busy servers generate log backups quickly. Microsoft also notes that backup storage used on a geo-redundant server is twice that of a locally redundant one. On a sandbox database nobody will ever restore to day 30, that extra storage is spend with no purpose.

Finding long retention on non-production servers

Print the backup and storage settings for each server; the backup object carries the retention period and whether geo-redundant backup is on:

az mysql flexible-server list -o json | jq '.[] | {name, resourceGroup, backup, storage}'

Then compare consumed backup storage against the provisioned size:

az monitor metrics list \
  --resource /subscriptions/<sub>/resourceGroups/my-rg/providers/Microsoft.DBforMySQL/flexibleServers/my-dev-db \
  --metric backup_storage_used --aggregation Maximum --interval PT24H --offset 30d

Conditions for a finding on a Flexible Server

1. The server name marks it as non-production: it contains dev, test, qa, staging, sandbox or demo. Names that point to tooling, such as devops, runner, agent, bastion or jumpbox, do not count.
2. The retention period, read from the server’s backup configuration, is longer than 7 days.
3. Azure Monitor reports backup storage used for the server, and that figure is larger than its provisioned storage. Only the part above the free allowance can be saved.
4. A per-GB backup storage rate is available for the server’s redundancy: geo-redundant when geo backup is enabled, locally redundant otherwise.

Servers left without a recommendation

Production-named and neutral-named servers are not evaluated, because shortening a production recovery window is a business decision, not a cost tweak. A server whose backups still fit inside the free allowance produces nothing, since trimming retention there saves no money. When the backup metric or the backup storage rate for the region is missing, ZopNight does not fall back to a share of the server bill; it simply raises no finding.

Pricing the excess backup gigabytes

billable GB   = max(0, backup storage used - provisioned storage)
excess share  = (retention days - 7) / retention days
monthly saving = billable GB x excess share x backup rate per GB-month
                 capped at the server's monthly cost

The excess share assumes backup volume is spread evenly across the retention window, so cutting from 21 days to 7 removes two thirds of the billable excess.

Shortening retention on a dev server

1. Confirm with the owners that no one relies on restoring this server further back than 7 days.
2. Reduce retention: az mysql flexible-server update --resource-group my-rg --name my-dev-db --backup-retention 7.
3. Check the backup storage metric after a week; it should settle near the new window.