Azure Backup for PostgreSQL v2 Preview: Physical Backups, 64 TB Support and Restore as Server

What actually changed​

The v2 solution is for Azure Database for PostgreSQL flexible servers and elastic clusters. It takes physical backups from managed disk snapshots instead of logical (pg_dump based) backups. Microsoft's Azure Backup release notes describe the backups as stored in an Azure Backup vault. They say the design lets you protect larger servers, run more frequent vaulted backups, and use incremental backups after the first full backup.

The published feature list includes:

• Incremental backups after the first full: Microsoft says this enables daily protection at multiterabyte scale.
• Restore as Server: a recovery point goes straight to a precreated target server, with no intermediate storage account.
• Retention from 7 days to 10 years: daily, weekly, monthly and yearly recovery points get independent retention rules.
• WORM immutable backups: these are meant to stop recovery points being modified or deleted before their retention period ends.
• Elastic cluster coverage: clusters can be protected alongside flexible servers.

v1 versus v2 at a glance​

The support matrix for the generally available v1 solution shows why v2 matters. It also confirms that v1 stays available.

The v1 documentation spells out some of the pain points. If you configure backup on a server larger than 1 TB, the backup operation fails. A second weekly backup in the same week also fails. v1 restores land as files in a storage container, and you then rebuild a server with native PostgreSQL tools.

How this fits with built-in PostgreSQL backups​

This is not the first backup feature for flexible server. The service already takes automatic snapshot backups and supports point-in-time recovery. Microsoft's PostgreSQL documentation puts built-in retention at a maximum of 35 days. Azure Backup vaulted protection is the separate long-term layer. Microsoft describes long-term retention as independent of, or alongside, the automated backups, and it stores backups in separate security and fault domains. If the source server or subscription is compromised, the vaulted copies stay safe.

In practice, v2 doesn't replace point-in-time recovery for fast operational restores. It adds a recovery layer for compliance retention, ransomware and rogue-admin scenarios, and databases too large for v1.

Who should care​

• Teams with servers over 1 TB: v1 couldn't protect these. An internal engineering ticket from a UK public-sector team (the hmcts roadmap repository) shows one way to react. It plans a sandbox spike comparing v2 with v1, and it inventories instances that v1 can't protect and flags them as at risk.
• Elastic cluster users: elastic clusters went generally available in November 2025 according to Microsoft's release notes, but v1 vaulted backup didn't cover them.
• Premium SSD v2 users: v1 vaulted backup didn't support this storage tier either.
• Compliance-driven shops: daily schedules and WORM immutability address common audit asks. Microsoft's material doesn't say how the immutability settings are configured.

What Microsoft hasn't said yet​

The material I reviewed leaves several practical questions open. Check the dedicated v2 documentation before relying on any of them:

• Supported regions and PostgreSQL engine versions.
• Pricing for the preview and for vault storage.
• Permissions, networking prerequisites, and whether separate registration is needed.
• Whether v1 and v2 can protect the same server, and how to migrate between them.
• Whether the restore target must match the source's region, subscription or configuration. The target must be precreated, so don't assume the feature provisions or overwrites a server for you.
• Measured backup or restore durations. Microsoft publishes a one-day RPO, but no restore-time guarantees.

A sensible evaluation plan​

1. Pick a non-production server, ideally one that mirrors a workload v1 can't cover, such as one over 1 TB, on Premium SSD v2, or an elastic cluster.
2. Create a vault and a daily policy with the retention tiers you'd actually need.
3. Precreate a target server and run Restore as Server.
4. Record how long the restore takes, then validate the data and application connectivity.
5. Compare the results with your recovery objectives. Microsoft's own guidance for the long-term retention feature is to test backup and restore right after configuring it.
6. Keep point-in-time recovery and your disaster recovery plan in place while the feature is in preview.

Bottom line​

The v2 preview closes the biggest gaps in v1: the 1 TB ceiling, weekly-only backups, no elastic cluster or Premium SSD v2 support, and file-based restores. It is still preview software with several unanswered operational questions. Test it now, and don't put production recovery on it yet.