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).