2026.10.11
pgBackRest: Backup and Restore for PostgreSQL
pgBackRest provides PostgreSQL backup, WAL archiving, object-storage repositories, and parallel restore features. Review version, licensing, storage, and encryption considerations before adoption.
What it is for
pgBackRest is a PostgreSQL backup and restore project intended to support database backup workflows, WAL archiving, and recovery operations. It may suit database administrators, platform teams, and organizations designing disaster-recovery procedures. The README describes the project as scalable to large databases and workloads, but the supplied sources provide no performance benchmarks or hardware requirements, so those claims should not be converted into throughput expectations.
Known capabilities
The project supports full, differential, and incremental backups, along with parallel backup and restore. Its documented features include file- or block-level change copying, retention and WAL archive expiration policies, file checksums, restore verification, and resuming an interrupted backup from completed work. When PostgreSQL page checksums are enabled, pgBackRest can validate relevant pages during backup and report warnings.
For deployment models, pgBackRest supports local and remote operation, multiple repositories, and communication over TLS/SSH. Repositories can use local storage or S3-, Azure-, and GCS-compatible object storage. The project also provides repository encryption. During recovery, tablespaces and file or directory links can be remapped. WAL push and get support parallel and asynchronous processing. With versioned object storage, the README describes point-in-time repository reads and mentions S3 object locking plus soft delete for GCS or Azure as additional protection options.
Limits and deployment considerations
pgBackRest is not a complete disaster-recovery policy by itself. Operators still need to define PostgreSQL versions, WAL archive locations, repository permissions, retention periods, object-storage versioning, and backup and restore tests. Multiple repositories can improve redundancy and recovery choices, but they also increase the work required for credentials, capacity, lifecycle management, and monitoring. Remote deployments require clear decisions about networking, TLS/SSH, host roles, and failure handling.
The supplied sources do not establish minimum hardware, detailed compatibility requirements, performance benchmarks, or hosted pricing. These points should be confirmed against the target PostgreSQL version, database size, write volume, and storage provider documentation. GitHub metadata reports the license SPDX value as NOASSERTION, while the README says the project is MIT-licensed. That discrepancy should be checked against the repository license file and relevant legal information before adoption.
The v2.59.3 release also matters for encrypted repositories. It says earlier versions could generate weak encryption subkeys and salts when access to system random data failed, and it records fixes for that issue and a possible checksum error involving encrypted info and manifest files. Teams using repository encryption should review affected versions, upgrade procedures, and the handling of existing backups rather than assuming that a version number alone resolves every operational risk.
Sources
Sources checked: 2026-10-11