Verestore
Launching shortly

Azure Backup for PostgreSQL Flexible Server

Verified against the provider's documentation, not against a live account.

Azure Backup keeps long-term (vaulted) backups of Azure Database for PostgreSQL Flexible Server in a Backup vault. Verestore cannot read the vault directly, so the flow is: Azure Backup vault → Restore as files to a storage container → Verestore tests the database file. A dump in a container you control is also the copy that survives if the server or vault does not.

1. Prepare the target storage account

Microsoft's restore-as-files requires the target storage account to have:

  • AllowCrossTenantReplication set to true
  • Permitted scope for copy operations set to From any storage account
  • public network access, so the vault can reach it
az storage account update --name ACCOUNT --resource-group RG \
  --allow-cross-tenant-replication true

Set the copy scope in the storage account's configuration (check the provider's current documentation for the matching CLI option). Create a container such as acme-backups. Hosted Verestore runs also need public network access to the account: see Azure Blob Storage.

2. Restore as files

Restore a recovery point with Restore as files, choosing the container (and a folder such as orders/) as the destination. See Microsoft's restore guide.

According to Microsoft, the restore writes .sql files:

File Contents Used by Verestore
one database file per database data and schema of that database yes: the file that is tested
roles file server-level roles of the instance no, skipped
tablespace file tablespaces no, skipped
schema file schema of all databases no, skipped (Microsoft says not to run it: the schema is already in each database file)

The exact file format and file names must be confirmed on a real vault: we have not run this flow against a live Azure Backup vault.

Microsoft's own instructions restore the database file with pg_restore ... --no-owner, which implies pg_dump custom format despite the .sql name, while the same pages call them SQL files. Verestore handles both: it detects custom or plain format from the content, not from the extension, and a custom-format file named .sql is also checked against the compressed size guard.

3. What Verestore does with the companion files

When it selects the newest blob under the prefix, Verestore skips the companion files automatically: names roles.sql, schema.sql and tablespace.sql, or ending in _roles.sql, -roles.sql (and the same for schema and tablespace), case-insensitive.

It never runs the roles file. Custom-format dumps are restored with --no-owner --no-privileges. Plain SQL dumps that reference roles missing from the scratch server (for example azure_pg_admin or azuresu) get them created as NOLOGIN roles, reported as warnings in the run.

4. One target per database

If the server has several databases, their database files land together. Add one Verestore target per database:

  • point the prefix at one database's file name prefix, if the names allow it (for example orders/orders), or
  • restore as files into a folder or container per database.

5. Automate the restore before each test

Azure Backup does not restore to files on a schedule by itself; it is a manual or scripted step. Script it with the Azure CLI on a schedule that runs before the Verestore schedule:

az dataprotection backup-instance restore trigger \
  --resource-group RG --vault-name VAULT \
  --backup-instance-name INSTANCE \
  --restore-request-object restore-as-files.json

See Microsoft's CLI reference for the restore-as-files request body (az dataprotection backup-instance restore initialize-for-data-recovery-as-files builds it from a recovery point and the target container URL). Each restore writes new blobs, so Verestore picks the newest one.

6. Give Verestore read access

Create a read-only SAS token or a service principal for the container as described in Azure Blob Storage, then add the target:

  • Storage account URL: https://<account>.blob.core.windows.net
  • Container: acme-backups
  • Prefix: orders/ (or the database's file name prefix)
  • Access with: SAS token (read + list) or service principal (Storage Blob Data Reader)

7. For your own disaster-recovery restores

Verestore does not need the roles file. When you restore to a real server yourself, Microsoft documents cleaning roles.sql first; it removes Azure service roles and superuser-only attributes:

sed -i '/azure_superuser/d; /azure_pg_admin/d; /azuresu/d; /^CREATE ROLE replication/d; /^ALTER ROLE replication/d; /^ALTER ROLE/ {s/NOSUPERUSER//; s/NOBYPASSRLS//;}' roles.sql