Learn pgBackRest - v2.59.0 & the Latest Features

#Introduction

The backup system you've built is alive and keeps evolving — pgBackRest is released periodically with fixes, new PostgreSQL support, and feature refinements. In episode 17 we map out the latest release 2.59.0, trace the release history that led here, and put together a safe upgrade strategy — because an ignored version is a lurking risk.

This isn't a dry "release news" episode. Understanding the direction of pgBackRest development helps you decide when to upgrade, which features are coming, and where this tool is headed in the next 2-3 years.

#Release 2.59.0 (July 2026)

#What's New

pgBackRest 2.59.0 was released 20 July 2026 as the current stable. This release focuses on fixes and the newest support: stability refinements across several areas, bug fixes in frequently used code paths (archiving, restore, and object storage integration), and ensuring compatibility with the latest PostgreSQL.

Alongside the release, a new distribution tarball (20 July 2026) is available — a ready-to-install package variant for specific Linux distributions. This makes installing the latest version easier without waiting for the distro repo (episode 3).

#PostgreSQL Support

One of pgBackRest's strengths is its broad support: a single installation serves up to 10 PostgreSQL versions at once, including EOL versions. Release 2.59.0 ensures full compatibility with PostgreSQL 17 and 18 — so when your production cluster upgrades versions, the backup tool is already ready without major changes.

pgbackrest version

#The Trail of Previous Releases

To understand 2.59.0, look at how it grew:

#2.56 (2025): S3 Fixes

This 2025 release polished the S3/object storage integration — fixing transfer reliability for large buckets and edge cases on S3-compatible storage beyond AWS (MinIO, R2, etc.). For those relying on repo1-type=s3 (episode 12), this release is important to follow.

#2.54 (2025): Backup from Standby

This release refined backup from standby — the ability to take backups from a replica instead of the primary. This is the path toward the HA architecture we discuss in episode 18: backup load no longer disturbs the primary serving traffic.

#Other Building-Block Milestones

• 2.50: zstd compression became the default — a major performance change.
• 2.51: the verify command — proactively validating backups against the database.
• 2.47: block incremental — block-level deduplication, dramatic space savings for large databases.

# https://pgbackrest.org/release.html

#A Safe Upgrade Strategy

#The Principle: Old Backups Stay Readable

One of the most important guarantees: pgBackRest is backward compatible with backup formats. A new version can read and restore backups made by older versions. This means an upgrade doesn't force a re-backup from scratch.

#A Structured Upgrade Process

1. Read the release notes on pgbackrest.org — check for option or behavior changes that touch your configuration.
2. Test in a non-production environment: run the new pgbackrest version on a drill host (episode 16) and do a restore test before touching production.
3. Take a full backup first: before upgrading, run backup --type=full with the old version as a safety net.
4. Upgrade the binary: install the new version (package or tarball).
5. Verify after the upgrade:

pgbackrest version
sudo -u postgres pgbackrest --stanza=main check
sudo -u postgres pgbackrest --stanza=main backup --type=diff

6. Watch one full backup cycle before concluding the upgrade is safe — monitor logs and alerts (episode 14).

#When to Upgrade

• Immediately: there's a bug fix touching your configuration (for example an S3 fix for MinIO users).
• During a maintenance window: for regular releases, follow the routine maintenance cycle.
• Together with a PostgreSQL upgrade: take advantage of the PG upgrade moment to raise pgBackRest too — one window, one test suite.

#Conclusion

Key takeaways:

• 2.59.0 (20 July 2026) brings fixes, a new distribution tarball, and PostgreSQL 17/18 support.
• 2.56 polished S3; 2.54 refined backup from standby — the foundation of an HA architecture.
• The backup format is backward compatible — an upgrade doesn't force a re-backup.
• Upgrade one at a time, test in the drill environment first, then verify with check and one backup cycle.
• Monitor pgbackrest.org for development direction and new releases.

In the next episode we'll move the backup load to a replica: backup from standby & HA — configuring pg1-standby and backup-standby to reduce the primary's load, integration with Patroni/repMgr, and restoring to a new node in an HA cluster. Backups and HA work together as one architecture!