# When Azure PostgreSQL needs a backup vault

> Azure's built-in PostgreSQL backups stop at 35 days and outlive a deleted server by five. Which production databases need a Backup vault, and what it costs.

Published: 2026-10-17
Author: Ivan Vydrin
Tags: Azure, Cloud
Canonical: https://www.techfabric.com/blog/azure-backup-postgresql-flexible-server-vaulted-preview

---

Any application going into production on Azure Database for PostgreSQL should be able to answer two questions in its security review: what happens to the data if someone deletes the server, and can you restore records from last year? With Azure's built-in backups alone, the answers are bad. Those backups stop at 35 days and are gone five days after the server is deleted ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/postgresql/backup-restore/how-to-restore-deleted-server)), so stolen admin credentials, a careless cleanup script or an auditor's request becomes a lost database or a failed audit.

Azure Backup closes that gap by keeping copies in a separate vault for up to 10 years, and its v2 preview, announced on 5 October 2026, extends it to databases up to 32 TB with daily backups. Here's how we'd decide which of your production databases need a vault, what it costs, and how long a restore takes.

## What the built-in backups already cover

For everyday mistakes, such as a bad deploy or a dropped table, the built-in backups are the better tool and we'd keep them on every server. Azure snapshots the disks daily and keeps the transaction log, so you can restore to within about five minutes of any moment in the last 7 to 35 days, and backup storage up to the size of the disk costs nothing extra. A restore always creates a new server and never overwrites the old one, and its recovery point is minutes old where a vault's is a day old at best.

The gap is what happens around the server itself. After a deletion there's a five-day window to revive it, from the subscription the deletion came from, and Microsoft says that restore "isn't always guaranteed". Its suggested guard is a management lock on the server, which stops the careless script and does nothing against someone with the rights to remove the lock first.

## When a vault is worth it

We'd add vaulted backup to a server when at least one of these is true, and skip it when none are.

| Requirement | Built-in backups | Vaulted backup |
| --- | --- | --- |
| Restore data older than 35 days | No | Up to 10 years |
| Backups survive deletion of the server | Five days, best effort, same subscription | Yes, for the full retention period |
| Backups held outside the server's subscription | No | Vault can sit in another subscription of the same tenant |
| Nobody, admins included, can delete recovery points early | No | Yes, with vault immutability locked |
| Recovery point within minutes | Yes (about 5 minutes) | No, one day at best |

The first row is usually a retention clause in a contract or a regulation. The middle three are the ransomware and insider-risk questions we'd expect from an insurer or a tabletop exercise. If your only requirement is the last row, the built-in backups already meet it and a vault adds cost without adding recovery.

## Choosing v1 or the v2 preview

Azure Backup now protects flexible servers two ways, and one server can be on only one of them ([v2 overview](https://learn.microsoft.com/en-us/azure/backup/backup-azure-postgresql-flex-server-elastic-cluster-v2-overview), [v2 support matrix](https://learn.microsoft.com/en-us/azure/backup/backup-azure-postgresql-flex-server-elastic-cluster-v2-support-matrix)).

| | v1 (generally available) | v2 (preview) |
| --- | --- | --- |
| How it backs up | Logical, `pg_dump`, a full backup every time | Physical, managed disk snapshots, incremental after the first |
| Largest server | 1 TB | 32 TB on Premium SSD v1, 64 TB on Premium SSD v2 |
| Schedule | One backup a week | Daily or weekly |
| Restore | As files to a storage container, then import with native tools | As a server, onto a target you create first |
| Premium SSD v2 servers | Not supported | Supported |
| PostgreSQL versions | No minimum listed | 15 and later |
| Compute tier | No restriction listed | General Purpose and Memory Optimized only |
| Elastic clusters | No | Yes, up to 8 nodes |

The size, disk and schedule rows decide most cases. A server over 1 TB, or one on Premium SSD v2 at any size, has no vaulted option except v2, provided it's in a region the preview covers (the support matrix excludes a few, among them Southeast US, Southwest US, Mexico Central and West India). A server under 1 TB that only needs a monthly or yearly point for an auditor is well served by v1 today, with general availability behind it, though every weekly v1 backup is a full dump and the vault fills accordingly.

A `pg_dump` file from v1 restores into a different PostgreSQL major version. A v2 recovery point restores only onto the major version it was taken on, and the support matrix adds that restores from backups taken on versions no longer supported aren't guaranteed. For a seven-year archive of a PostgreSQL 15 server, that's the real risk, and it's why we'd keep a yearly logical export of anything with a legal retention period alongside the v2 points.

Moving a protected server from v1 to v2 is one-way. The v1 recovery points stay and restore as files, but going back means stopping protection and deleting the backup instance, which no one should want to do to a vault holding years of history. During the preview we wouldn't move a server that v1 already covers well.

## How a v2 backup moves into the vault

Only the first backup copies the whole disk; after that the vault receives the blocks that changed since the last snapshot. The catch is that a full copy happens again whenever the snapshot chain breaks, without anyone asking for it, so the cost and duration of a first backup isn't a one-off.

```mermaid
%% caption: How a scheduled v2 backup turns a disk snapshot into a recovery point in the vault, and where a restore lands.
flowchart TD
 A["Scheduled backup runs"] --> B["Managed disk snapshot taken"]
 B --> C["Compared with the previous snapshot"]
 C --> D["Changed blocks copied to the vault"]
 D --> E["Recovery point, isolated and optionally immutable"]
 E --> F["Restore onto an empty, matching server"]
 class E accent
```

Schedule the first backup like a migration. Microsoft says the one-day recovery point objective isn't guaranteed, because an initial replication of a large server can take more than a day, and so can daily runs on servers with heavy churn or on Premium SSD v2.

## What it costs

Both versions bill two meters. A protected instance fee is charged per 250 GB of server size, and a storage fee covers what the vault holds, priced by the vault's redundancy. The Azure Backup pricing page lists one PostgreSQL table, priced per 250 GB, for flexible servers and elastic clusters on either version, and says restores from the standard tier are free of transaction and egress charges ([Azure Backup pricing](https://azure.microsoft.com/en-us/pricing/details/backup/)). On East US list prices, Azure's retail price list has the PostgreSQL protected instance at $7.50 a month per unit, and standard-tier backup storage at $0.0224 per GB-month on LRS, $0.028 on ZRS and $0.0448 on GRS ([Azure retail prices](https://prices.azure.com/api/retail/prices?$filter=serviceName%20eq%20%27Backup%27%20and%20armRegionName%20eq%20%27eastus%27)). Other regions differ, so we'd rerun the numbers in the pricing calculator for yours.

As a worked example on those list prices, a 2,000 GB server is eight units, $60 a month in instance fees. If the vault ends up holding the first full copy plus a year of changed blocks, say 4,000 GB, storage adds about $90 a month on LRS or $179 on GRS. The instance fee is fixed by size, but the storage figure is the one your own change rate decides, and it grows with every daily point you keep.

We'd follow the advice on Microsoft's [v2 overview](https://learn.microsoft.com/en-us/azure/backup/backup-azure-postgresql-flex-server-elastic-cluster-v2-overview#understand-pricing-for-azure-postgresql-flexible-server-and-elastic-cluster-vaulted-backup-v2) and keep daily points for a few months, carrying the long retention on weekly, monthly and yearly points. A policy with 30 daily, 12 monthly and 7 yearly points holds 49 recovery points for a seven-year requirement, against roughly 2,555 if every daily point were kept for seven years.

## How we'd set it up

The portal flow lives under Resiliency. Choose **+ Configure protection**, set the datasource type to **Azure PostgreSQL flexible server/elastic cluster**, pick a vault and a policy, and on the **Datasources** tab choose **v2 (physical backup) (preview)** where the default is **v1 (logical backups)** ([configure backup](https://learn.microsoft.com/en-us/azure/backup/backup-azure-database-postgresql-flex), [migrate to v2](https://learn.microsoft.com/en-us/azure/backup/backup-azure-postgresql-flex-server-elastic-cluster-v2-migrate)). The clicks are quick; the decisions around them take longer.

The vault has to be in the same region as the server, but it can be in a different subscription of the same tenant. We'd put it in a subscription that the application team can't administer, because isolation from the people and credentials that run the server is half of the reason to have a vault.

The vault's managed identity needs roles on the server. The portal checks them on the Datasources tab and offers **Assign missing roles** if you have write access. If you don't, it hands you a role assignment template for a database administrator to run, which is the path we'd expect in any company where backup and database rights sit with different people.

The management-lock problem from earlier, someone with enough rights to undo the protection, is what multi-user authorization on the vault is for. It puts a [Resource Guard](https://learn.microsoft.com/en-us/azure/backup/multi-user-authorization-concept), owned by someone other than the backup admin, in front of critical vault operations such as deleting a backup instance or disabling immutability. The v2 support matrix lists it along with soft delete. We'd turn both on before the first backup.

Immutability goes last. Once it's locked on the vault, no user can alter or delete a recovery point before its retention expires, vault administrators included. That's what an auditor wants, and it's also what makes a retention mistake permanent. Our order would be to let the policy run for a few weeks, have someone accountable sign off the numbers, then lock.

## Restore limits to plan for

You can't restore a v2 recovery point into a server shaped like production, because Azure Backup doesn't provision the target and won't write into one with high availability turned on. You create the target first, and Azure Backup validates it against the recovery point before writing anything. It has to be empty, on the same PostgreSQL major version as the source when the backup was taken, with the same disk type and disk size as the source. It can't be Burstable, can't have high availability or a geo-replica configured, and has to be in the vault's region, though it may be in another subscription.

So a disaster recovery runbook needs a server definition ready to deploy, and we'd keep it in Bicep or Terraform with high availability switched off, then turn high availability back on once the restore finishes. Data in unlogged tables doesn't survive a restore, which matters if anything in the schema uses them for staging.

Restore time scales with the size of the recovery point, because the restore writes a full disk image. Microsoft tells you to plan for a recovery time measured in hours to days on multi-terabyte servers. If the business expects a large database back within an hour, a vault restore can't meet that, and the plan needs a replica or the built-in point-in-time restore as its first line.

After a planned geo-failover, the backup configuration stays with the old primary and its backups start failing. Whoever owns failover needs "reconfigure backup on the new primary" in their runbook.

## Where we'd use it

On a server above 1 TB with a retention or isolation requirement, we'd configure v2 now on a staging copy and run a restore drill. Protect it with a short policy, take an on-demand backup, create a matching empty target from code and restore into it. Time the whole thing. That number, set against the recovery time the business has written down, tells you whether v2 can carry the plan when it reaches general availability.

On production during the preview, we'd keep the built-in backups as the operational recovery path and treat the vault as the long-term and isolated copy. A server under 1 TB that v1 already protects stays on v1 until v2 is generally available.

## Frequently asked questions

### Does Azure Backup for PostgreSQL flexible server support daily backups?

Yes, but only in the v2 preview, which runs daily or weekly with a one-day recovery point objective. The generally available v1 takes one backup a week, and a second scheduled backup in the same week fails.

### How long can Azure keep PostgreSQL flexible server backups?

Built-in backups keep 7 to 35 days. Azure Backup keeps vaulted backups for up to 10 years in both v1 and v2, and v2 lets daily, weekly, monthly and yearly points each have their own retention from 7 days to 10 years.

### Can I restore a vaulted backup to a new server automatically?

No, you have to create the target server first. It must be empty and match the recovery point's PostgreSQL major version, disk type and disk size, and Azure Backup checks that before it writes the restore.

### Do vaulted backups survive if the server is deleted?

Yes, for as long as their retention runs. The v2 support matrix says restore works after the source server has been deleted, whereas the built-in backups of a deleted server are kept for five days and can be revived only from the original subscription, without a guarantee.