pgBackRest 2.59.3 is maintained and shipping current releases

pgBackRest 2.59.3 is maintained and shipping current releases

pgBackRest 2.59.3 is maintained and shipping current releases. The official project site and pgBackRest repository identify 2.59.3 as the current stable release. The project has current release notes and names nine sponsors. A migration should therefore start with a concrete recovery or support requirement, rather than a claim that the project is unmaintained.

An active upstream project is only one part of a backup decision. The operational question is whether an installation can meet its recovery objectives and whether the team can prove it. A backup tool can be maintained yet still fail a particular recovery-time target, omit a required storage control, or leave the only usable restore procedure in one person’s head.

What the current pgBackRest project offers

The official project page documents full, differential and incremental backups, including block-level backup support; multiple repositories; checksums and verification; local or remote operation; asynchronous WAL handling; and delta restore. Those features establish what the tool supports, while the deployed configuration determines which protections a service actually gets.

For PostgreSQL teams, the distinction between a completed backup and a usable recovery path matters more than a feature tally. An operating check should include:

• a recent successful backup and continuous WAL archiving;
• an isolated restore test using the same repository type and encryption settings as production;
• a measured path to the recovery point and recovery time the service needs;
• a documented owner for credentials, retention, storage controls and emergency access; and
• alerting for a missing archive segment or failed verification before a restore is needed.

pgBackRest’s checksums, repository model and delta restore can help implement those checks. An integrity check alone does not provide the same evidence as starting a restored PostgreSQL instance and verifying application data.

A tool change is a recovery project

Before changing backup tools, retain enough working capacity and access to restore existing backups. Perform a fresh full backup under the new system, rehearse point-in-time recovery, and keep a written rollback decision. Do not discard the old repository simply because a new system produced one successful full backup.

This is especially important when a database has a long retention window. The ability to write new backups does not demonstrate that the team can read an older backup chain, retrieve every required WAL segment or recover after losing the primary machine. Inventory those dependencies before treating a package upgrade or replacement as finished.

If an alternative evaluation is already under way, keep the useful evidence. The comparison should ask which tool satisfies the service’s storage, operator, support and restore requirements. A repository label or an isolated release announcement cannot answer that question alone.

When an alternative can fit better

WAL-G is an archival and restoration project for databases, with PostgreSQL among its supported systems. Its PostgreSQL documentation separates backup and WAL operations and documents configuration for storage backends. Barman is a PostgreSQL backup and recovery manager. These are substantive alternatives to evaluate, with their own deployment models, storage configuration and recovery procedures.

Choose an alternative for a concrete requirement, such as a platform standard, a supported operator integration, a vendor-support relationship or a storage topology the team already operates well. Do not assume the backup formats or configuration files are interchangeable.

Barman 3.19.1 shipped on May 26, 2026. That dated release record is useful for identifying a particular version; current compatibility decisions belong against the documentation for the version being deployed. Test the exact PostgreSQL major version, storage backend and recovery workflow before relying on any claimed equivalence.

The same discipline applies to Kubernetes. Operator documentation establishes the backup interface an operator exposes. A tool being maintained upstream does not prove that an installed operator version has adopted a feature, and an exposed feature does not demonstrate that the restore job meets the service’s recovery target.

A decision process grounded in restores

1. Write down the recovery point objective, recovery-time objective, database size, WAL rate, required retention and off-site or immutable-storage requirements.
2. Inventory repository locations, encryption keys, stanza or server configuration, archive command, retention settings and the last tested restore.
3. Test a full restore and a point-in-time recovery in an isolated environment. Record elapsed time, missing steps and the evidence that the application is usable.
4. If comparing tools, run the same test with a fresh full backup and the same data shape. Documentation examples and nominal compression ratios do not substitute for a restore drill.
5. Keep the decision reversible until the new system covers the retained recovery window and the team has demonstrated that it can recover from its backup chain.

Repeat restore drills after changes to PostgreSQL, object storage, keys, retention or an operator. Review upstream releases and support commitments as part of that cycle. This leaves room for pgBackRest, WAL-G, Barman, a managed service’s backup system or an operator-provided integration without assuming that one choice wins for every installation.

Durable funding and governance also belong in a critical dependency review. A sponsor coalition or Grant-based funding like NLnet’s can inform that discussion. The recovery decision still needs current release evidence and a tested restore path.