[{"data":1,"prerenderedAt":10},["ShallowReactive",2],{"public:public\u002Fcontent\u002Fdocs\u002Fazure-postgres-flexible-backup":3},{"slug":4,"title":5,"description":6,"draft":7,"updated":8,"html":9},"azure-postgres-flexible-backup","Azure Backup for PostgreSQL Flexible Server","Restore Azure Backup vaulted backups of PostgreSQL Flexible Server as files to a storage container and let Verestore test the database file.",false,null,"\u003Ch1>Azure Backup for PostgreSQL Flexible Server\u003C\u002Fh1>\n\u003Cblockquote>\n\u003Cp>Verified against the provider's documentation, not against a live account.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>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: \u003Cstrong>Azure Backup vault → Restore as files to a storage container → Verestore tests the database file\u003C\u002Fstrong>. A dump in a container you control is also the copy that survives if the server or vault does not.\u003C\u002Fp>\n\u003Ch2>1. Prepare the target storage account\u003C\u002Fh2>\n\u003Cp>Microsoft's restore-as-files requires the target storage account to have:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ccode>AllowCrossTenantReplication\u003C\u002Fcode> set to \u003Ccode>true\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Permitted scope for copy operations\u003C\u002Fstrong> set to \u003Cstrong>From any storage account\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>public network access, so the vault can reach it\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode class=\"language-sh\">az storage account update --name ACCOUNT --resource-group RG \\\n  --allow-cross-tenant-replication true\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>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 \u003Ccode>acme-backups\u003C\u002Fcode>. Hosted Verestore runs also need public network access to the account: see \u003Ca href=\"\u002Fdocs\u002Fazure-blob\">Azure Blob Storage\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>2. Restore as files\u003C\u002Fh2>\n\u003Cp>Restore a recovery point with \u003Cstrong>Restore as files\u003C\u002Fstrong>, choosing the container (and a folder such as \u003Ccode>orders\u002F\u003C\u002Fcode>) as the destination. See \u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fbackup\u002Frestore-azure-database-postgresql-flex\">Microsoft's restore guide\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>According to Microsoft, the restore writes \u003Ccode>.sql\u003C\u002Fcode> files:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>File\u003C\u002Fth>\n\u003Cth>Contents\u003C\u002Fth>\n\u003Cth>Used by Verestore\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>one database file per database\u003C\u002Ftd>\n\u003Ctd>data and schema of that database\u003C\u002Ftd>\n\u003Ctd>yes: the file that is tested\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>roles file\u003C\u002Ftd>\n\u003Ctd>server-level roles of the instance\u003C\u002Ftd>\n\u003Ctd>no, skipped\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>tablespace file\u003C\u002Ftd>\n\u003Ctd>tablespaces\u003C\u002Ftd>\n\u003Ctd>no, skipped\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>schema file\u003C\u002Ftd>\n\u003Ctd>schema of all databases\u003C\u002Ftd>\n\u003Ctd>no, skipped (Microsoft says not to run it: the schema is already in each database file)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>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.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Microsoft's own instructions restore the database file with \u003Ccode>pg_restore ... --no-owner\u003C\u002Fcode>, which implies \u003Ccode>pg_dump\u003C\u002Fcode> custom format despite the \u003Ccode>.sql\u003C\u002Fcode> 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 \u003Ccode>.sql\u003C\u002Fcode> is also checked against the compressed size guard.\u003C\u002Fp>\n\u003Ch2>3. What Verestore does with the companion files\u003C\u002Fh2>\n\u003Cp>When it selects the newest blob under the prefix, Verestore skips the companion files automatically: names \u003Ccode>roles.sql\u003C\u002Fcode>, \u003Ccode>schema.sql\u003C\u002Fcode> and \u003Ccode>tablespace.sql\u003C\u002Fcode>, or ending in \u003Ccode>_roles.sql\u003C\u002Fcode>, \u003Ccode>-roles.sql\u003C\u002Fcode> (and the same for schema and tablespace), case-insensitive.\u003C\u002Fp>\n\u003Cp>It never runs the roles file. Custom-format dumps are restored with \u003Ccode>--no-owner --no-privileges\u003C\u002Fcode>. Plain SQL dumps that reference roles missing from the scratch server (for example \u003Ccode>azure_pg_admin\u003C\u002Fcode> or \u003Ccode>azuresu\u003C\u002Fcode>) get them created as \u003Ccode>NOLOGIN\u003C\u002Fcode> roles, reported as warnings in the run.\u003C\u002Fp>\n\u003Ch2>4. One target per database\u003C\u002Fh2>\n\u003Cp>If the server has several databases, their database files land together. Add one Verestore target per database:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>point the prefix at one database's file name prefix, if the names allow it (for example \u003Ccode>orders\u002Forders\u003C\u002Fcode>), or\u003C\u002Fli>\n\u003Cli>restore as files into a folder or container per database.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>5. Automate the restore before each test\u003C\u002Fh2>\n\u003Cp>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 \u003Cstrong>before\u003C\u002Fstrong> the Verestore schedule:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sh\">az dataprotection backup-instance restore trigger \\\n  --resource-group RG --vault-name VAULT \\\n  --backup-instance-name INSTANCE \\\n  --restore-request-object restore-as-files.json\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>See Microsoft's CLI reference for the restore-as-files request body (\u003Ccode>az dataprotection backup-instance restore initialize-for-data-recovery-as-files\u003C\u002Fcode> builds it from a recovery point and the target container URL). Each restore writes new blobs, so Verestore picks the newest one.\u003C\u002Fp>\n\u003Ch2>6. Give Verestore read access\u003C\u002Fh2>\n\u003Cp>Create a read-only SAS token or a service principal for the container as described in \u003Ca href=\"\u002Fdocs\u002Fazure-blob\">Azure Blob Storage\u003C\u002Fa>, then add the target:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Storage account URL: \u003Ccode>https:\u002F\u002F<account>.blob.core.windows.net\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>Container: \u003Ccode>acme-backups\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>Prefix: \u003Ccode>orders\u002F\u003C\u002Fcode> (or the database's file name prefix)\u003C\u002Fli>\n\u003Cli>Access with: SAS token (read + list) or service principal (Storage Blob Data Reader)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>7. For your own disaster-recovery restores\u003C\u002Fh2>\n\u003Cp>Verestore does not need the roles file. When you restore to a real server yourself, Microsoft documents cleaning \u003Ccode>roles.sql\u003C\u002Fcode> first; it removes Azure service roles and superuser-only attributes:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sh\">sed -i '\u002Fazure_superuser\u002Fd; \u002Fazure_pg_admin\u002Fd; \u002Fazuresu\u002Fd; \u002F^CREATE ROLE replication\u002Fd; \u002F^ALTER ROLE replication\u002Fd; \u002F^ALTER ROLE\u002F {s\u002FNOSUPERUSER\u002F\u002F; s\u002FNOBYPASSRLS\u002F\u002F;}' roles.sql\n\u003C\u002Fcode>\u003C\u002Fpre>\n",1794290783588]