Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Barman – Backup and Recovery Manager for PostgreSQL

github.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Barman – Backup and Recovery Manager for PostgreSQL

#21

Post by hephaes7us »

timacles wrote: post #18
hephaes7us wrote: post #8

Earlier quoted context omitted.

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...

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.

Re: Barman – Backup and Recovery Manager for PostgreSQL

#23

Post by mkroman »

Synthetic7346 wrote: post #20
ninjaoxygen wrote: post #4

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

Re: Barman – Backup and Recovery Manager for PostgreSQL

#24

Post by blazarquasar »

nodesocket wrote: post #12

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.

Re: Barman – Backup and Recovery Manager for PostgreSQL

#25

Post by rostislav_dugin »

blazarquasar wrote: post #24
nodesocket wrote: post #12

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.

[dead]

Re: Barman – Backup and Recovery Manager for PostgreSQL

#27

Post by gbartolini »

Tostino wrote: post #14
subhobroto wrote: post #5

Earlier quoted context omitted.

> 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…

I thought that link was actually going to have a discussion on why they chose it. No such discussion exists.

Barman Cloud was a convenient choice for CloudNativePG (CNPG) because it was developed by the same team that created Barman originally (I am part of both teams). When we started CNPG, we never anticipated it would become so popular, which has obviously resulted in some technical debt. The issue you mentioned concerns our decision not to integrate pgBackRest into CNPG's core, as we aimed to develop a pluggable interface (CNPG-I).

As a community, we have decided to support volume snapshot backups and offer the Barman Cloud plugin to ensure we provide the same level of service. Our aim is to encourage other organisations or developers to create plugins for their preferred backup solutions.

Currently, as maintainers of CNPG, we must concentrate on the core capabilities and allow the ecosystem to grow with both community and, potentially, commercial solutions based on CNPG-I.

Re: Barman – Backup and Recovery Manager for PostgreSQL

#28

Post by Tostino »

gbartolini wrote: post #27
Tostino wrote: post #14

Earlier quoted context omitted.

I thought that link was actually going to have a discussion on why they chose it. No such discussion exists.

Barman Cloud was a convenient choice for CloudNativePG (CNPG) because it was developed by the same team that created Barman originally (I am part of both teams). When we started CNPG, we never anticipated it would become so popular, which has obviously resulted in some technical debt. The issue you mentioned concerns our decision not to integrate pgBackRest into CNPG's core, as we aimed to develop a pluggable interfa…

I appreciate the response!

Completely understand your motivations considering the lineage, and I appreciate that you guys put in the effort for the backup plug-in system. I think you guys made the right choices for that project. I appreciate it much more than the Crunchy k8s project which didn't have open images.

I was definitely hoping that a pgbackrest plug-in would mature for cnpg, but I didn't realize there were troubles on the horizon for that project.

Re: Barman – Backup and Recovery Manager for PostgreSQL

#29

Post by ninjaoxygen »

gbartolini wrote: post #27
Tostino wrote: post #14

Earlier quoted context omitted.

I thought that link was actually going to have a discussion on why they chose it. No such discussion exists.

Barman Cloud was a convenient choice for CloudNativePG (CNPG) because it was developed by the same team that created Barman originally (I am part of both teams). When we started CNPG, we never anticipated it would become so popular, which has obviously resulted in some technical debt. The issue you mentioned concerns our decision not to integrate pgBackRest into CNPG's core, as we aimed to develop a pluggable interfa…

Great to see you posting on HN! I still remember making the decision to replace Crunchy Data PGO. CNPG was newer and smaller at the time, so maybe riskier, but seeing the way your team had responded to issues, had a real engineering mindset and clear knowledge of how PostgreSQL should be operated made it an easy choice!

Thank you for your efforts, I hope the balance of commercial and community works out well for you, the product is great.

Post reply on HN