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

Lorenzo Bergadano 0 Reputation points
2026-10-26T13:54:49.9266667+00:00

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.

Azure Database for PostgreSQL
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SHOUMIK CHAKRAVARTY 1,230 Reputation points
    2026-10-27T12:11:07.73+00:00

    Hi @Lorenzo Bergadano - welcome to the Microsoft Azure QnA.

    Your backups are ZRS. The documentation does contradict itself, but only one sentence ties redundancy to the HA configuration, and three tie it to the region.

    Q1. Three statements link backup redundancy to the region with no HA condition, and two of them sit on the same Backup and restore page as the sentence that says otherwise.

    • The overview says backups are stored in ZRS or LRS “depending on the region”.
    • The FAQ says ZRS “in regions where multiple zones are supported”.
    • The reliability guide adds “regardless of the server’s high-availability configuration”.

    That same guide also describes recovery for a server with same-zone HA as restoring zone-redundant backups into another zone, which contradicts the outlier sentence for one of the two configurations it names. Italy North supports availability zones in the Azure regions list, so your server falls on the ZRS side.

    A likely source of confusion: the reliability guide also says each zone keeps data files and WALs on premium managed disks with locally redundant storage. That refers to the server’s own storage, not backup storage, and they read similarly at a glance.

    Q2. Nothing exposes the redundancy directly. It helps to separate two needs.

    • If you only want to know how the service behaves, the region decides it and no case is needed.
    • If you need a server-specific attestation for audit or compliance, documentation of intended behavior will not serve as one, and a support case is the correct route.

    Q3 and Q4 are already answered correctly above, and the restore FAQ states Q3 plainly: “Yes. If the region supports multiple availability zones, the backup is stored on a zone-redundant storage account so that you can restore to another zone.”

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

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-10-26T13:56:05.9066667+00:00

    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
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.