Azure Database for PostgreSQL

To back up an Azure Database for PostgreSQL, Backup connects to its Flexible Server like any other Postgres. Azure runs real PostgreSQL under the hood, so pg_dump works normally. Two Azure specifics are worth knowing before you start: adding a firewall rule so Backup can reach the server, and what a restore test does with Azure's managed extensions.

This guide covers Azure Database for PostgreSQL – Flexible Server, the current deployment option. Single Server is retired, so if you're still on it, migrate to Flexible Server first.

Which connection string

Flexible Server exposes a single public endpoint. The host is always your server name followed by the Azure Postgres domain:

<server-name>.postgres.database.azure.com

The port is 5432. Azure resolves the host to a public IPv4 address, which is what Backup connects over. Always use this fully qualified name rather than an IP address, because Azure's underlying IP can change.

Azure enforces encrypted connections. The server parameter require_secure_transport is ON by default, so a plaintext connection is refused. Set SSL mode to require in Backup. That encrypts the connection without needing a client certificate. Azure doesn't support TLS client certificate authentication, so don't add sslcert or sslkey. If you want Backup to also verify the server's certificate, verify-full works, but require is enough to satisfy Azure's enforcement.

Find the connection details

1. In the Azure portal, open your Azure Database for PostgreSQL flexible server.
2. On the Overview page, copy the Server name (the <server-name>.postgres.database.azure.com value) and note the Admin username.
3. Under Settings, open Connect for ready-made connection strings, or assemble the fields yourself: host from step 2, port 5432, database (postgres by default, or your own), the admin username, and its password.

Paste the host, port, database, user, and password into Backup, and set SSL mode to require.

We recommend a dedicated read-only role rather than the admin account. On Flexible Server the admin user is a member of azure_pg_admin, a restricted pseudo-superuser role that is more than a backup job needs. Sign in as the admin user once and create a role that only reads:

CREATE ROLE norcube_backup LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE <your-db> TO norcube_backup;
GRANT USAGE ON SCHEMA public TO norcube_backup;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO norcube_backup;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO norcube_backup;

Repeat the USAGE and SELECT grants for any non-public schemas you want in the backup. See read-only role snippets.

Network access

By default a Flexible Server accepts no inbound connections. If your server uses public access (allowed IP addresses), add a firewall rule for Backup's egress IP 18.196.207.101:

1. In the portal, open your server and go to Settings → Networking.
2. Under Firewall rules, add a rule. Give it a name (for example norcube-backup), and set both Start IP address and End IP address to 18.196.207.101. A single IP means start and end are identical.
3. Select Save. Firewall changes can take up to five minutes to apply.

Firewall rules must be IPv4, which 18.196.207.101 is. Don't use Allow public access from any Azure service: a single-IP rule is all Backup needs. See network access.

If your server is configured for private access (VNet integration), it has no public endpoint and firewall rules don't apply, so an external service can't reach it. To back it up, switch the server to public access and add the firewall rule above. Private connectivity (VNet peering, Private Link) is not supported today.

Restore tests and managed extensions

Every backup can be restore-tested: Backup restores it into a throwaway, vanilla stock PostgreSQL engine and confirms your data comes back. Azure preinstalls its own managed extensions, and if your database uses any, they live only on Azure's platform. Their shared libraries don't exist in a generic engine, so they can't be recreated during a restore. The Azure-authored ones are:

• azure_storage — Azure Blob Storage integration (owns the azure_storage schema).
• azure_ai — Azure AI and OpenAI integration (owns the azure_ai, azure_openai, azure_cognitive, and azure_ml schemas).
• pg_diskann — Azure's DiskANN vector index method.

Each must be explicitly allowlisted (via the azure.extensions server parameter) before it can be created, so most servers won't have any. If yours does, their absence in a restore isn't a data problem: they're Azure platform features, not your application data, and Azure recreates them on any Flexible Server. So a restore test treats their absence as expected, notes them in the log, and still records a clean Passed. What it proves is what matters: your schemas, tables, and rows all restore. Details: Provider-managed extensions.

Common extensions like pgvector, postgis, pg_trgm, or uuid-ossp are standard community extensions. They exist in vanilla Postgres and restore normally, so they don't come into this at all.

From there, it's the standard flow

Backup runs a full pg_dump on your schedule and writes the encrypted archive to storage you control. You can download any backup and restore it with standard Postgres tools, independent of Norcube, which is the point of an off-site copy. For the general walkthrough, see connect a database.