One of the pghoard developers here. We developed pghoard for our use case (<a href="https://aiven.io" rel="nofollow">https://aiven.io</a>):<p>* Optimizing for roll forward upgrades in a fully automated cloud environment
* Streaming: encryption and compression on the fly for the backup streams without creating temp files on disk
* Solid object storage support (AWS/GCP/Azure)
* Survive over various glitches like faulty networks, processes getting restarted, etc.<p>Restore speed is very important for us and pghoard is pretty nice in that respect, e.g. 2.5 terabytes restored from an S3 bucket to an AWS i3.8xlarge in half an hour (1.5 gigabytes per second avg). This means hitting all of cpu/disk/network very hard, but at restore time there's not typically much else to do with them.
It would be good for the PG community to consolidate some of these projects (wall-e, wall-g, pghoard, pgbackrest, barman, etc) into the core functionality at this point.
One of the PGHoard authors will be talking about PostgreSQL backups in the cloud in a couple of weeks in PostgresConf NYC:
<a href="https://postgresconf.org/conferences/2019/program/proposals/postgresql-backups-in-the-age-of-the-cloud" rel="nofollow">https://postgresconf.org/conferences/2019/program/proposals/...</a>
How does a 'periodic backup using pg_basebackup' compare to barman's rsync and reuse_backup = link for speed of backups, and size of files?<p>I want to look at this (and Wal-G) but am not sure how much of a load I would be putting on our db servers when they do the periodic backups. Our database is pretty heavy on 'history' tables that don't change much once they are written to.
I'm going to look at this more later, but my first thought is how does this compare to WAL-e
<a href="https://github.com/wal-e/wal-e" rel="nofollow">https://github.com/wal-e/wal-e</a>