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

Question

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

Torben Strüver 0

Problem description

I am using the preview feature of Azure Backup for PostgreSQL Flexible Server v2 on a development server and have observed that daily backup durations are roughly the same regardless of small changes in data. I want to understand if this is expected behavior, especially when planning to enable this on a larger production server of about 4 TB.

Environment

Azure Database for PostgreSQL flexible server, backup feature under test: Azure Backup for PostgreSQL flexible server and elastic cluster v2 (preview), backup type: PhysicalBackup, testing on a development flexible server.

What I've already tried

I performed a pilot test of the preview backup feature on a development PostgreSQL flexible server. I compared the first backup with subsequent scheduled daily backups and noticed they took approximately the same amount of time, despite minimal data changes. No restore failures were reported. The case materials indicate that v2 uses physical backups from managed disk snapshots and performs incremental backups after the initial full backup, but do not provide guidance on how backup duration correlates with data changes.

Current status

I am seeking clarification on whether the observed backup duration behavior is expected for this preview feature, especially regarding its implications for scaling to larger servers, and how to accurately estimate backup times for planning purposes.

VEMULA SRISAI 14,070 Reputation points Microsoft External Staff Moderator

2026-10-09T09:36:25.7266667+00:00

Hello Torben Strüver,

Thank you for the detailed description and for testing the Azure Backup for PostgreSQL Flexible Server and Elastic Cluster v2 preview.

The behavior you observed can be expected with the current v2 architecture. The first backup is a full** **backup, while subsequent backups are incremental. For subsequent backups, Azure Backup transfers only the changed data blocks from the managed disk snapshots. If the previous snapshot required for the incremental chain is unavailable, Azure Backup automatically performs initial replication again.

However, incremental** backup does not mean that the overall backup duration will decrease proportionally to the amount of changed PostgreSQL **data. Microsoft currently documents the incremental data movement behavior, but it does not document a formula or guaranteed relationship between the amount of changed data and the total elapsed backup-job duration. Therefore, seeing similar durations between the initial and subsequent backups does not, by itself, establish that each backup is transferring the full dataset.

Another important point is that a v2 backup job is considered successful after the managed disk snapshot has been copied to the Backup vault.

Regarding the planned 4-TB** production server, this size is within the documented v2 limits. The preview currently supports up to 32 TB with Premium SSD v1 and 64 TB with Premium SSD **v2, subject to the other requirements in the support matrix.

For capacity and backup-window planning, I would therefore recommend using a representative production-like test rather than extrapolating the duration observed on the smaller development server. In particular, compare multiple backup cycles under typical and higher data-change workloads and validate the corresponding restore behavior.

Since this capability is currently in** **preview, the published documentation does not provide a supported calculation for predicting how long a 4-TB backup will take based only on database size or daily changed-data volume.
Torben Strüver 0 Reputation points

2026-10-09T09:50:53.9066667+00:00
Hello @VEMULA SRISAI

Thank you. I understand there is no published formula. But I would at least expect an incremental backup being faster than the full one. This is what I see for my dev instance which has 256GB SSD P15 and 64GB in use:

First initial self triggered backup: : 2 h 58 min

First nightly scheduled backup (7GB was written between initial and this backup): 2 h 03 min

Second nightly backup (9GB was written between first nighly and this backup): 2 h 43 min

For me this looks like not incremental at all but as full disk-backups every time.

Can I get support from Second or third level support to investigate my backup-runs to see why an incremental backup taks as long as a full backup?
VEMULA SRISAI 14,070 Reputation points Microsoft External Staff Moderator

2026-10-09T15:56:40.9333333+00:00

Thank you for providing the backup timings and the amount of data written between each backup. This additional information helps clarify your concern.

I will investigate these backup runs further from our side and update you with the findings as soon as possible. If I need any additional details, such as job IDs or run timestamps, I'll reach out to you through a private message.

1 answer

Your answer

Torben Strüver 0 Reputation points

2026-10-09T09:50:53.9066667+00:00

Hello @VEMULA SRISAI

Thank you. I understand there is no published formula. But I would at least expect an incremental backup being faster than the full one. This is what I see for my dev instance which has 256GB SSD P15 and 64GB in use:

First initial self triggered backup: : 2 h 58 min

First nightly scheduled backup (7GB was written between initial and this backup): 2 h 03 min

Second nightly backup (9GB was written between first nighly and this backup): 2 h 43 min

For me this looks like not incremental at all but as full disk-backups every time.

Can I get support from Second or third level support to investigate my backup-runs to see why an incremental backup taks as long as a full backup?
VEMULA SRISAI 14,070 Reputation points Microsoft External Staff Moderator

2026-10-09T15:56:40.9333333+00:00

Thank you for providing the backup timings and the amount of data written between each backup. This additional information helps clarify your concern.

I will investigate these backup runs further from our side and update you with the findings as soon as possible. If I need any additional details, such as job IDs or run timestamps, I'll reach out to you through a private message.

Answer 1

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

Torben Strüver 0 Reputation points

2026-10-09T12:34:59.18+00:00

Thanks for your answer. So I'll perform a test in prod to see the performance of incremental backups. The current estimation based on dev would lead to a runtime of more than once day, what would be bad...

Are you able to raise the request against the backup support? I just make my first experience with the "new" support path where I first had mail ping-pong with AI agents and then it asked me to create a ticket here at this board. I dont actually see any way how to get my ticket to a human support engineer.

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

Problem description

Environment

What I've already tried

Current status

1 answer