EnterpriseDB/barman release/3.16.0

Release 3.16.0

on GitHub

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.