Implementing pgBackRest for Backup and Restore in pgEdge
pgEdge enhances PostgreSQL by enabling distributed, multi-active database clusters designed for low-latency, globally scaled applications. However, distributed systems introduce new challenges in data protection and disaster recovery. In this blog, we'll outline the steps and best practices you should follow when implementing and maintaining a reliable backup and restore strategy for pgEdge environments using pgBackRest.
pgBackRest is a robust, high-performance backup tool designed for PostgreSQL that offers features such as:
Full, differential, and incremental backups
Compression and encryption
Parallelism and delta restores
Point-in-Time Recovery (PITR)
Seamless integration with WAL archiving
When combined with pgEdge, pgBackRest ensures data resilience across distributed nodes by supporting geographically redundant backups and rapid restoration of services after network interruption or failure.
In this blog, we'll:
Define a consistent and reliable backup process for pgEdge clusters.
Share steps to recover from data loss, node failures, or full-cluster outages.
Guide both automated and manual backup/restore procedures.
help you support compliance with organizational RTO (Recovery Time Objective) and RPO (Recovery Point Objective) policies.
We'll define the process for backing up and restoring PostgreSQL databases in a pgEdge cluster with pgBackRest. You can use this information to ensure consistency, reliability, and disaster recovery readiness in a distributed pgEdge PostgreSQL cluster. This information will be useful for you if you manage a:
production or staging pgEdge cluster.
a team responsible for backups and recovery.
a cluster running pgEdge PostgreSQL 15+ with pgBackRest installed.
Prerequisites
Before working your way through this blog, you should ensure that you have:
An installed and operational pgEdge cluster
With pgBackRest installed on each node (or a centralized backup host)
PostgreSQL WAL archiving is enabled (this is prompted during cluster setup)
a configured backup repository (either posix or S3-compatible storage)
Passwordless SSH access for centralized backup
You should also ensure that your cluster is running version 25.X of the pgEdge CLI:
Configuring pgBackRest on an Existing Cluster
There are multiple ways to deploy pgBackRest with a pgEdge cluster; if you are spinning up a new pgEdge cluster, you can deploy pgBackRest at the same time by using the cluster module to define a .json file that includes the pgBackRest specifications, and then initialize your cluster.
In the example that follows, we'll add pgBackRest to an existing pgEdge cluster. To accomplish this, you'll use the pgEdge CLI to install and configure the pgEdge backrest bundle. This Multi-master-enabled pgBackRest bundle is designed specifically for pgEdge use cases.
The following are the steps involved in setting up the backrest:
Install the latest version of the pgEdge backrest source code bundle.
Create a pgBackRest stanza with the
set-postgresqlconf
API.Modify the PostgreSQL
pg_hba.conf
file and reload the configuration.Modify the stanza to configure the backup.
Identify your backup repository; the current options are posix and S3.
Update pgEdge Postgres to provide details like user identities, port information, and data directory location.
Configuring pgBackRest on an Existing pgEdge Cluster
First, we'll use pgEdge to install pgBackRest on each node of the cluster:
./pgedge install backrest
Then, we'll use the
set-postgresqlconf
API to update the postgresql.conf
file in preparation for configuring pgBackRest:
./pgedge backrest set-postgresqlconf --stanza demo_stanza_n1 --pg1-path
/home/rocky/practice/pgedge/data/pg17 --repo1-path
/var/lib/pgbackrest/n1 --repo1-type posix --repo1-cipher-type aes-256-cbc
Next, we'll use the
set-hbaconf
API to update the pg_hba.conf file, configuring authentication for pgBackRest:
./pgedge backrest set-hbaconf
Then, we'll reload the server configuration so the changes take effect:
./pgedge psql 'select pg_reload_conf()' lcdb
Next, we'll configure our backup and create the backup stanza:
./pgedge set BACKUP stanza demo_stanza_n1
sudo mkdir -p /var/lib/pgbackrest_restore/n1
./pgedge set BACKUP restore_path /var/lib/pgbackrest_restore/n1
./pgedge set BACKUP repo1-host-user rocky
./pgedge set BACKUP pg1-path /home/rocky/practice/pgedge/data/pg17
./pgedge set BACKUP pg1-user rocky
./pgedge set BACKUP pg1-port 6432
./pgedge set BACKUP repo1-type posi
./pgedge backrest create-stanza --stanza=demo_stanza_n1
--repo1-path=/var/lib/pgbackrest/n1
Then, we start pgBackRest:
./pgedge backrest backup --repo1-path=/var/lib/pgbackrest/n1 --stanza=demo_stanza_n1
--pg1-path=/home/rocky/practice/pgedge/data/pg17
After starting pgBackRest, we can review a list of backups:
./pgedge backrest list-backups
Conclusion:
Implementing a robust backup and restore strategy is essential for maintaining the integrity and availability of distributed PostgreSQL databases in pgEdge environments. By leveraging pgBackRest’s advanced capabilities, such as incremental backups, parallel processing, and PITR, you can meet the demands of modern, geo-distributed applications with confidence.
Whether you're preparing for unexpected node failures or planning for compliance with strict RTO and RPO requirements, pgBackRest offers the tooling necessary to keep your pgEdge clusters protected and resilient. Consistent backup routines, regular testing of restore procedures, and clear operational workflows are the cornerstones of a well-architected data protection strategy.
As your pgEdge deployment scales across regions and continents, a dependable backup system becomes not just an option, but a necessity. With the right processes in place, pgBackRest ensures that your critical data remains recoverable, consistent, and always readily accessible, regardless of the challenges that arise.
For more information about using pgEdge distributed multi-master replication, visit the pgEdge website or see the pgEdge documentation.