Install whpg-dr on the primary cluster, create a backup configuration file, and run whpg-dr configure backup to enable WAL archiving to the storage repository.
Prerequisites
Confirm that the primary cluster meets these requirements:
- WarehousePG 6.x or 7.x running on RHEL 8 or RHEL 9 (x86_64)
- No standalone
barmanorbarman-clipackages installed on the WarehousePG hosts. Theedb-whpg-drRPM conflicts with them. - Access to the storage repository from the coordinator and all segment hosts. For NFS, the path must be mounted read-write. For S3, credentials must be available on all hosts. S3 requires WarehousePG 7.x.
Installing the package
Install the edb-whpg-dr RPM on the coordinator and all segment hosts. Run these steps as gpadmin on the coordinator.
The
edb-whpg-drpackage is available in thegpsuppEDB repository. Download it to the coordinator:export EDB_SUBSCRIPTION_TOKEN=<your-token> curl -1sSLf "https://downloads.enterprisedb.com/$EDB_SUBSCRIPTION_TOKEN/gpsupp/setup.rpm.sh" | sudo -E bash sudo dnf download edb-whpg-dr
Create a file
all_hostslisting the coordinator and all segment hosts:cdw sdw1 sdw2 sdw3
Copy the RPM to all hosts:
gpsync -f all_hosts edb-whpg-dr-<version>.el9.x86_64.rpm =:/tmp/
gpscp -f all_hosts edb-whpg-dr-<version>.el9.x86_64.rpm =:/tmp/
Install the package on all hosts:
gpssh -f all_hosts -u gpadmin -e "sudo dnf install -y /tmp/edb-whpg-dr-<version>.el9.x86_64.rpm"
The package installs
whpg-drto/usr/edb/whpg-dr/bin/, bundles its own copy of Barman and all required Python modules, and installs Python 3.12 as a dependency if it isn't already present.Add the
whpg-drbin directory togpadmin'sPATH:echo 'export PATH=$PATH:/usr/edb/whpg-dr/bin' >> ~/.bashrc && source ~/.bashrc
Verify the installation on the coordinator:
whpg-dr --version
Customizing the home directory (optional)
You can override the default home directory and set shared configuration defaults that apply across cluster configurations.
Set WHPG_DR_HOME to override the default location where whpg-dr stores Barman configuration, state, and logs. The default path is $HOME/.whpg-dr:
export WHPG_DR_HOME=/data/coordinator/whpg-dr-home
Add this export to gpadmin's .bashrc or .bash_profile to make it persistent. You can also set whpg_dr_home in your backup YAML file, as described in Creating the backup configuration file. When both are set, the environment variable takes precedence over the YAML field.
Create $WHPG_DR_HOME/global.yaml to set default values that per-cluster YAML files inherit:
log_dir: /data/coordinator/gpAdminLogs log_file_level: debug ssh_user: gpadmin pg_user: gpadmin
Per-cluster YAML settings override global.yaml values.
Creating the backup configuration file
Create a YAML file that describes your cluster name and storage repository, then run whpg-dr configure backup to generate the necessary backup configuration and prepare the cluster for WAL archiving. Run all whpg-dr commands as the WarehousePG cluster owner, typically gpadmin on the coordinator. The RPM installs ready-to-adapt starting points under /usr/edb/whpg-dr/examples/backup/.
Important
whpg-dr configure backup restarts the cluster by running gpstop -ar. Close all client connections before running it. The command waits for active connections to close, which can add several minutes if clients are busy.
Using POSIX storage
Create a backup YAML file with storage.type: posix when both the primary and DR cluster hosts can mount the same filesystem path:
cluster_name: my_cluster storage: type: posix path: /data/backups/whpg-dr
For a full description of all available fields, see Backup configuration YAML.
Using S3 storage
Create a backup YAML file with storage.type: s3 if all cluster hosts have network access to an S3 endpoint. S3 requires WarehousePG 7.x.
cluster_name: my_cluster storage: type: s3 bucket: my-dr-bucket prefix: whpg/my_cluster region: us-east-1 access_key_id: your_aws_access_key_id secret_access_key: your_aws_secret_access_key
For S3-compatible stores such as MinIO or SeaweedFS, add endpoint_url pointing to your endpoint. For a full description of all fields including other credential methods, see Backup configuration YAML.
Preparing the primary cluster for backup
Run whpg-dr configure backup to set up the primary cluster for WAL archiving. The command is a one-time configuration step. It doesn't take a backup. Once complete, the cluster is ready to start archiving WAL to the storage repository:
whpg-dr configure backup /home/gpadmin/backup.yaml
The command does the following:
- Generates Barman configuration files under
$WHPG_DR_HOME/<cluster_name>/backup/barman_conf/and distributes them to the coordinator and all segment hosts. - Saves a copy of your YAML to
$WHPG_DR_HOME/<cluster_name>/backup/config.yaml. - Records a topology snapshot of the cluster's segment configuration to
$WHPG_DR_HOME/<cluster_name>/backup/segment_configuration.csv.whpg-druses this snapshot to detect topology drift before each backup. Any topology change, such as a failover, segment add or remove, or hostname or port change, requires re-runningconfigure backupbefore the next backup. Each base backup also saves a copy to the storage repository underrestore-points/<backup_name>/segment_configuration.csv, whichconfigure restorereads when setting up the DR cluster. - Sets
archive_modeandarchive_commandinpostgresql.confto enable WAL archiving, then restarts the cluster for the changes to take effect.
Use --dry-run to preview the planned actions without writing any files or restarting the cluster:
whpg-dr configure backup /home/gpadmin/backup.yaml --dry-run
Once the command completes without errors, verify the backup configuration:
whpg-dr check my_cluster
All checks report OK when the configuration is correct. If any check fails, see Troubleshooting for common issues.
At this point the storage repository is initialized with a cluster metadata file and a wal/ directory. WAL archiving starts immediately. No base backup exists yet — that happens in the next step.
With the primary cluster configured, you can start taking backups. See Performing backups.
Important
Record the following details before disaster occurs and store them somewhere accessible without the primary cluster, such as version control, a secrets manager, or the storage repository itself. You'll need them to construct the restore configuration YAML at recovery time, and they may not be retrievable if the primary is down:
- The exact WHPG patch version and OS (for example,
warehouse-pg-7-7.4.0-1.el8.x86_64) - The number of primary segments
- The cluster name (as set in the backup YAML)
- Storage credentials and bucket or path details
Updating the configuration
Use --reconfigure to update Barman options such as compression settings, or to rotate S3 credentials such as access_key_id, secret_access_key, and session_token, without restarting the cluster:
whpg-dr configure backup /home/gpadmin/backup.yaml --reconfigureThe command regenerates and distributes the configuration files without modifying postgresql.conf or restarting the cluster. It rejects unsupported field changes and fails if the cluster topology has changed since the last configure backup. In either case, run a fresh configure backup instead.
If you need to change the storage location, use a new cluster name to avoid conflicts with existing backup data in the repository.
Removing the backup configuration
Run configure reset to disable WAL archiving and remove the Barman configuration files from all cluster hosts:
whpg-dr configure reset my_cluster
The command does the following:
- Removes Barman configuration files from all hosts.
- For S3 storage, removes the stored AWS credentials from all hosts.
- Resets
archive_commandandarchive_modeinpostgresql.confand restarts the cluster.
Use --dry-run to preview what will be removed without making any changes:
whpg-dr configure reset my_cluster --dry-run
Note
configure reset affects only the primary cluster. It doesn't remove restore configuration or data directories on the DR cluster, and it doesn't delete backups from the storage repository. Existing backups remain recoverable. However, WAL archiving stops immediately after the reset, so you can only recover to the point of the last backup taken before the reset.