wal-e VS pghoard

See the GitHub: https://github.com/wal-e/wal-e

Unmaintained would’ve made more sense to say, but the maintainer choose the words “obsolete” so I took those. :)

Seems to be obsolete due to a lack of interest and contributions.

I believe the idea originally started with Wal-E project (https://github.com/wal-e/wal-e) since then there were many improvements to it and AWS no doubt has their own proprietary solution.

Hope this helps someone out there.

https://github.com/wal-e/wal-e

Running your own postgres server on AWS is not difficult. You'll want to get familiar with EBS and look into using a tool like wal-e to manage your WAL logs and ensure yuor ability to recover from the various exciting failure modes that Amazon makes available to you.

These read-replicas leveraged WAL segments created by the primary database; however, we didn’t want to bog down the primary database with each replica by reading directly from production. To circumvent this issue, we leverage wal-e, a tool that performs continuous archiving of PostgreSQL WAL files and base backups, and read replicas restored from s3 or gcs versus reading directly from the primary database.

Have a look at barman, pgBackrest or for maybe WAL-G or WAL-E

I am using the following docker image https://github.com/docker-library/postgres. I want the ability to make regular backups to my S3 bucket. PITR is not necessary but a nice to have. I've tried to use https://github.com/wal-e/wal-e but I've not found something that works very well with docker.

This story starts with our own PgHoard, a PITR backup tool for PostgreSQL. PgHoard offers several methods to archive the WAL (Write Ahead Log), including pg_receivewal, a small application shipping with PostgreSQL which connects to a PostgreSQL cluster using the physical replication protocol to stream WAL as they are produced, optionally keeping track of the position on the server using a replication slot.