Barman has always been solid for backup and restore, however configuring backup in CNPG is a little more interesting - WAL limits need to be set carefully or you just end up filling WAL volumes and the database becoming unavailable.
CloudNativePG also implements support for volume snapshots: https://cloudnative-pg.io/docs/1.29/backup#backup-methods
right and here's why CloudNativePG chose Barman over pgBackRest: https://github.com/cloudnative-pg/cloudnative-pg/issues/3077
> WAL limits need to be set carefully or you just end up filling WAL volumes and the database becoming unavailable.
This is true. For anyone getting alarmed that this is due to a bug in PostgreSQL, it's not - it's PostgreSQL protecting the customer from attempting to write data that it cannot durable commit - "I am going to go unavailable because I don't have enough space to save more data".
There are multiple ways to handle this, the easiest, most hands on way is to keep a monitor and alert that watches the WAL size like a hawk and then alerts OPS the moment it breaches a threshold.
I think (and I'm probably wrong now) that Barman only could push backups to another Linux machine (e.g., EC2 box), so you had to worry about your backup system _on top_ of the main DB.
So I'm really hoping someone will pickup maintaining pgBackRest.
https://docs.pgbarman.org/release/3.14.1/user_guide/barman_c...
https://docs.pgbarman.org/release/3.12.0/user_guide/barman_c...
For CNPG: https://github.com/cloudnative-pg/plugin-barman-cloud
Stability and performance at scale sound like implementation specific properties though. If you've tried this, I'd be curious to known about the specific issues you encountered.
Nonetheless, very happy to see this project on the front page of HN!
Anyone here had considered Barman in the past, used it for a while and went to pgBackRest? Are you revisiting that decision now?
https://thebuild.com/blog/2026/05/01/pgxbackup-continuity-su...
Databasus seems to be taking somewhat similar approach to Barman, but (at this time) does not appear to use pg_receivewal, which makes it less efficient than Barman.
For PG v17+, Barman seems to be the most efficient backup solution based on PG native tools, that is able to do low-RPO or even zero-RPO (if configured as a synchronous receiver).
