Barman 2.2 released

3 minute read

17 July 2017: 2ndQuadrant is proud to announce the release of Barman 2.2, a Backup and Recovery Manager for PostgreSQL databases.

This major release boasts a long awaited feature: the implementation of parallel copy for backup/recovery through the parallel_jobs option. This highly anticipated feature allows Barman to perform copies at an accelerated rate, speeding up the backup and recovery process for the rsync copy method.

Subito, long time partners of 2ndQuadrant and sponsor of the Barman project, participated in early testing of the parallel copy feature.

Barman’s parallel backup feature with 4 parallel jobs doubled transfer rate and cut the backup time by 60% and recovery time by 40%. (Subito Data Team)

This feature has been a goal of the development team for some time. “Parallel copy fills an important gap for Barman in very large database (VLDB) scenarios, by giving users flexibility and freedom in architecture design to help them reduce both backup and recovery times sensibly.” said Gabriele Bartolini, one of the lead developers behind Barman. “This feature takes advantage of the code refactoring activity that has been previously performed with 2.0 and 2.1 releases, including the thousands of automated tests that help us make Barman more robust.”

Other notable features in this major release include:

  • Support custom WAL size (PostgreSQL 8.4 and up)
  • Improve check command
  • Add external_configuration to backup_options
  • Add --get-wal and --no-get-wal options to barman recover
  • Add max_incoming_wals_queue global/server option for the check command
  • Documentation improvements

Additionally, several minor bug fixes have also been implemented.

For a complete list of changes, see the “Release Notes” section below.

Navionics, manufacturer of electronic navigational charts and founding sponsor of the Barman project, migrated its systems to PostgreSQL in 2012. With several servers under Barman backup, the Navionics team stated that they are proud to have contributed again in the developing of a new Barman release that includes parallel jobs. “We have been a sponsor of Barman since the first release because we need a reliable system and disaster recovery [capability] for our production servers,” stated the Navionics DBA Team. “We are sure that [parallel copy within Barman] will allow us to have faster backup and restore for our huge databases.”

Release notes

  • Implement parallel copy for backup/recovery through the parallel_jobs global/server option to be overridden by the --jobs or -j runtime option for the backup and recover command. Parallel backup is available only for the rsync copy method. By default, it is set to 1 (for behaviour compatibility with previous versions).

  • Support custom WAL size for PostgreSQL 8.4 and newer. At backup time, Barman retrieves from PostgreSQL wal_segment_size and wal_block_size values and computes the necessary calculations.

  • Improve check command to ensure that incoming directory is empty when archiver=off, and streaming directory is empty when streaming_archiver=off (#80).

  • Add external_configuration to backup_options so that users can instruct Barman to ignore backup of configuration files when they are not inside PGDATA (default for Debian/Ubuntu installations). In this case, Barman does not display a warning anymore.

  • Add --get-wal and --no-get-wal options to barman recover

  • Add max_incoming_wals_queue global/server option for the check command so that a non blocking error is returned in case incoming WAL directories for both archiver and the streaming_archiver contain more files than the specified value.

  • Documentation improvements

  • File format changes:

    • The format of file has changed. For this reason a backup taken with Barman 2.2 cannot be read by a previous version of Barman. But, backups taken by previous versions can be read by Barman 2.2.
  • Minor bug fixes:

    • Allow replication-status to work against a standby
    • Close any PostgreSQL connection before starting pg_basebackup (#104, #108)
    • Safely handle paths containing special characters
    • Archive .partial files after promotion of streaming source
    • Recursively create directories during recovery (SF#44)
    • Improve xlog.db locking (#99)
    • Remove tablespace_map file during recover (#95)
    • Reconnect to PostgreSQL if connection drops (SF#82)