Barman for PostgreSQL Files

3.16.0 (2025-10-02)

Notable changes

• The restore_command for local restores no longer includes sudo

When using barman restore --get-wal for a local restore (i.e. without --remote-ssh-command), the generated restore_command no longer includes a sudo -u $USER prefix. This simplifies the process for the common case where the locally restored Postgres cluster is run by the barman user, whom already owns the files by the end of the barman restore operation.

Action Required: If you intend to run the restored cluster as a different user (e.g., postgres), you must now manually add the appropriate sudo -u postgres prefix to the restore_command in the recovery configuration and ensure file ownership is correct.

References: BAR-675.

• Deprecate pygzip and pybzip2 compression options

The pygzip and pybzip2 compression options are now deprecated and will be removed in a future release. Users should migrate to the gzip and bzip2 options, which now use Python's internal libraries.

This change was made to improve performance and code consistency. Previously, the gzip and bzip2 options relied on external subprocesses, while their py counterparts used native Python libraries. The core compression logic for gzip and bzip2 has been updated to also use Python's built-in libraries, making the pygzip and pybzip2 options redundant.

References: BAR-878.

• Add delta-restore flag and recovery option to barman restore

Introduces the --delta-restore flag for barman restore, enabling delta restore mode. This mode restores a backup by reusing identical data already present in the destination directory, which drastically reduces restore time and network traffic.

This feature is also configurable per-server via 'recovery_options' as a new field called delta-restore in the server configuration file.

References: BAR-788.

• S3 Object Deletion Fallback for Object Stores non-compliant with boto3 >=1.36

When using delete_objects() with some non-compliant S3-compatible object stores, users could encounter a MissingContentMD5 ClientError due to a breaking change in boto3 1.36 that Botocore will no longer automatically compute and populate the Content-MD5 header.

To address this, Barman now implements a fallback mechanism:

• Bulk deletion via delete_objects() is still attempted first.
• If delete_objects() fails with MissingContentMD5, Barman automatically falls back to deleting objects individually using delete_object(), which does not require a Content-MD5 header.
• Other errors continue to raise exceptions as before.

This change ensures Barman remains compatible with non-compliant object stores without requiring changes on the user's side.

Users with older S3-compatible storage can continue performing backup cleanups without failures, while newer object stores are unaffected.

References: BAR-909.

• Cloud connectivity checks are now only performed with the -t/--test flag.

Previously, Barman always tested cloud connectivity and bucket existence for most of the commands, raising errors if connectivity failed or if the bucket did not exist. Both checks are now executed only when the -t/--test flag is specified. The only exception was barman-cloud-check-wal-archive, which still checks connectivity and the existence of the bucket.

Additionally, buckets are no longer created automatically — Barman assumes the target bucket already exists, making it the user's responsibility to provision the bucket in advance.

References: BAR-895, BAR-908, BAR-918.

Minor changes

• Add combine-mode option to barman restore command

Added a --combine-mode option to the barman restore command, which can be used to specify a copy mode for pg_combinebackup when combining incremental backups during a restore. Available modes are copy, link, clone, and copy-file-range which are equivalent to the pg_combinebackup options --copy, --link, --clone, and --copy-file-range, respectively. An equivalent combine_mode configuration option can be specified in the configuration file.

This feature allows for greater optimization of the restore process based on the underlying filesystem capabilities.

References: BAR-870.

• Reorganize fields in barman diagnose JSON

In the barman diagnose JSON, some fields appeared under the server's "config" section even though they were not actual configuration fields.

The fields "barman_lock_directory", "lock_directory_cleanup", and "config_changes_queue" were relocated under the "global" key, since they represent global configurations. The "name" field was removed since the server name is already used as the key. Additionally, "msg_list" is now stored under the server's name key.

References: BAR-134.

• Add '-p JOBS' to barman-wal-restore command when --get-wal is True

Adds '-p JOBS' to barman-wal-restore command when --get-wal or get_wal configuration option is True, JOBS being the number of jobs chosen by the user via -p flag or parallel_jobs configuration option.

References: BAR-857.

• The `barman show-backup`` command now displays the backup compression method

The output of the barman show-backup command has been enhanced to include a new Backup Compression field. If a backup was taken with compression enabled, this field will now display the compression algorithm that was used (e.g., zstd). This makes it easier to quickly verify the compression status of a backup.

References: BAR-901.

Bugfixes

• Fix parallelism (--parallel option) in barman-wal-restore

There has been a regression in barman-wal-restore when introducing the --keep-compression option in Barman 3.12.0, which made the --parallel option not invoke processes as expected. This issue has now been fixed.

References: BAR-865.

• Fix pg_combinebackup not being found in PATH when staging_location is remote

When recovering an incremental backup to a remote server with staging_location set to remote, Barman checks if pg_combinebackup is available in the remote PATH. However, a previous issue was making it incorrectly check the local PATH as well, leading to errors if pg_combinebackup was not installed locally. The problem has been fixed by ensuring that the check is only performed on the server where pg_combinebackup is actually executed.

References: BAR-903.