pgBackRest

"Reliable PostgreSQL Backup & Restore." C, MIT, 4,323★ / 381 forks, started 2013-11-11 and pushed 2026-08-20. The licence file names both parties that maintain it: "Portions Copyright (c) 2015-2026, The PostgreSQL Global Development Group" and "Portions Copyright (c) 2013-2026, David Steele" — a personal project that grew into shared community infrastructure without changing hands.

Read from the project site and repository (T1), pulled from awesome-postgres' Backups section — the largest section in the catalog after the tool sections, fourteen entries deep, which is itself a signal about where operational effort goes.

It is a WAL tool wearing a backup tool's name

The Postgres documentation states the possibility: "By archiving the WAL data we can support reverting to any time instant covered by the available WAL data: we simply install a prior physical backup of the database, and replay the WAL just as far as the desired time." That sentence describes two continuous obligations, not one nightly job — take physical base backups, and never lose a WAL segment in between. pgBackRest is the machinery for both, and the feature list reads as a catalogue of the ways each one goes wrong at size.

The archive side is where the pressure is. "Dedicated commands are included for pushing WAL to the archive and getting WAL from the archive. Both commands support parallelism" — and they are asynchronous. A busy primary generates WAL faster than a serial, per-segment shell command can ship it, and when the archive falls behind, segments accumulate on the primary until the volume fills. This is the concrete shape of a bottleneck planetscale-768-servers named from the other direction: that page lists WAL, replicas and backups among the things that stop scaling before the query load does, and gives sharding as the answer. pgBackRest is the answer you try first.

The backup side is about not re-copying what has not changed. Full, differential and incremental backups, with block-level options that "save space by only copying the parts of files that have changed." Compression and checksums are computed "in stream while files are being copied to the repository" rather than in a separate pass, and the project states plainly where the time goes: "Compression is usually the bottleneck during backup operations so pgBackRest solves this problem with parallel processing and more efficient compression algorithms such as lz4 and zstd." An interrupted backup "can be resumed from the point where it was stopped."

Restore is the same trick in reverse. Delta restore compares checksums against what is already on disk and rewrites only the differences — the difference between re-provisioning a large cluster in hours and in minutes, and the reason a restore-time claim means little without saying whether the target was empty.

Verification, which is the part that distinguishes a backup tool from a copy

"Checksums are calculated for every file in the backup and rechecked during a restore or verify." And separately: "If page checksums are enabled pgBackRest will validate the checksums for every file that is copied during a backup."

The second one is quietly the more interesting. Because a full backup reads every page in the cluster, it is also the only routine process that reads every page — so with page checksums on, the nightly backup is a corruption scan the database would not otherwise get. The failure mode it guards against is the one that makes backup software a genuine subject: a backup that copied already-corrupt data faithfully, verified its own checksums happily, and restores garbage.

Repositories can live "in S3, Azure, and GCS compatible object stores", with repository encryption supported. The site also frames versioned object storage as ransomware protection; that is the project's positioning rather than a mechanism this page verified.

Why it belongs here

It closes the near half of growth edge 5's successor — the write path that postgresql and mysql both stop short of. It does not close the mechanism itself, which is why write-ahead-logging was written from the engine's documentation alongside it: this page is what an operator does with the WAL, that page is what the WAL is.

It also completes a pairing with patroni that neither project makes explicit. Both exist because a single Postgres is a single point of failure, and they answer opposite failures. Patroni handles the machine dying — another node has the data already, so recovery is measured in the seconds of a ttl. pgBackRest handles the data being wrong: a dropped table, a bad migration, corruption, which replication faithfully copies to every replica within milliseconds. Replication is not a backup, and the two tools sitting in adjacent sections of the same catalog is the ecosystem saying so.

Not covered here. Any measurement — every performance claim above is the project's own, with no benchmark on this page. The interaction with pgbouncer and with replication topology. And the restore procedure for a real PITR, which the documentation covers at length and this ingest did not read.

Related

write-ahead-logging · postgresql · patroni · planetscale-768-servers · awesome-postgres · operational-databases