Barman 3.17 – How the Latest Release Changes Your PostgreSQL Backup Game
Barman 3.17 drops in with a handful of tweaks that actually matter when you’re juggling remote backups, S3 compliance, or a server that’s been put on ice. In this post I’ll walk through the bits you can start using today and warn you about the things that will bite if you ignore them.
Operations on Inactive Servers
In older versions you had to re‑enable a server just to peek at its catalog or pull a WAL file. That was a pain when the config was deliberately disabled because the host was flaky or under maintenance. Barman 3.17 lets you run barman list-backup, barman get-wal and even full restores against a server marked inactive.
Why this matters: I’ve seen DBAs re‑enable a production node just to copy a missing WAL, only to accidentally trigger a new backup that clobbers disk space. With the new flag you can safely query or restore without waking the sleeping dog.
S3 Object Lock Support
If your organization is subject to governance retention policies, you’ve probably wrestled with accidental deletions in an S3 bucket that has Object Lock enabled. The barman-cloud-backup-delete --check-object-lock option now aborts the delete if any locked objects are present.
Custom SSH Ports for Remote Restore
Not every shop runs SSH on port 22. Some firewalls force you onto 2222, 443, or even an obscure high‑numbered port. The new --recovery-option-port flag lets the barman restore command pass a custom port straight to barman-wal-restore.
How to use it:
- Identify the non‑standard SSH port on your target host (e.g., 2222).
- Run barman restore mydb /var/lib/pgsql/13/data --recovery-option-port=2222.
- Barman will open the tunnel on that port, pull the WALs and spin up the restored cluster.
Skipping this step used to mean you’d get a “connection refused” error and have to edit config files manually – now it’s a one‑liner.
Deprecation of Custom Compression
Barman 3.17 finally says goodbye to the old custom_compression filter. If you’re still feeding your backups through a home‑grown gzip wrapper, plan to switch to one of the built‑in algorithms (gzip, bzip2, lz4, xz, zstd, or pigz). The native options are faster, better supported and won’t disappear in the next minor release.
I’ve watched teams keep a custom script alive for years because “it works”. When the underlying library got upgraded, their backups started failing with obscure checksum errors. Upgrading to a supported algorithm saved them from a weekend of data‑recovery drills.
Minor Fixes Worth Mentioning
- S3 Compatibility – The delete command now parses error messages that contain “content-MD5”, preventing false failures on MinIO or other S3‑compatible stores.
- Delta Restore Logic – Barman no longer wipes the destination directory before a delta restore, which used to break incremental restores on busy servers.
- Mount Point Safety – Restores won’t try to rm a mount point that houses PGDATA or tablespaces, avoiding “rm execution failed” crashes.
- macOS UnicodeDecodeError – A fix for undecodable bytes when checking file encryption means the tool runs cleanly on macOS laptops used by developers.
If you’re already running Barman 3.16 in production, schedule a quick upgrade window and test the inactive‑server restore flow first – it’s the change that will most likely affect your daily ops. And for anyone still clinging to custom compression scripts: replace them now or prepare for a broken backup pipeline later this year.
You may download the most recent version of Barman from here. For details on new features, bug fixes, and other changes, please refer to the release notes.
