Azure Database for PostgreSQL Flexible Server

Arpio supports recovery of Azure Database for PostgreSQL Flexible Server workloads.

The following resource types are supported:

PostgreSQL Database

Arpio replicates PostgreSQL Databases into the recovery environment. At backup time Arpio stores snapshots of your databases into the recovery subscription and region. At recovery time, new databases are created from those snapshots and attached to the recovery server.

The following attributes are translated during replication:

The following resources are automatically selected into recovery points when a PostgreSQL Database is selected:

• PostgreSQL Server containing the database

PostgresSQL Server

Arpio replicates PostgreSQL servers into the recovery environment. At backup time Arpio stores the roles and memberships into the recovery subscription and region. At recovery time, new servers are created with those roles and memberships.

The following attributes are translated during replication:

The following resources are automatically selected into recovery points when a PostgreSQL Server is selected:

• Entra administrators (optional)
• Firewall rules (optional)
• Key Vaults containing the administrator password
• Delegated subnets and Private DNS zones (if using virtual network injection)

PostgreSQL Entra Administrator

Arpio replicates Azure PostgreSQL Entra Administrators to the recovery environment.

The following attribute is translated during replication:

PostgreSQL Firewall Rule

Arpio replicates Azure PostgreSQL Firewall rules to the recovery environment.

Backup Access Setup

To back up a PostgreSQL Flexible Server, Arpio reads its databases and roles through a dedicated, read-only credential. How you provide that credential depends on the server's authentication mode. Until it is configured, Arpio cannot back up the server and raises a PostgreSQL Backup Setup Required issue describing the exact steps for your server.

Note: this credential is used only to read the source server at backup time. It is separate from the arpio-config:admin-password-secret tag, which supplies the administrator password used to provision the recovery server.

Microsoft Entra authentication

When the source server has Microsoft Entra authentication enabled, Arpio connects as its own delegate managed identity — no dedicated login or stored password is required. The delegate must be registered as an Entra principal on the server with read access and the REPLICATION attribute.

Connect to the postgres database as an administrator and run the SQL below, using the object ID that Arpio provides in the setup issue:

SELECT * 
FROM pgaadauth_create_principal_with_oid(
         'ArpioPrimaryDelegate',
         '<delegate-object-id>',
         'service',
         false,
         false
      );
 
ALTER ROLE "ArpioPrimaryDelegate" WITH REPLICATION; 
GRANT pg_read_all_data TO "ArpioPrimaryDelegate";

Note: This entra based approach is only valid for "single source" scenarios where the PostgreSQL Flexible server is not included in another app going to a different recovery location. Additionally, you may encounter a situation where the above SQL command does not resolve the Arpio issue. This might be resolved by dropping the existing role and then re-running the SQL suggested by the issue. 

DROP ROLE IF EXISTS "ArpioPrimaryDelegate"; 

PostgreSQL authentication

When the source server has PostgreSQL password authentication enabled (username/password), Arpio is able to recovery the admin user name, but for security purposes, the admin password cannot be retrieved. When attempting to create a recovery point you may see the following "Missing Required Tag" issue:

To recover this password-authenticated PostgreSQL Flexible Server, Arpio must set its administrator password on the server it creates in the recovery environment, but cannot retrieve that password from the primary environment. To resolve this, create a Key Vault secret containing the administrator password in the primary environment. Then add the "arpio-config:admin-password-secret" tag to this PostgreSQL Flexible Server, with the value set to the URL of that secret. (This is needed for recovery only — it is separate from the read-only login Arpio uses to back up the server.)

Resolve this issue by placing the password into an Azure Key Vault in the same subscription/region, and then use the arpio-config:admin-password-secret tag to tell Arpio where the password is stored.

If an admin username/password have not already been defined, create a dedicated read-only login and point Arpio at its password through the same tag: 

1. As a server administrator, create the login:

   CREATE ROLE "arpio-replication" WITH LOGIN PASSWORD '<choose-a-strong-password>' REPLICATION; 
   GRANT pg_read_all_data TO "arpio-replication";

2. Store the login's password in an Azure Key Vault secret.
3. Set the arpio-config:replication-password-secret tag on the server to the full Key Vault secret URI, in the form https://{vault-name}.vault.azure.net/secrets/{secret-name}.

You will also need to grant the Arpio delegate identity get permission on that secret (or its Key Vault) so Arpio can read the password at backup time. 

Continuous (Incremental) Backup

By default, Arpio protects each database by capturing a full snapshot on every backup. You can optionally enable continuous backup, which streams changes between full snapshots so recovery points can be created more frequently and with less overhead.

When a PostgreSQL Flexible Server is added to your Arpio application, it may raise an issue requesting you make change some of the server settings. While this approach is recommended, it is not required and full snapshot backups of the database will continue (and the issue will continue to be displayed). 

Continuous backup builds on PostgreSQL logical replication, so the source server must meet these prerequisites:

Once the prerequisites are met, Arpio enables continuous backup automatically on the next backup — there is no separate setting to toggle. If they are not met, Arpio raises an Enable Continuous PostgreSQL Backup issue listing what to fix, and continues protecting the database with periodic full snapshots until the prerequisites are satisfied.

How it works

When continuous backup is active, Arpio captures your data in two complementary ways:

• Full snapshots — a complete copy of the database. Arpio takes a fresh full when the most recent one is more than 24 hours old; between fulls, backups capture only incremental changes.
• Incremental segments — committed changes captured via logical replication and sealed into ordered, position-stamped segments between full snapshots.

When continuous backup is not enabled (or its prerequisites are not yet met), each recovery point is simply the most recent full snapshot.