Barman backup and recovery manager for PostgreSQL(pgbarman.org)
pgbarman.org
Barman backup and recovery manager for PostgreSQL
http://www.pgbarman.org/
3 comments
While looking beyond a pg_dump-style approach to backup/recovery, I was considering https://github.com/heroku/WAL-E and discovered Barman. It's also open source, and looks like a strong contender.
Another option which I've been looking at is pg_rman ( http://code.google.com/p/pg-rman/ ) .
It's several years old, from NTT, and with a BSD license. It seems a bit simpler , and lists a couple of useful features such as compression and backup maintenance which don't seem to be in barman yet.
Also, from looking at the barman FAQ : "We are currently seeking sponsors willing to fund the addition of this feature to the open-source version." is something it would be nice to get clarification on, in case some features in the future only go into a closed version.
It's several years old, from NTT, and with a BSD license. It seems a bit simpler , and lists a couple of useful features such as compression and backup maintenance which don't seem to be in barman yet.
Also, from looking at the barman FAQ : "We are currently seeking sponsors willing to fund the addition of this feature to the open-source version." is something it would be nice to get clarification on, in case some features in the future only go into a closed version.
As core team member of Barman (and manager), I want to start answering from the bottom of your request.
I actually thank you for giving me the chance to answer to this question and to talk about Barman in general.
2ndQuadrant has adopted the open-source business model, and we have a long history of contributions to the PostgreSQL project and its evolution (I encourage you to verify my words). This applies to satellite projects too, including repmgr (High Availability) and Barman (Disaster Recovery). With Barman we have a precise statement: it has to be open-source and to remain open-source, under GNU GPL 3. Being a business, we need to fund the development of features through our consulting services in Disaster Recovery or through feature sponsorships. But our intention is that everything will be released open-source (otherwise, why bother releasing this software in the first place?).
On a more technical point of view, one of the main characteristics of Barman is that it does not require to be physically located where the Postgres server resides. It performs remote backup (if you can, you can do local backups too, but I prefer sharing nothing between a backup server and a production server - points of view?). If you think about it carefully, this also gives more flexibility in terms of architecture, especially in large master-slave scenarios (you do not need to install Barman on every Postgres server or share the same file system, for instance).
Barman can compress transactions/WAL files (bzip2, gzip or custom) and has a parallel management of the WAL archive and periodical backups (I suggest you read this article where we describe the association between a WAL segment and a backup http://blog.2ndquadrant.com/management-wal-archive-barman/).
Currently it does not automatically compress periodical backups, but gives a clear and simple interface to archiving (to give you an idea, we have a customer that regularly - every week - transfers on tapes a 6TB database with Barman). Current development version has already hooks for pre and post backup operations. Next boundaries will be incremental backup and retention policies (what you probably call backup maintenance) - as I said, depending on fundings we receive.
Another important aspect of Barman is that you can have a backup server managing multiple PostgreSQL servers, from one single place, and having a catalogue of periodical backups.
Then ... I'd say remote recovery, data directory and tablespace relocation during recovery, Point in Time recovery, diagnostics, etc.
If you have more information, you can join the IRC channel too or the mailing list (details on www.pgbarman.org).
2ndQuadrant has adopted the open-source business model, and we have a long history of contributions to the PostgreSQL project and its evolution (I encourage you to verify my words). This applies to satellite projects too, including repmgr (High Availability) and Barman (Disaster Recovery). With Barman we have a precise statement: it has to be open-source and to remain open-source, under GNU GPL 3. Being a business, we need to fund the development of features through our consulting services in Disaster Recovery or through feature sponsorships. But our intention is that everything will be released open-source (otherwise, why bother releasing this software in the first place?).
On a more technical point of view, one of the main characteristics of Barman is that it does not require to be physically located where the Postgres server resides. It performs remote backup (if you can, you can do local backups too, but I prefer sharing nothing between a backup server and a production server - points of view?). If you think about it carefully, this also gives more flexibility in terms of architecture, especially in large master-slave scenarios (you do not need to install Barman on every Postgres server or share the same file system, for instance).
Barman can compress transactions/WAL files (bzip2, gzip or custom) and has a parallel management of the WAL archive and periodical backups (I suggest you read this article where we describe the association between a WAL segment and a backup http://blog.2ndquadrant.com/management-wal-archive-barman/).
Currently it does not automatically compress periodical backups, but gives a clear and simple interface to archiving (to give you an idea, we have a customer that regularly - every week - transfers on tapes a 6TB database with Barman). Current development version has already hooks for pre and post backup operations. Next boundaries will be incremental backup and retention policies (what you probably call backup maintenance) - as I said, depending on fundings we receive.
Another important aspect of Barman is that you can have a backup server managing multiple PostgreSQL servers, from one single place, and having a catalogue of periodical backups.
Then ... I'd say remote recovery, data directory and tablespace relocation during recovery, Point in Time recovery, diagnostics, etc.
If you have more information, you can join the IRC channel too or the mailing list (details on www.pgbarman.org).
Thanks for the update on the licensing.
Barman does have a lot of great features, and hopefully I will be able to try it out on a test system sometime soon.
Barman does have a lot of great features, and hopefully I will be able to try it out on a test system sometime soon.
I have no vested interest either way, but barman does appear to support compression and backup maintenance - it has a built in command for running all maintenance tasks, including compressing backups and moving them to archival storage.
This comes from 2ndQuadrant, so hopefully they will leave the core version as open-source.
This comes from 2ndQuadrant, so hopefully they will leave the core version as open-source.
Terminology conflict I think :-) The pg_rman docs call backup retention management "backup maintenance" , and retention management is one of the things on the barman todo list.
As for compression, I think barman does log compression not the backups, but it could simply be that the barman docs [1] are out of date where they say :
"Barman’s most wanted features include: backup catalogues, retention policies, remote recovery, archiving and compression of WAL files and of backups."
[1] http://docs.pgbarman.org/
As for compression, I think barman does log compression not the backups, but it could simply be that the barman docs [1] are out of date where they say :
"Barman’s most wanted features include: backup catalogues, retention policies, remote recovery, archiving and compression of WAL files and of backups."
[1] http://docs.pgbarman.org/
You are right. I confirm, currently it is only WAL compression (documentation is up to date). I hope that we can add one between incremental backups and retention policies in version 1.1. Which are part of the most wanted features still. :)
By then, we'd love to have a Debian package too.
Thank you.
By then, we'd love to have a Debian package too.
Thank you.
Ah, that makes sense, thanks for the clarification.
I've used WAL-E[1] in production for almost a year now. It was painless to setup and configure and has been working flawlessly for the entire time. I've had to do database recoveries, point-in-time recoveries, and database upgrades, and WAL-E has worked through all of them.
[1]: https://github.com/heroku/WAL-E