| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| barman-3.17.0.tar.gz.md5 | 2026-01-07 | 55 Bytes | |
| barman-3.17.0.tar.gz | 2026-01-07 | 472.6 kB | |
| barman-3.17.0-py2.py3-none-any.whl | 2026-01-07 | 520.8 kB | |
| barman-3.17.0-manual.pdf | 2026-01-07 | 1.4 MB | |
| README.md | 2026-01-07 | 6.7 kB | |
| Release 3.17.0 source code.tar.gz | 2026-01-07 | 2.0 MB | |
| Release 3.17.0 source code.zip | 2026-01-07 | 2.2 MB | |
| Totals: 7 Items | 6.5 MB | 0 | |
Barman release notes
© Copyright EnterpriseDB UK Limited 2026 - All rights reserved.
3.17.0 (2026-01-07)
Notable changes
- Enable query, fetch, and selective operations on inactive/disabled servers
Multiple Barman commands now work with inactive and disabled servers based on their safety profile:
Query commands:
- list-backups: view backups from inactive/disabled servers
- status: check status of inactive/disabled servers
- show-backup: display backup details from inactive/disabled servers
- list-files: list files from backups on inactive/disabled servers
- verify-backup: verify backups on inactive/disabled servers
Fetch commands:
- restore: restore backups from inactive servers
- get-wal: retrieve WAL files from inactive servers
Modification commands:
- delete: delete backups from inactive servers
- config-switch: switch configuration models for inactive/disabled servers
This change improves operational flexibility by allowing users to query backup information and perform restore operations even when servers are manually disabled (inactive) or have configuration issues (disabled). The different behavior for disabled servers provides safety against operations on servers with potential configuration conflicts or path issues.
References: BAR-976.
- Deprecate custom compression for WAL files
The custom compression option and its related configuration options
(custom_compression_filter, custom_decompression_filter, and
custom_compression_magic) are now deprecated and will be removed in a
future release.
Users currently using custom compression are advised to migrate to one of the
built-in compression algorithms supported by Barman: gzip, bzip2, lz4,
xz, zstd, or pigz.
The custom compression feature was designed to provide flexibility for users with specific compression requirements, but maintaining compatibility with arbitrary external compression tools has proven to be complex and error-prone. The built-in compression options provide better performance, reliability, and maintainability.
Existing configurations using custom compression will continue to work in the current release, but users should plan to migrate their configurations before the feature is removed.
References: BAR-993.
Minor changes
- Handle non-UTF8 output when checking for file encryption
In certain scenarios, such as when recovering WALs via barman-wal-restore or
running barman rebuild-xlogdb, Barman executes the file command to check
whether a file is encrypted.
On macOS systems (which are not officially supported), this command was reported
to be raising a UnicodeDecodeError exception if its output contained bytes that
could not be decoded using UTF-8.
To prevent this, Barman now handles undecodable bytes gracefully, allowing the process to continue without interruption.
Github issue: [#1117]
References: BAR-926.
- Add
--recovery-option-porttobarman restorecommand
When doing a remote restore with get-wal mode, Barman writes a restore_command
which invokes barman-wal-restore to fetch WALs. However, there was currently no
way to specify a custom port to the written barman-wal-restore command.
This change introduces the --recovery-option-port flag to the barman restore
command, allowing users to specify a value for the --port option of
barman-wal-restore command during remote restores.
References: BAR-943.
- Add S3 Object Lock support for the deletion of backups in barman-cloud
barman-cloud-backup-delete now supports checking for Object Lock before
deleting backups in AWS S3. This feature helps prevent deletion of objects
protected by compliance or governance retention policies.
A new --check-object-lock option has been added, which enables Object Lock
verification before deletion. When enabled, the deletion operation for all objects of
a base backup will be aborted if any of those objects is locked. For performance
reasons, lock checks are only performed for base backup files, since once the
base backup is removed, the corresponding WAL files are no longer useful.
Note that this feature adds overhead to the delete operation, as it requires an additional API call for each object being deleted. This feature is only available for AWS S3-compatible object stores and requires the appropriate permissions to function correctly.
References: BAR-946.
Bugfixes
- Increase coverage of non-compliant S3 object stores for backup deletion
With this fix we increase the coverage of non-compliant S3 object stores for backup deletion.
We've reduced the expression we were matching for the message returned on failure to catch any error code that returns a message that contains "content-MD5".
We believe with this, almost all non-compliant S3 object stores for backup deletion will be covered
References: BAR-974.
- Fix passive node not syncing
In Barman 3.16 the "name" field was removed from the "config" key of
the barman diagnose command. Turns out the same "config" data is also
used when syncing a passive node, and the absence of the "name" field
caused the sync to fail.
This change adds back the "name" field to the "config" key, fixing the sync of passive nodes.
Reported in GitHub issue [#1125].
References: BAR-971.
- Fix delta restore not working
The delta restore feature was not functioning correctly due to an oversight where Barman was removing the destination directory before performing a restore. The problem was fixed by avoiding the removal of the destination directory on certain operations. Reported in GitHub issue [#1139].
References: BAR-1002.
- Fix "rm execution failed" errors during restore
As a consequence of a refactoring implemented during the release of version 3.15, Barman started removing the destination directory of the restore operation before copying backup files. This was to ensure that the files were always being copied to a clean directory.
However, when the destination directory is a mount point, or a subdirectory where the user does not have sufficient permissions on its parent, the removal of the directory fails, leading to errors like "rm execution failed".
The issue is now fixed by avoiding the removal of the destination directory for PGDATA and tablespaces on the restore final destination.
References: BAR-975.