We use Barman inside Kubernetes via CloudNativePG's plugin, as it is the default backup plugin.
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.
> 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.
Last time I checked, Barman didn't support backups to S3. That's why (for us) pgBackRest was such a big deal: it could offload full and incremental backups to a basically limitless and reliable medium.
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.
Something like Rclone and a cron job, or else s3 mounted via FUSE, could possibly bridge that. Of course then you have to worry about reliability of the bridge...
This is a fantastic project that a lot of self-hosters using PostgreSQL use. Specially with pgBackRest archived by the owner on Apr 27, 2026, this is likely the leading option that has been around the block for a while.
Anyone here had considered Barman in the past, used it for a while and went to pgBackRest? Are you revisiting that decision now?
It looks like pgBackRest will likely continue, multiple companies are stepping up with sponsorships. Mentioning this just in case anyone is making plans to move away, it's probably worth waiting a bit for things to settle.
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.
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.
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...