pgBackRest is no longer maintained: a calm migration plan for production Postgres operators

The pgBackRest GitHub repository was archived this week — the maintainer announced that the project is no longer being actively developed. For anyone running production PostgreSQL backups via pgBackRest (and that’s a lot of people; it’s been the de facto serious-tier Postgres backup tool for a decade), this is a moment to pause and re-evaluate.

The good news: pgBackRest is open source, the binary you have today still works, and the existing backups are still restorable. The bad news: a backup tool you can’t update is a tool you should plan to migrate off of, because PostgreSQL versions march on and the project’s compatibility window with new PG releases will quietly stop expanding.

What you don’t have to do today

• Don’t panic-migrate. If you’re on PostgreSQL 16 or 17 and pgBackRest’s last supported version, your backup pipeline keeps working. The tool will not stop functioning because the repo got archived.
• Don’t delete existing backups. The on-disk format stays restorable as long as you keep a working pgBackRest binary somewhere. Even if you migrate to something else, keep one copy of the pgBackRest binary archived alongside your backup data so future-you can extract a 2024 backup if needed.
• Don’t switch to manual pg_dump. It’s tempting, and for small databases it’s fine, but pg_dump doesn’t do incremental, doesn’t do PITR, and gets painful past about 100 GB. The reasons you picked pgBackRest over pg_dump in the first place haven’t changed.

The real options for migration

Three serious candidates, and each suits a different shape of operation:

• WAL-G — actively maintained, supports object storage backends (S3, GCS, Azure, Swift, FS), incremental, PITR, and parallel decompression. Closest one-to-one feature replacement for pgBackRest. Configuration is simpler in some ways, more verbose in others. The migration path is “set up WAL-G in parallel, do a fresh full backup with it, run both for a couple of weeks, switch the restore-tested backup to be the new source of truth.”
• Barman — 2ndQuadrant’s tool, now under EnterpriseDB. Different operational model: a dedicated backup server that pulls from Postgres via WAL streaming. Heavier to set up, but excellent for centralizing backups across many Postgres clusters from one operational point. Worth it if you have 10+ Postgres instances; overkill for a single-cluster deployment.
• Continuous archiving + a custom restore script — back to first principles: archive_command pushing WAL to S3, periodic pg_basebackup for a fresh base, and a small script that ties the two together for restore. Maximum control, minimum dependencies. Works if your team has the time to write and maintain it; doesn’t if you’re a one-person ops team.

A recommended migration plan, week by week

1. Week 1: confirm a current-pgBackRest-version restore actually works. Pick a non-production environment, take the most recent backup, restore it from scratch, validate. If you’ve been doing this regularly, just confirm the rotation is healthy. If you haven’t been doing this regularly, do it now while you still have an actively-developed tool to fix any problems with.
2. Week 2: stand up WAL-G in parallel. Don’t replace pgBackRest yet. Configure WAL-G to push to a different bucket / prefix, run a full base backup, let WAL accumulate for a week.
3. Week 3: restore-test from the WAL-G data only. This is the gate. If you can fully restore from WAL-G in your environment, you’re ready to migrate. If you can’t, you’re either misconfigured or you’ve found something that pgBackRest was doing for you that WAL-G doesn’t replicate, and you need to figure out which.
4. Week 4: cut over the source-of-truth. Update your runbook, your monitoring, your “where do backups live” docs. Keep the pgBackRest pipeline running for one more cycle to be safe. Then disable it.

The unspoken thing

An archived backup tool is also a moment to ask: when was the last time you successfully restored from your backups? Most teams find out they have problems with their backup pipeline only when they need to use it — which is the worst time to find out. Tools getting deprecated forces an audit you should have been doing anyway.

If your last successful restore was more than 6 months ago, or it was on a smaller database than what you have in production today, the migration window is the right time to fix that — not three months from now when you’re rushing to install WAL-G because your backups stopped working.

One more thing: if you maintain something open-source-y in this space and have the bandwidth, fork pgBackRest. It’s been load-bearing for a lot of small Postgres installations that don’t have the budget for Barman’s operational complexity, and a maintained fork from a credible team would be welcome.

Source: github.com/pgbackrest/pgbackrest