Azure Database for PostgreSQL Flexible Server uses huge amounts of space for backups

Question

I have a problem very similar to that described in https://learn.microsoft.com/en-us/answers/questions/5838468/azure-postgresql-flexible-server-backup-storage-gr and this appears to be some sort of error with the Azure Database for PostgreSQL Flexible Server backup operations.
I have followed the steps described in that article but nothing gives me reasons as to why my backup storage is so large.My storage used is 4.64GB. The WAL is 0.487GB and yet my Backup Storage Used has grown from 82.3GB to 223GB over the past 30 days with a peak of 260.8GB.

I am on the minimal backups possible (7 days) and this backup storage is costing approximately £15 a month and caused me to exceed my credit limit last billing month. I am using a B1ms compute size with 32GiB storage size with no high availability.

Answer 1

Hi @Geoffrey Thomas

With the figures you've provided, I agree this deserves a closer look. However, one important distinction is that Backup Storage Used isn't expected to equal your current database/storage size.

For PostgreSQL Flexible Server, backup_storage_used is the combined storage consumed by the retained database backups and log backups within the configured retention window. Azure currently takes daily snapshot backups, with the first being full and subsequent snapshots differential, while WAL/transaction-log backups occur based on workload. Heavy transactional activity can increase backup storage regardless of the current database size.

So your current:

Storage Used: ~4.64 GB

Transaction Log Storage: ~0.487 GB

Backup Storage Used: ~223 GB

Peak Backup Storage: ~260.8 GB

Retention: 7 days

aren't directly comparable. In particular, the current transaction-log storage metric isn't the same as the cumulative amount of WAL generated and archived into backups over the previous seven days.

That said, 223-260 GB of retained backup data for this workload is significant enough that you don't assume it is normal without checking the workload history.

In Azure Monitor → Metrics, put these metrics on the same 30-day timeline:

Backup Storage Used, Storage Used, Transaction Log Storage Used, Write Throughput, and Write IOPS

Look specifically for what happened immediately before each large increase in Backup Storage Used. Bulk UPDATE/DELETE operations, ETL/import jobs, index rebuilds, VACUUM-related activity, and other write-heavy operations can generate considerably more WAL than the resulting database size might suggest.

Also confirm Backup redundancy on the server. Geo-redundant backup storage consumes twice as much backup storage as locally redundant backup storage. Geo-redundancy can only be configured when the server is created, so it's worth confirming even if you don't recall enabling it.

There's another billing detail relevant to your B1ms server: Azure provides free backup storage up to 100% of the server's provisioned storage, not 100% of the amount currently used by the database. Anything above that provisioned-storage allowance is chargeable.

So avoid increasing provisioned database storage just to get a larger free backup allowance until you understand what's driving the backup growth. It might reduce the apparent backup overage, but it wouldn't address whatever is generating the backup volume.

If the 30-day metrics show Backup Storage Used climbing rapidly without corresponding write/WAL activity, or remaining unexpectedly high after enough time has passed for data outside the 7-day retention window to age out, open an Azure Support request for Azure Database for PostgreSQL Flexible Server / Backup and Restore.

Include the server resource ID (privately), region, PostgreSQL version, backup retention of 7 days, backup redundancy setting, timestamps showing the increase from approximately 82.3 GB to 223 GB and the 260.8 GB peak, screenshots/exports of the relevant Azure Monitor metrics, and the associated Cost Management charges.

One limitation is that Azure doesn't expose the individual service-managed backup files. Backup operations/files aren't exposed to end users, so if the metrics don't explain the growth, Azure Support is better positioned to determine what is contributing to the retained backup footprint.

If you can post a screenshot of the Backup Storage Used and Write Throughput/Write IOPS graphs over the same 30-day period, along with whether Backup redundancy is locally/zone redundant or geo-redundant, that should help distinguish high WAL generation from an unexplained service-side backup-storage issue.

References:

Backup and restore in Azure Database for PostgreSQL Flexible Server

Monitor Azure Database for PostgreSQL Flexible Server

---

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.