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.