Barman Kickoff - What you need to know before installing Barman

Before the installation of Barman on your Linux server can be initiated, we ask that you provide some additional information about your disaster recovery requirements. In addition, we would like to work with you to understand and/or help you define your disaster recovery processes.

This document details the information needed to successfully kickoff your Barman installation. Please fill out the final page of the document to the best of your ability with the information requested.

In order to install and configure Barman we will need to access the Barman and PostgreSQL servers through SSH. Please let us know if we can access them directly using a pool of trusted, static IP addresses or if we will need to access through VPN.

2ndQuadrant strongly recommends to have a separate server dedicated to Barman, possibly on a different storage than the PostgreSQL server.

Having a separate server makes the overall architecture of your PostgreSQL servers simpler, and therefore easier to maintain, especially when you have standby servers involved.

It is typically suggested to share just the network between the PostgreSQL server and Barman, in order to reduce the risk of data loss after a failure or a disaster - both inevitable.

Due to its “get-wal” capability, the WAL archive of Barman can be used as an “infinite” basin by all your standby servers, as a fallback method in case of problems with streaming replication (see the "Integration with standby servers" section below).

In addition, another important reason is that the Barman server can be used as control room for recovery operations, as well as monitoring (very important in case you decide to share the same Barman server with more PostgreSQL servers).

2ndQuadrant suggests to keep the Barman server in proximity to the PostgreSQL servers (if not in the same data centre. At the very least, make certain that connectivity is sufficient, especially if the intention is to use Barman in a “zero data loss” context with RPO=0.

2ndQuadrant will need the IP addresses and hostnames of the PostgreSQL servers that are intended to be backed up with Barman, including their PostgreSQL version. If available, the IP address and hostname of the Barman server are also requested.

Barman will be used to backup one or more existing PostgreSQL servers. In order to estimate how much disk space is required for Barman, it is important for 2ndQuadrant to know the following:

• Total size of all databases on the PostgreSQL server
• WAL production rate
• Frequency of full backups (weekly/daily)
• Retention policies required by your business (e.g. 4 weeks or last 2 backups)
• Expected growth rate of the database

It is possible to use EDB's Lasso to gather information about the PostgreSQL production server, in particular size of the instance and WAL production. We recommend to gather at least two samples so that we can estimate the number of WALs generated by your PostgreSQL server within that timeframe. It is important to select a meaningful period for data sampling.

Will Barman run on a virtual machine or a dedicated physical server? 2ndQuadrant suggests choosing the approach that best suits your business needs. Barman simply needs disk space and cores (depending on the number of PostgreSQL servers that need to be backed up and their size).

2ndQuadrant develops and supports Barman packages for the major Linux distribution. It is necessary to know which distribution the Barman server will be installed on.

Please let us know what your storage strategy with Barman is going to be, such as local disks on a physical server, or a NFS volume on a virtual machine in VMWare, and so on.

Barman supports the following two backup methods:

1. rsync/ssh: this approach requires an SSH passwordless connection between the Barman server (barman user) and the PostgreSQL server (postgres user). One of the advantages of this approach is that it enables incremental backup (through hard links) and network compression.
2. postgres: this approach relies on pg_basebackup, the main physical backup application distributed alongside with PostgreSQL. pg_basebackup requires a PostgreSQL streaming replication connection between the Barman server and the PostgreSQL server. While this approach does not require an SSH connection, it does not support incremental backup and network compression. PostgreSQL 9.1+ is required. This is the only option if you run PostgreSQL on Windows.

A backup that is not tested is not a valid backup.

It is suggested that one or more servers are dedicated for recovery, including Business Intelligence or staging purposes. Thanks to hook scripts, Barman allows users to setup an automated rebuild of recovery PostgreSQL servers, enabling unsupervised testing of backups.

Monitoring is the most important characteristic of an ICT infrastructure with business continuity requirements. One of the main reasons behind the conception of Barman is the integration with monitoring tools.

The barman check command has been present since the first prototype of Barman and is a very handy way to verify that all major components of a PostgreSQL disaster recovery solution are working smoothly. If Nagios/Icinga are in use, Barman can natively work as a NRPE agent. Please let us know if you plan to monitor Barman proactively - as we recommend.

RPO stands for Recovery Point Objective. It is a business continuity metric that defines the “maximum targeted period during which data might be lost from an IT service due to a major incident”. Properly configured, an open source solution consisting of Barman and PostgreSQL, combined with streaming replication can achieve an RPO of 0. Please indicate the desired RPO for your PostgreSQL database.

RTO stands for Recovery Time Objective. It is a business continuity metric that defines the “targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity”. In Barman, this is generally measured by the time that it takes for you to recreate a PostgreSQL server from scratch and recover the latest available data (or up to a point in time) from an available backup. Please indicate your desired RTO.

Let us know if you want your Barman to relay both WAL files and base backups to your Amazon S3 bucket in the Cloud, making your disaster recovery solution more resilient.

Barman stores WAL files for all your backups. Therefore, depending on your retention policy settings, you can have several days/weeks/months worth of WAL files.

Thanks to both Barman’s get-wal command and the barman-cli package (to be installed on every PostgreSQL server), your standby server can pull the required WAL files from Barman, in case of temporary/prolonged connection issues with streaming replication.

Let us know if this is your use case and/or if you plan to integrate Barman with repmgr repmgr, a leading open-source technology for PostgreSQL high availability, developed and maintained by 2ndQuadrant.

At 2ndQuadrant we value regular testing and simulations of disasters. Please let us know if you would like to get basic training on Barman and disaster recovery, as well as assistance with your PostgreSQL disaster recovery plan. Enquire about our training program on Barman and disaster recovery simulation procedures.

Please do not hesitate to ask us if you need further information on Barman and how to move forward with the installation.

1. Where is the Barman server located?

• Same data centre as PostgreSQL
• Different data centre in the same metropolitan area
• Remote data centre

2. How will we access your servers? In order to install and configure Barman we will need to access the Barman and PostgreSQL servers through SSH. Please let us know if we can access them directly using a pool of trusted, static IP addresses or if we will need to access through VPN.
3. List IP addresses and hostnames of the PostgreSQL Server(s) to be backed up with Barman (including their version number):
4. Where will you host Barman?

• Virtual Machine
• Physical Server

5. Which Linux distribution are you going to install on the Barman server?

• CentOS 7
• RHEL 7
• Ubuntu 16.04
• Other (please specify)

6. What type of storage will you use?

• Local disks
• NFS Volume on a virtual machine in VMWare
• Other (please specify)

7. Please provide the required disk space for the following:

• Total size of all databases on the PostgreSQL server
• WAL production rate
• Frequency of full backups (weekly/daily)
• Retention policies required by your business (e.g. 4 weeks or last 2 backups)
• Estimated growth rate of the database

8. Which backup method would you prefer to use?

• rsync/ssh
• PostgreSQL’s pg_basebackup

9. What is your desired Recovery Point Objective (RPO)?
10. What is your desired Recovery Time Objective (RTO)?
11. Do you plan to relay your files to S3?
12. Will you require integration with a monitoring infrastructure?
13. Will you have a dedicated server(s) for recovery?
14. Will you require integration with Standby Servers?
15. Would you like to perform Disaster Recovery training and simulations?