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.
The way I read that issue and the linked discussion was, that pgBackRest handles a lot of details itself that's otherwise handled by Kubernetes. Hence, a lot of functionality in pgBackRest is not only redundant but incompatible with how Kubernetes CSI could be used to provide incremental and differential backups. Hence, Barman and `barman-cloud` plugins are a better, natural fit for a Kubernetes environment than pgBackRest.
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.
Huh... Opposite experience. Barman cloud (s3 backups) is the only way I've ever used it. I didn't realize it wasn't the only way. Makes sense it could just use a filesystem.
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...
I can understand why it'd be preferable to avoid such a bridge layer, and indeed I too would rather just have a transparent view of what's going on at the protocol level.
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.
We (ParadeDB) use Barman via CloudNativePG for almost all our deployments. It's been solid, although I've had a few complaints about 1) inability to set S3 storage classes, 2) slow upload for very large databases.
Nonetheless, very happy to see this project on the front page of HN!
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?
One interesting thing about Barman is that it just uses PG's own backup utilities. It doesn't implement custom parsers and things like that. So, there's less maintenance work needed for Barman when PostgreSQL changes data-file internals. Tradeoff is that there's less custom optimization than pgBackRest/pg_probackup/WAL-G-local.
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).
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.
A shout out to Databasus (https://databasus.com). It’s a remarkably simply utility and web interface to schedule PostgreSQL backups. I use it in my homelab and works great.
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.
Can the plugin do non objectstore backups? E.g. If I don't want to use S3 / minio / whatever blobstore for my homelab
The plugin is specifically for handling backups via object storage.
CloudNativePG also implements support for volume snapshots: https://cloudnative-pg.io/docs/1.29/backup#backup-methods
> We use Barman inside Kubernetes via CloudNativePG's plugin, as it is the default backup plugin.
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 thought that link was actually going to have a discussion on why they chose it. No such discussion exists.
The way I read that issue and the linked discussion was, that pgBackRest handles a lot of details itself that's otherwise handled by Kubernetes. Hence, a lot of functionality in pgBackRest is not only redundant but incompatible with how Kubernetes CSI could be used to provide incremental and differential backups. Hence, Barman and `barman-cloud` plugins are a better, natural fit for a Kubernetes environment than pgBackRest.
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.
Huh... Opposite experience. Barman cloud (s3 backups) is the only way I've ever used it. I didn't realize it wasn't the only way. Makes sense it could just use a filesystem.
https://docs.pgbarman.org/release/3.14.1/user_guide/barman_c...
They have a plugin that supports backups to cloud storage
https://docs.pgbarman.org/release/3.12.0/user_guide/barman_c...
For CNPG: https://github.com/cloudnative-pg/plugin-barman-cloud
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...
There’s support via Barman cloud - we use it for azure at work but s3 and others are supported iirc
Mounting S3 with Fuse is not stable or performant enough at scale for backup storage
I can understand why it'd be preferable to avoid such a bridge layer, and indeed I too would rather just have a transparent view of what's going on at the protocol level.
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.
https://github.com/Barre/ZeroFS Should do a great job at this.
There are other ways to mount S3, but you may want to check out Amazon's new product, S3 files: https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-s3...
https://aws.amazon.com/s3/features/files/
We (ParadeDB) use Barman via CloudNativePG for almost all our deployments. It's been solid, although I've had a few complaints about 1) inability to set S3 storage classes, 2) slow upload for very large databases.
Nonetheless, very happy to see this project on the front page of HN!
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?
A side note on pgBackRest: PGX created a fork and announced to maintain it under the name pgxbackup:
https://thebuild.com/blog/2026/05/01/pgxbackup-continuity-su...
One interesting thing about Barman is that it just uses PG's own backup utilities. It doesn't implement custom parsers and things like that. So, there's less maintenance work needed for Barman when PostgreSQL changes data-file internals. Tradeoff is that there's less custom optimization than pgBackRest/pg_probackup/WAL-G-local.
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).
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.
A shout out to Databasus (https://databasus.com). It’s a remarkably simply utility and web interface to schedule PostgreSQL backups. I use it in my homelab and works great.
Its fine for HomeLab use, but its not really an alternative to something like barman. Quite heavy and vibe-coded.
Upvote, this is working well for us.