Why we recommend to install Barman on a separate server

A recurring question we receive is: "Can I install Barman on the same server where PostgreSQL resides?". Learn from the authors of Barman why we decided to design the software with shared nothing architecture and work remotely from the start.

Barman was conceived to be installed on a separate server, in the same data center where the PostgreSQL cluster(s) to be backed up reside.

While for evaluation, development and testing purposes you can install Barman on the same host where PostgreSQL resides (by using SSH to localhost), for production environments we recommend to use a dedicated server for Barman. Physical and virtual servers are both an option, as long as any hardware or storage are not shared with the database server.

Here follows a short list of reasons behind this choice.

1. Your backups will still be available after a hardware failure of the PostgreSQL server.
2. Keeping Barman independent from any server participating in a replication cluster improves maintenance of the cluster during switchover and failover operations, as well as making them faster (there are fewer things to do)
3. Barman acts as a witness and increases robustness of the cluster if integrated into the monitoring infrastructure (see barman check command and its --nagios option)
4. If Barman is on a third node, you can implement a 3 node cluster with synchronous replication (Barman acts as fall-back) and achieve zero data loss backups
5. You have the option to take a backup from a standby, reducing the I/O impact on the master server
6. A shared nothing approach between the Barman server and the Postgres one highly reduces risk of data loss and reduces the impact on the master server
7. A separate Barman server allows your standby servers to take advantage of the barman-wal-restore+ get-wal facility, making them more resilient
8. You can take advantage of parallel copy
9. An independent server for backup facilitates recovery tests and better suits with disaster recovery plans for periodic simulations of recovery from failures

This is the typical architecture we recommend and install on our customers' premises that allows us to reach very high business continuity goals, such as low RTO and RPO = 0 ( or ~0 if you do not use synchronous replication).