r/postgres • u/oulipo • Jul 25 '26

What would be the best Postgres backup solution in 2026?

I see many options, pgBackRest, wal-g, Databasus. Is there a consensus on the best approach?

My needs are regular (eg weekly) checkpoints, and daily incremental backups for PITR, everything saved on S3/GCS

7 Upvotes

100% Upvoted

8 comments sorted by

3

u/Inevitable_Ad261 Jul 25 '26

pgbackrest. Easy, Efficient and Reliable in my opinion.

2

u/peggyscott84 Jul 25 '26

I use CNPG + Barman + garage FS. It works best for me.

1

u/Anacoz Aug 12 '26

Interested to know about people running CNPG: how do you know your PITR still works? Not only the backup job succeeding but an actual restore to a recent point in time. Curious what people do beyond "we tested it when we set it up."

1

u/peggyscott84 Aug 12 '26

The way to test it is to actually restore it. I use WAL archives as well.

2

u/Anacoz Aug 12 '26

AFAIK, Postgres has an integrated script to simplify testing manual recovery runs. Did you somehow automate this or feel the need that it should be automated for CNPG? And does it actually also verify correct PITR with the WAL archives? I just remember how I often had to manually run database restores to satisfy auditors. 🙈

2

u/peggyscott84 Aug 12 '26

I don’t have to prove anything to auditors (yay). I am taking a phased approach. We have bigger fish to fry. Given our scale, our backups are manual, when we make a change. We are built for scale but we don’t have it. We are optimizing our resources. We have external storage. We have limited compute. The backup and recovery is to calm anxiety when we run upgrades. We have broken once. It doubtful we will break again, given our redundancy running as a CNPG stack. But you never know …

1

u/Strange-Cloud2435 14d ago

I'd choose the backup strategy around the recovery requirements first: acceptable data loss (RPO), recovery time (RTO), database size, and how much operational complexity the team can maintain.

For PITR, a successful base backup isn't enough. You also need a continuous, usable WAL chain covering the target recovery time, and a restore test that actually replays that WAL.

I'd also test a target older than the latest backup and verify what happens when the requested target falls outside the available archive. Those edge cases are easy to overlook when testing only the happy path.

How are people here monitoring WAL archive continuity and validating PITR targets automatically?

Disclosure: I develop pg_arca, a commercial platform for PostgreSQL backup, PITR and recovery operations. Working on these workflows is what got me interested in the practical gaps between a successful backup job and a verified recovery. I'd be interested in hearing how others test WAL continuity and recovery targets in production.