How to do it…

We will start by looking at Barman's main configuration file:

  1. As root on malcolm, open the /etc/barman.conf file for editing. This file contains global options for Barman. Once you are familiar with the main configuration options, I recommend that you set the default compression method by uncommenting the following line:
compression = gzip
  1. Add the configuration file for the angus server. Drop the angus.conf file, containing the following lines, into the /etc/barman.d directory:
[angus] 
description =  "PostgreSQL Database on angus" 
active = off 
archiver = on 
backup_method = rsync 
ssh_command = ssh postgres@angus 
conninfo = host=angus user=barman dbname=postgres
  1. You have just added the angus server to the list of Postgres servers managed by Barman. The server is temporarily inactive until configuration is completed. You can verify this by typing barman list-server, as follows:
[root@malcolm]# barman list-server
angus - PostgreSQL Database on angus (inactive)
  1. In this recipe, you will be executing commands as root user. Be aware, however, that every command will be executed by the barman system user (or, more generally, as specified in the configuration file by the barman_user option).

Anyway, it is now time to set up continuous archiving of WAL files between Postgres and Barman. Execute the barman show-server angus command and write down the directory for incoming WALs (incoming_wals_directory):

[root@malcolm]# barman show-server angus

Server angus (inactive):
active: False
archive_command: None
archive_mode: None
     incoming_wals_directory:     
     /var/lib/barman/angus/incoming
  1. The next task is to initialize the directory layout for the angus server, through the check command. You are advised to add this command to your monitoring infrastructure as, among other things, it ensures that the connection to the Postgres server via SSH and libpq is working properly, as well as continuous archiving. It returns 0 if everything is fine:
[root@malcolm]#

barman check angus
Server angus (inactive):
  WAL archive: FAILED (please make sure WAL    shipping is setup)
  PostgreSQL: OK
  superuser: OK
  wal_level: FAILED (please set it to a higher level than 'minimal')
  directories: OK
  retention policy settings: OK
  backup maximum age: OK (no last_backup_maximum_age provided)
  compression settings: OK
  failed backups: OK (there are 0 failed backups)
  minimum redundancy requirements: OK (have 0 backups, expected at least 0)
  ssh: OK (PostgreSQL server)
  not in recovery: OK
  archive_mode: FAILED (please set it to 'on' or 'always')
  archive_command: FAILED (please set it accordingly to documentation)
  archiver errors: OK

[root@malcolm]# echo $?
1
  1. As you can see, the returned value is 1, meaning that the angus server is not yet ready for backup. The output suggests that archive_mode and archive_command in Postgres are not set for continuous archiving. Connect to angus and modify the postgresql.conf file by adding this:
archive_mode = on
archive_command = 'rsync -a %p      barman@malcolm:/var/lib/barman/angus/incoming/%f'
 
wal_level = replica
  1. Restart the PostgreSQL server.
  2. Activate the server in Barman, by removing the line that starts with active.
  3. Run the check command on malcolm (suppressing the output with -q) again, and compare the results with what you got earlier:
[root@malcolm]# barman -q check angus 
[root@malcolm]# echo $?
0

It returned 0. Everything is all good! PostgreSQL on angus should now be regularly shipping WAL files to Barman on malcolm, depending on the write workload of your database.

Do not worry if the check command complains with the following error:

WAL archive: FAILED (please make sure WAL shipping is setup)

It is a precautionary measure we had to take in order to prevent users from going live without a working archiving process. That means that your server (like angus in this case) has a very low workload and no WAL files have yet been produced, shipped, and archived. If you want to speed up the installation, you can execute the following commands:

[root@malcolm]# barman switch-wal --force --archive angus
[root@malcolm]# barman archive-wal angus

I recommend that you check both the PostgreSQL and Barman log files and verify that WALs are correctly shipped. Continuous archiving is indeed the main requirement for physical backups in Postgres.

  1. Once you have set up continuous archiving, in order to add the disaster recovery capability to your Postgres server, you need to have at least one full base backup. Taking a full base backup in Barman is as easy as typing one single command. It should not be hard for you to guess that the command to execute is barman backup angus.

Barman initiates the physical backup procedure and waits for the checkpoint to happen, before copying the data files from angus to malcom using rsync:

[root@malcolm]# barman backup angus
Starting backup using rsync-exclusive method for server angus in /var/lib/barman/angus/base/20171003T194717
Backup start at xlog location: 0/3000028 (000000010000000000000003, 00000028)
This is the first backup for server angus
WAL segments preceding the current backup have been found:
  000000010000000000000001 from server angus has been removed
Copying files.
Copy done.
This is the first backup for server angus
Asking PostgreSQL server to finalize the backup.
Backup size: 21.1 MiB
Backup end at xlog location: 0/3000130 (000000010000000000000003, 00000130)
Backup completed
Processing xlog segments from file archival for angus
  000000010000000000000002
  000000010000000000000003
  000000010000000000000003.00000028.backup

It is worth noting that, during the backup procedure, your PostgreSQL server is available for both read and write operations. This is because PostgreSQL natively implements hot backup, a feature that other DBMS vendors might make you pay for.

From now on, your angus PostgreSQL server is continuously backed up on malcolm. You can now schedule weekly backups (using the barman user's cron) and manage retention policies so that you can build a catalog of backups covering you for weeks, months, or years of data, and allowing you to perform recovery operations at any point in time between the first available backup and the last successfully archived WAL file.