Good news has come out to ensure your disaster recovery strategy is even better!
Wait…what?! You don’t have a disaster recovery strategy?! No good, my friend, no good…
But don’t despair, as I was saying, the good news is that Barman, the powerful backup and recovery manager for PostgreSQL, has just released its 1.6.0 version, which comes with important new features and, as expected, bug fixes.
So, if you are already using Barman, just update it to start using the new features. And, if you don’t yet use it, now is the time you can begin elaborating your disaster recovery plan. It’s better you don’t wait…trust me on that one. 🙂
“And what are those new features?” you ask. Here we go:
Streaming connection & WAL streaming
This is the main feature of this release. Now Barman is capable of connecting to the database server and continuously receiving WAL files via PostgreSQL’s native streaming protocol, which will reduce RPO (Recovery Point Objective). In case the streaming connection fails for any reason, the standard log archiving takes control right away, making sure WALs are being archived. This version 1.6.0 still requires that standard archiving is in place (which means you will end up transferring WAL files twice, over two different channels – but this is a small price to pay for near zero RPO).
Enabling PostgreSQL streaming connection on the Barman server is pretty straightforward. Just open the configuration file of your backup server, that is by default inside /etc/barman.d/ directory, and add the following settings:
streaming_conninfo = host=your.postgresql.server user=streaming_barman streaming_archiver = on archiver = on path_prefix = /path/to/pg_receivexlog/
Each line above provides the necessary set that Barman needs to successfully use the streaming connection:
- The first line configures
streaming_conninfoin the same way as the already present
hostindicates your PostgreSQL server.
userinforms which user will be used for this connection. The user
streaming_barmanhas to be created on your database server and granted access on pg_hba.conf accordingly.
- The second line activates the
- The third line, as you can guess, activates
archiveris activated by default, but I’m including this line here to make sure I tell you that. 🙂
- The fourth line indicates the directory where
pg_receivexlogcan be found. For example, it could be
/usr/pgsql-9.5/bin/. Barman uses it for the WAL streaming and, as
pg_receivexlogis not present on the Barman server by default, you have to install the PostgreSQL client to operate effectively. It isn’t necessary to install the PostgreSQL server on your Barman server, only the client.
As a last tip, for the streaming connection to work, make sure you have
psycopg2 installed with version 2.4.2 or newer on your PostgreSQL server.
Implicit restore point
Although this feature has been present since version 1.5.1, as it wasn’t mentioned in the Barman documentation until now, I think it is worth listing here. Barman automatically creates a restore point in the form “barman_BACKUPID” immediately after the backup, allowing users to use this label during recovery through the use of the option
New WAL compression algorithms
Besides the previous included gzip and bzip2 compression algorithms, now it is also possible to compress the WAL files using the pigz, pygzip, and pybzip2 algorithms (thanks to Stefano Zacchiroli and Christoph Moench-Tegeder). Do not forget that it is also possible to specify your own custom compression/decompression filter.
Customisation of binary paths
The new configuration option
path_prefix allows you to list the directories where you want Barman to look for executables as, for example,
pg_receivexlog used for WAL streaming. Above, on Streaming connection & WAL streaming section, it is shown how to use this option.
Barman has been a well known choice when DR comes to mind and if you want to get a complete list of its features, as well as information about how to configure and use it, the Barman documentation is a helpful place to check and it’s always on hand.