Azure Database for PostgreSQL Flexible Server: is automated backup storage zone-redundant or locally redundant when HA is disabled (Italy North)?

Question

We run Azure Database for PostgreSQL Flexible Server 16 in Italy North (a region with availability zones), General Purpose, single zone, high availability disabled, geo-redundant backup disabled, 7-day retention. The ARM/CLI properties only expose backupRetentionDays, earliestRestoreDate and geoRedundantBackup, so we cannot read what redundancy the automated backup storage actually has.

The documentation (Backup and Restore concepts page) seems to say two different things. One passage says zone-redundant backup storage is automatically selected for regions that support availability zones. Another passage says that by default the service sets backup storage to locally redundant for servers with same-zone HA or no HA configuration.

Questions:

Q1: For a server with HA disabled in a region with availability zones, are the automated backups (snapshots and WAL) stored in ZRS or LRS?

Q2: Where can this be verified (portal, CLI, REST API, a metric or the activity log)? If it is not exposed, is there an official way to confirm it?

Q3: If it is LRS, does a point-in-time restore into a different availability zone still work if the source zone is unavailable?

Q4: Can the redundancy be changed after creation, apart from geo-redundancy which the docs say can only be set at creation?

Thanks.

Answer 1

For PostgreSQL Flexible Server in Italy North, the current reliability guidance says automated backups are ZRS regardless of whether HA is enabled; however, because other official pages contradict this, Microsoft Support is the only documented way to obtain authoritative confirmation for the effective redundancy of your particular server.

Q1: ZRS or LRS?

ZRS is the intended documented behavior for this configuration.

The reliability documentation states explicitly:

• In a region with availability zones, backups use zone-redundant storage (ZRS), regardless of the server’s HA configuration.
• LRS applies to regions without availability zones. ^1^

Italy North supports zone-redundant HA for PostgreSQL Flexible Server, establishing that the service has multi-zone support there. ^2^

The business-continuity documentation independently says that backups are stored in ZRS when the region supports availability zones, including when the server itself is not configured for zone redundancy. ^3^

Therefore, for the stated Italy North server:

• HA disabled affects compute availability—there is no standby server for automatic failover.
• It does not, under the reliability documentation, reduce automated-backup redundancy to LRS.
• Both snapshot and transaction-log backups belong to the service-managed backup set used for PITR.

There is nevertheless a real documentation inconsistency: the backup concepts page and restore instructions also say that no-HA and same-zone HA servers receive LRS, while only zone-redundant HA receives ZRS. ^4^ ^5^

That HA-dependent statement conflicts directly with the reliability and business-continuity pages. It should not be used to infer that your server is definitely LRS.

Q2: Where can the effective value be verified?

There is no documented customer-visible property for regional LRS versus ZRS redundancy on the Flexible Server resource.

The current ARM schema exposes:

• backupRetentionDays
• geoRedundantBackup

It does not expose an LRS/ZRS field. ^6^

Consequently:

• Portal: No documented blade reports the effective operational-backup LRS/ZRS type.
• CLI/REST/ARM: geoRedundantBackup distinguishes geo-replicated backup from regional backup; it does not identify regional LRS versus ZRS.
• Metrics: Backup Storage Used reports retained snapshot and log consumption, not redundancy. ^4^
• Activity Log: It can show restore-operation progress or completion, but no documentation says it records the backup storage redundancy. ^4^

For a server-specific, auditable confirmation, open an Azure support request from PostgreSQL Flexible Server → Support + troubleshooting → Create a support request. Include:

• Server resource ID
• Region: Italy North
• Creation date
• HA mode: Disabled
• geoRedundantBackup: Disabled
• A request to confirm the effective redundancy of both snapshot and WAL backup storage

Ask Support to reconcile the HA-independent reliability statement with the HA-dependent backup/restore statements.

Q3: Restore to another zone during a source-zone outage

Under the documented ZRS behavior, yes: during a zone failure, a non-zone-redundant server can be restored from the latest restore point into another, unaffected zone. This creates a new server; it is not automatic failover. ^3^

The PITR workflow lets you select the destination availability zone, and PITR remains within the source region. ^5^

If Support were to confirm that this particular server is actually LRS, cross-zone recovery during loss of the backup’s datacenter should not be assumed. LRS stores copies in one datacenter, whereas ZRS provides cross-zone backup availability. In that case, obtain a server-specific recovery commitment from Support or use zone-redundant HA for the required resilience.

Q4: Can redundancy be changed?

The documentation says the backup storage redundancy option cannot be changed after the server is provisioned. Geo-redundant backup must also be selected during server creation. ^4^

Enabling zone-redundant HA later is supported, but that is an HA configuration change, not a documented in-place backup-redundancy control. ^7^

If a different immutable backup configuration is required, the practical path is to create or restore to a new server with the required creation-time settings and then cut over.

---

References

1. Reliability in Azure Database for PostgreSQL
2. What is Azure Database for PostgreSQL flexible server?
3. Overview of business continuity in Azure Database for PostgreSQL flexible server
4. Backup and restore in Azure Database for PostgreSQL flexible server
5. Restore to custom restore point
6. Microsoft.DBforPostgreSQL flexibleServers 2024-08-01 (deployment-language-terraform)
7. Configure high availability for Azure Database for PostgreSQL flexible server