does anyone know how this compares to wal-e ?
This separate instance is then called from primary's "archive_command", which usually looks like: archive_command = 'rsync -a %p barman@10.0.0.1:/var/lib/barman/main-db-server/incoming/%f' and once rsync'd barman does it's own magic on it (thru cron). Based on my observations, wal-e is more powerful if you want to store archives remotely (and is primarily an archiving solution), and barman is kinda the official backup solution (2ndQuadrant is a big contributor in the community) plus it offers point-in-time recovery.
Barman + Repmgr (which can do an automatic failover or a manual switchover) is a powerful combo. If only there were reliable tools to determine the master and slave (like Redis Sentinels)
Because wal-e + s3 is killer. I seriously dont think that the headache of managing a backup server is worth it.
Is there is a situation where barman's usecase is superior to wal-e ?
1) Zero data loss backups (as far as I know, Barman is the first backup tool for PostgreSQL to implement it)
2) Monitoring ('check' command)
3) Hybrid WAL shipping (archiving + streaming)
4) Incremental backups
5) Faster recovery time (backups are stored as plain files, you can have incremental recovery and you can use 'get-wal') - also we are working on parallel backup and recovery
6) Backup from a standby
In terms of management, Barman is very low maintenance, but the outcomes you get are relevant.
If you have multiple PostgreSQL servers, you can concentrate backups in a single Barman host. Every server can have its own settings allowing you to implement hybrid solutions (you can mix versions, backup methods such as rsync or pg_basebackup, WAL archiving, WAL streaming, and so on).
As said above by "amenonsen", with hook scripts you can also relay WAL files to S3 very easily, and create a backup of your backup.
That is why I think having a separate backup server has more pros than cons.
I hope this helps.