Azure Backup for PostgreSQL Flexible Server v2 (preview): daily backup duration doesn't scale with changed data — Inquiry about backup behavior and planning

Hi Torben Strüver & thx for join me at Q&A platform,

Yep, this can be expected with PostgreSQL Flexible Server v2 backups. The first backup transfers the full disk contents, while subsequent backups are incremental and only transfer changed blocks. But incremental doesn't automatically mean a much shorter backup job.

The backup process still has to create a managed disk snapshot, wait for it to hydrate, compare it with the previous snapshot, and copy the changes to the Backup vault. Some of that overhead isn't directly related to how much data actually changed, so u can see pretty similar runtimes on a small dev server.

For ur planned 4 TB production server, I wouldn't extrapolate backup duration from the dev environment. The initial full backup could take considerably longer, and daily incremental performance will depend on disk type, actual changed blocks, and snapshot/transfer throughput. Microsoft also notes that the 24-hour RPO isn't guaranteed in every scenario, especially with large initial transfers or high data churn.

I'd test with a representative dataset and realistic daily writes before enabling this in production. Track several consecutive backup jobs, compare transferred data and total duration, and run an actual restore test too. That's gonna give u a much better estimate than database size alone.

Also worth keeping in mind that v2 is still in preview, so I'd ask Azure Backup support for any current performance guidance or known limitations for multi-TB workloads before relying on it for production recovery targets.

rgds,

Alex

Hello Torben Strüver,

Thank you for sharing the results from your Azure Backup for PostgreSQL Flexible Server and Elastic Cluster v2 Preview testing.

Kindly note that the behavior you observed can be expected. In v2, the first backup is a full physical backup. Subsequent scheduled backups are incremental and transfer only changed blocks. However, the overall backup job duration is not determined only by the amount of changed data.

Each scheduled backup still includes platform processing steps such as creating and hydrating the managed disk snapshot, obtaining access to the current and previous snapshots, calculating the difference between them, and copying the required data to the Backup vault. The backup job is marked successful only after the required data has been copied to the vault.

Because these fixed workflow steps still run for each scheduled backup, an incremental backup may take approximately the same wall-clock duration as the initial backup, even when daily data changes are minimal. This does not necessarily indicate that the backup is running as a full backup each time.

For your planned approximately 4-TB PostgreSQL Flexible Server, this size is within the documented v2 supported scale limits. The documented limits are up to 32 TB on Premium SSD v1 and up to 64 TB on Premium SSD v2.

Regarding backup-window estimation, We don't have a fixed throughput rate, sizing calculator, formula, or guaranteed duration estimate for calculating the backup duration of a 4-TB PostgreSQL Flexible Server in v2. Since the total job duration can be influenced by storage type, snapshot processing, data churn, vault copy time, and platform activity during the backup window, the supported recommendation is to run representative production-like testing over multiple scheduled backup cycles and use the measured job durations as the baseline for production planning.

In summary, the similar duration between the initial backup and subsequent incremental backups can be expected due to the end-to-end backup workflow overhead. The 4-TB server size is supported in v2, but there is no published formula or guaranteed estimate for the backup window. The recommended planning method is to validate with representative testing and use observed backup job durations across multiple cycles.