pg_probackup manages PostgreSQL backups with page level incrementals

A backup manager built around the catalog, not a copy script

pg_probackup is described as a utility to manage backup and recovery of PostgreSQL database clusters, designed to perform periodic backups of the PostgreSQL instance that enable you to restore the server in case of a failure. The framing matters. This is not a wrapper around a single file copy command but a manager that owns a directory of backup data, a catalog of what is in it, and the WAL segments needed to bring a cluster back to a consistent point in time. The project states compatibility with PostgreSQL 13, 14, 15, 16, 17 and 18. The audience is database administrators and platform engineers running production clusters, where the interesting questions are how long a restore takes, how much disk the backups consume, and whether the archive can still reach the recovery point the business needs. The homepage hosts the documentation, and the tool is also documented in the Postgres Professional documentation, which signals the intended deployment environment: large PostgreSQL installations where operators expect a dedicated utility rather than a database extension.

The backup catalog holds data files, metadata and the WAL archive

The data model is the catalog. To manage backup data, pg_probackup creates a backup catalog, and this directory stores all backup files with additional meta information, as well as the WAL archives required for point-in-time recovery. Backups for different instances live in separate subdirectories of a single catalog, so one repository can serve a fleet of clusters. On top of that structure, the tool exposes two catalogues as commands: the Backup Catalog gives a list of backups with corresponding meta information in plain text or JSON formats, and the Archive Catalog gives the list of all WAL timelines with the corresponding meta information in the same two formats. Plain text is for humans reading a terminal, JSON is for feeding a dashboard or an audit script. The presence of a JSON output mode is a small but telling design decision, since it is what makes the tool scriptable without screen scraping. Partial restore is supported too, so you can restore only the specified databases, or exclude specified databases from a restore, which matters when one tenant's data is not supposed to come back with the cluster.

PAGE, DELTA and PTRACK solve the same problem three different ways

The incremental story is where this tool earns its place, and the three modes are worth comparing rather than just listing. A Full backup contains all the data files required to restore the database cluster from scratch. A PAGE backup scans all WAL files in the archive from the moment the previous full or incremental backup was taken, and the new backup contains only the pages mentioned in WAL records, which requires all the WAL files since the previous backup to be present in the archive. A DELTA backup reads all data files in the PGDATA directory and copies only the pages that changed since the previous backup, and continuous archiving is not necessary for it to operate, though it imposes read-only I/O pressure equal to a Full backup. A PTRACK backup has PostgreSQL track page changes on the fly, marking updated pages in a special PTRACK bitmap per relation, where each page needs just one bit, so the bitmaps stay small. PTRACK needs no continuous archiving either, adds minor overhead on the database server operation, and speeds up incremental backups significantly. The practical guidance is that PAGE favours space and speed if your WAL archive is complete, DELTA favours not having to keep one, and PTRACK favours steady state speed at the cost of a small server overhead.

PTRACK needs a specific server build, not just a recent one

PTRACK is the mode with the sharpest prerequisites, and the project lists exactly which servers provide it. PTRACK backup support is provided via vanilla PostgreSQL 13, 14, 15, 16 and 17 with the ptrack extension, and through Postgres Pro Standard and Postgres Pro Enterprise for the same version range. That is a narrower matrix than the overall PostgreSQL 13 to 18 compatibility statement, so a cluster on PostgreSQL 18 or on a vanilla build without the extension cannot use PTRACK even though the rest of the tool works there. The extension is a separate project from pg_probackup itself, which means adopting the fastest incremental mode means accepting an extra dependency on the server side as well as the client side. The repository contains a ptrack source file in the build, src/ptrack.o among the compiled objects, so the client side of the protocol is part of the same build, but the server side tracking still has to be enabled by the matching extension or Postgres Pro edition.

Autonomous backups carry their own WAL, archive backups rely on continuous archiving

Regardless of the backup type, the tool supports two WAL delivery strategies, and the difference decides whether you need a separate archive. Autonomous backups stream via the replication protocol all the WAL files required to restore the cluster to a consistent state at the time the backup was taken, and even if continuous archiving is not set up, the required WAL segments are included into the backup. Archive backups rely on continuous archiving instead. For a team that wants point-in-time recovery to arbitrary times, continuous archiving is the prerequisite, and the Autonomous mode then becomes a way to guarantee a particular backup is self consistent even if the archive has gaps. For a team that only cares about restoring to the moment of the backup, Autonomous mode removes the need to run and monitor a WAL archive at all, at the cost of losing the finer grained recovery targets. Retention is handled on top of either mode: the tool manages WAL archive and backups in accordance with retention policy, configurable by recovery time or by the number of backups to keep, with a time to live for a particular backup, and expired backups can be merged or deleted.

Merge, validation, checkdb and parallel workers around the same data

Around the core backup and restore sit the operational features that decide whether the tool is usable unattended. Merge allows an incrementally updated backups strategy, eliminating the need to do periodical full backups, and expired backups can be merged or deleted rather than thrown away. Validation provides automatic data consistency checks and on-demand backup validation without actual data recovery, and Verification gives on-demand verification of a PostgreSQL instance with the checkdb command. The Backup Catalog and Archive Catalog give the listings described earlier. Parallelization runs backup, restore, merge, delete, verification and validation processes on multiple parallel threads, and Compression stores backup data in a compressed state while Deduplication avoids copying unchanged non-data files such as _vm or _fsm. Remote operations cover backing up a PostgreSQL instance located on a remote system or restoring a backup remotely, and Backup from standby avoids extra load on master by taking backups from a standby server. External directories extend the backup to files and directories located outside the PostgreSQL data directory, such as scripts, configuration files, logs, or SQL dump files, which is the part most backup tools miss.

Three hard limits on restore compatibility and remote use

The README lists the limitations directly, and they are the ones to read before designing a restore plan. First, the server from which the backup was taken and the restored server must be compatible by the block_size and wal_block_size parameters and must have the same major release number. That is not a soft caveat: a cluster built with a non-default block size cannot be restored onto a server with the default one, and the tool will not paper over the difference. Second, remote backup via ssh on Windows is currently not supported, so a Windows source or target excludes the ssh transport, which points you at local operations or another transport. Third, when running remote operations via ssh, remote and local pg_probackup versions must be the same, so you cannot keep the server side pinned at an older release while upgrading the client. For a tool whose value is in large restores, the first limitation is the one that dictates architecture: keep the block size and major version consistent across every cluster you intend to restore into, or keep separate backup pools per configuration.

Custom licence, a release branch model, and a dated last push

Two housekeeping facts belong in an evaluation. The first is licensing: the repository carries a custom licence that GitHub cannot classify, so the terms live in the LICENSE file rather than in a standard MIT or Apache text, and a commercial redistribution question needs reading rather than assuming. The second is the release cadence and its shape. The tagged releases include 2.5.16 on 2025-12-09, 2.5.15 on 2024-05-16 and 2.5.14 on 2024-05-14, so two releases landed in May 2024 and the next one appeared more than a year later, while the last push to the repository was on 2026-07-12. Development follows a stated branching model: the stable version state is under the respective release tag, the master branch contains minor fixes planned for the nearest minor release, and the upcoming major release is developed in a release branch such as release_2_6, with detailed release plans in the project's Milestones. Installation is straightforward for a vendor project: on Windows, installers are available in the release assets, and on Linux the documentation's installation section covers it. On the source side, the Makefile shows a C codebase built against the PostgreSQL build system, with objects for backup, restore, merge, catalog, ptrack, checkdb and the utilities, and it even borrows WAL receiving and stream files from the PostgreSQL source tree.

Editorial conclusion

Adopt pg_probackup when your PostgreSQL clusters are large enough that full cluster copies hurt, when you need merge and retention policies rather than a shell script around a file copy, or when you want to take backups from a standby server. Do not adopt it when your environment mixes PostgreSQL major versions or block sizes, because the restore target must match, and do not expect Windows support for remote backup over ssh, which is explicitly not supported. Verify first that the backup server and the restore server agree on block_size and wal_block_size and on major release, that the local and remote pg_probackup versions match when you operate over ssh, and that the licence in the LICENSE file fits your distribution model.

Frequently asked questions

Official sources

1. Issues
2. postgrespro/pg_probackup on GitHub
3. Project website
4. README
5. Releases