Barman 2.2 released
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.”
Links
- Website
- Download
- Documentation
- Man page, section 1
- Man page, section 5
- Support
- Client utilities for Barman
- pgespresso extension
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 thebackup
andrecover
command. Parallel backup is available only for thersync
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
andwal_block_size
values and computes the necessary calculations. -
Improve
check
command to ensure thatincoming
directory is empty whenarchiver=off
, andstreaming
directory is empty whenstreaming_archiver=off
(#80). -
Add
external_configuration
tobackup_options
so that users can instruct Barman to ignore backup of configuration files when they are not insidePGDATA
(default for Debian/Ubuntu installations). In this case, Barman does not display a warning anymore. -
Add
--get-wal
and--no-get-wal
options tobarman recover
-
Add
max_incoming_wals_queue
global/server option for thecheck
command so that a non blocking error is returned in case incoming WAL directories for botharchiver
and thestreaming_archiver
contain more files than the specified value. -
Documentation improvements
-
File format changes:
- The format of
backup.info
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.
- The format of
-
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 duringrecover
(#95) - Reconnect to PostgreSQL if connection drops (SF#82)
- Allow