Wow, this is pretty surprising, I was under the impression that this is the leading PG backup/recovery tool.

Anybody know how WAL-G and Barman compare?

__s an hour ago | parent | next [-]

I'm one of many wal-g maintainers, it's comparable. I've been inactive for past few years, but back in managed postgres game. Hoping to get support for pg17 incremental backups alongside wal-g's existing delta backups where wal-g compares blocks itself. Be sure to use daemon mode

Sad to see competitor go, I think there's lots of room for improvement here, & C over Golang is particularly nice when postgres wants to run on system without overcommit

▲

zie 3 hours ago | parent | prev | next [-]

I dunno how they compare, but we have been using barman for a long time very happily. We test our backups every night, by restoring from barman into a _nightly DB. which we then give out to users as a training/testing spot, so that we know when it breaks. It hasn't broken in many years now. <3

▲

noosphr 7 hours ago | parent | prev | next [-]

>Wow, this is pretty surprising, I was under the impression that this is the leading PG backup/recovery tool.

https://xkcd.com/2347/

▲

andruby 6 hours ago | parent | prev [-]

We've been happy with WAL-E and now WAL-G (successor). The streaming PITR nature of these won over pgbackrest when we did the analysis ~9 years ago.

▲

fabian2k 6 hours ago | parent [-]

Are you using WAL archiving? As far as I understand, pgbackrest and Barman can also use direct streaming from the DB (same mechanism as replication), I didn't find any mention of this in the WAL-G documentation.

With WAL archiving you need to wait for a WAL segment to finish before it's backed up. With streaming backups the deadtime is minimized. At least that's as far as I understand this, I didn't get to try this out in practice yet.

▲

andruby 5 hours ago | parent [-]

WAL-G's PITR backups are insurance against data loss through erroneous data manipulations (eg: accidental DELETE/DROP/UPDATE). WAL-G's streaming approach (using pg_receivewal or similar) sends WAL records to backup storage continuously as they're generated, rather than waiting for a full segment to complete.

On top of that, for availability (and minimizing deadtime), we have 2 replicas using streaming replication. If the lead PG crashes, one of the replicas is promoted to lead (and starts accepting writes), and we "only" lose the writes that haven't been sent over the streaming replication.

You can fully eliminate that window of data loss with synchronous replication (vs the default asynchronous replication - which we use). The write slowdown (replica network round trip + 2nd write at replica) isn't worth it for us

	▲	dwwoelfel 44 minutes ago \| parent [-]
		Are you using `walg wal-receive` for streaming? As far as I can tell, that command will wait for the full wal segment before it pushes anything to storage. I don't see any way to stream wal records continuously in wal-g.