12 ms·

The big conceptual difference is that with WAL-E, all your backup code and configuration is on your Postgres server, whereas with Barman, it's all (or almost al

The big conceptual difference is that with WAL-E, all your backup code and configuration is on your Postgres server, whereas with Barman, it's all (or almost all) on your backup server. WAL-E stores backups in S3 (or S3-alikes), whereas Barman is built around the idea of having a backup server (it can store backups in S3 too, but it's not central to its operation as it is with WAL-E).

sandGorgon 10y ago
hey - thanks for this. it makes things much simpler. This then begs the question - can this run on AWS Lambda and archive to s3 ? 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 ?
- gbartolini 10y ago
  Some food for thought. These are the first cases that came to my mind: 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.
  - sandGorgon 10y ago
    thanks - this was very useful!

sandGorgon 10y ago

hey - thanks for this. it makes things much simpler. This then begs the question - can this run on AWS Lambda and archive to s3 ? 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 ?

gbartolini 10y ago
Some food for thought. These are the first cases that came to my mind: 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.
- sandGorgon 10y ago
  thanks - this was very useful!