Barman

Barman release notes

© Copyright EnterpriseDB UK Limited 2026 - All rights reserved.

3.20.0 (2026-08-27)

Notable changes

• Barman now requires Python 3.12 or later

  The minimum supported Python version has been raised to 3.12. Installations running on Python 3.8, 3.9, 3.10, or 3.11 must upgrade their Python interpreter before upgrading Barman.

  References: BAR-1332.

• Add support for AWS S3 SSE-C (Server-Side Encryption with Customer Keys)

  Barman now supports SSE-C (Server-Side Encryption with Customer-Provided Keys) for AWS S3. The --sse-customer-key option is available across all backup, restore, and WAL management barman-cloud-* commands. The key is supplied as a file:// URI pointing to a file containing a base64-encoded 256-bit (32-byte) key (e.g. file:///etc/barman/sse-c.b64). SSE-C cannot be used together with --encryption or --sse-kms-key-id. The equivalent server configuration parameter aws_sse_customer_key is also supported when using backup_method = local-to-cloud or postgres with cloud destination directories.

  All backups and WAL files for a given server must be encrypted with the same SSE-C key. Mixing SSE-C-encrypted and unencrypted objects, or using different keys, will cause commands to fail.

  References: BAR-1006.

• Stop WAL receiver on inactive servers through barman cron

  When a server is switched to active = false, the next run of barman cron now stops any background receive-wal subprocess that is still streaming for that server, and skips all other cron work. Previously inactive servers were silently filtered out at the cron level, which meant a receiver spawned while the server was active kept running indefinitely until it was stopped manually.

  Note however that, while the server remains inactive, the upstream Postgres server will retain WAL on its side for the still-existing slot, so on re-enabling the Barman server the next cron run will resume streaming from where the slot left off.

  References: BAR-1139.

• Make command handling consistent for inactive servers

  Inactive servers (configured with active = false) are Barman instances that no longer actively manage backups, but their existing catalogs remain fully accessible for inspection, verification, and maintenance.

  The behavior of Barman commands has been made consistent with this principle.

  Now the following commands work on inactive servers: read-only commands for inspection, like check-wal-archive, list-processes and sync-info.

  Also the following maintenance commands for catalog management work on inactive servers: terminate-process, keep and check-backup.

  Commands that ingest new data remain rejected on inactive servers. Specifically, import-backup now cannot be used with inactive servers.

  References: BAR-1343.

• Add support for parallel uploads to Google Cloud Storage

  Previously, backups to Google Cloud Storage required the entire tarball to be written locally before upload could begin. This was because the GCS implementation did not support multipart uploads, resulting in slower backups and higher disk space usage compared to AWS S3 and Azure Blob Storage.

  Multipart upload is now supported for GCS backups. Data is now streamed in chunks and uploaded in parallel using multiple workers (specified via -J / --jobs in barman-cloud-backup), matching the behavior of the other cloud providers.

  References: BAR-972.

• Performance improvements for restoring compressed backups from cloud storage

  Restoring a compressed backup from cloud storage could take significantly longer than necessary, because downloading, decompressing and extracting the backup ran sequentially instead of overlapping. This has been fixed by reworking the restore pipeline so these stages now run concurrently, which is expected to noticeably improve restore performance for compressed backups.

  As a result of this change, the tar package is now a required dependency whenever restoring a backup stored in the cloud.

  References: BAR-1546.

• Add parallel WAL prefetching support to barman-wal-archive

  The barman-wal-archive script now supports a --parallel option, which enables opportunistic prefetching of additional WAL files during archival. When --parallel N is set (N > 1), up to N - 1 extra WAL files that are ready in pg_wal/archive_status are archived concurrently in background worker processes after the primary WAL has been successfully archived. This can significantly reduce WAL archival backlog during periods of high WAL generation.

  Using --parallel requires a writable cache directory to store metadata about the WAL files being parallelized. By default, this cache directory is located at /tmp/barman-SERVER_NAME-COMPUTED_HASH, where SERVER_NAME is the name of the PostgreSQL server being archived, and COMPUTED_HASH is a hash of the destination (barman host, port, and config). The cache directory can be overridden with the --prefetch-cache-dir option.

  References: BAR-551.

Minor changes

• Script barman-cloud-wal-restore now exits with code 2 on network failures

  barman-cloud-wal-restore previously always exited with code 4 (general error) when a WAL download failed, regardless of the cause. It now exits with code 2 when the failure is caused by a loss of connectivity to the cloud provider, consistent with the behaviour of barman-cloud-check-wal-archive. This allows callers such as CloudNativePG to apply different retry policies for transient network errors versus permanent failures.

  References: BAR-1325.

• Deprecate --stop option of barman receive-wal

  The --stop option of barman receive-wal is deprecated and will be removed in a future release. Use barman terminate-process <server> receive-wal instead.

  References: BAR-724.

• Add check-archived-wal-range command to detect gaps in the WAL archive

  A new check-archived-wal-range command has been added to Barman. It accepts a server name, a begin_wal, and an end_wal, and verifies that every WAL segment in that range is present in the archive. Missing segments are listed on exit, and the command returns a non-zero status if any are found.

  References: BAR-1324.

• Support S3 access point ARNs, including S3 on Outposts, as cloud storage destinations

  Barman's S3 cloud storage support previously required a plain bucket name in the destination URL. This prevented using S3 access points as a backup or WAL archive destination, including Amazon S3 on Outposts access points, since access point ARNs contain characters that were not handled correctly, causing the ARN to be silently truncated and the destination never reached.

  Destination URLs can now specify an S3 access point ARN in place of a bucket name, using the same s3://<access-point-arn>/<key> convention already used by the AWS CLI's own S3 commands. This applies to all barman-cloud-* commands, as well as to basebackups_directory and wals_directory when configured with a cloud storage URL (for example with backup_method = local-to-cloud or backup_method = postgres with streaming backups to the cloud).

  If the destination is an access point ARN that does not exist (for example due to a typo), Barman now raises a clear error explaining that access points cannot be auto-created and that the underlying bucket must already exist, instead of failing with a confusing, low-level error from the AWS SDK.

  References: BAR-1561.

• Store EBS snapshots locally on the Outpost for AWS Outposts-hosted instances

  As part of AWS Outposts support, Barman now detects when a PostgreSQL instance targeted for a snapshot backup is running on an AWS Outpost, and creates its EBS snapshots locally on that Outpost rather than in the instance's parent AWS Region. This preserves the data residency and latency benefits of running on Outposts. No additional configuration is required.

  AWS does not support locking local EBS snapshots on Outposts, so aws_snapshot_lock_mode cannot be combined with a snapshot backup of an Outposts-attached instance. Barman now raises a clear error for this combination instead of attempting an unsupported lock.

  References: BAR-1562.

• Add keepalive support to barman-cloud-backup

  barman-cloud-backup now sends periodic heartbeat queries (SELECT 1) to the PostgreSQL server during the backup phase to prevent idle connection timeouts caused by intermediate network devices such as firewalls and load balancers. This ensures the backup session remains valid so that pg_backup_stop() can be successfully executed after the data transfer or snapshot creation is complete.

  This applies to both the standard data upload path and the snapshot backup path.

  The interval can be configured via the --keepalive-interval flag (default: 60 seconds). Setting the value to 0 disables the mechanism.

  References: BAR-1557, BAR-1571.

• Add Zstd compression support for cloud backups

  barman-cloud-backup now supports Zstd compression via the --zstd option. Zstd offers a good balance between compression ratio and speed, making it well-suited for cloud backup workloads.

  Zstd compression requires the optional zstandard Python library to be installed.

  References: BAR-729.

• Add --skip-archive-wal flag to barman restore command

  Added a new --skip-archive-wal CLI argument for barman restore which allows users to skip the archiving of staged WAL files before initiating the restore process. By default, barman restore archives any WAL files in the server's inco

…(truncated)

Barman release notes

© Copyright EnterpriseDB UK Limited 2025 - All rights reserved.

3.19.1 (2026-05-26)

Bugfixes

• Fix cloud-wal-restore failing to find compressed WAL files

  Fixed a bug where barman-cloud-wal-restore and barman cloud-wal-restore commands would fail to locate a compressed WAL file when a backup file with the same prefix existed in the cloud storage bucket.

  For example, when requesting WAL 00000001000000030000001A and the bucket contained both 00000001000000030000001A.gz and 00000001000000030000001A.00000028.backup.gz, Barman would only locate the backup file and then write an error log like:

  ERROR: WAL file 00000001000000030000001A for server pg does not exist

  The issue is now fixed and WAL files are correctly identified even when backup files with the same prefix are present in the bucket.

  References: BAR-1315.

Barman release notes

© Copyright EnterpriseDB UK Limited 2025 - All rights reserved.

3.19.0 (2026-05-20)

Notable changes

• Add support for restoring backups from cloud storage

  Barman can now restore backups taken with backup_method = local-to-cloud or backup_method = postgres when stored in cloud object storage.

  The standard barman restore command can be used to restore such backups.

  For WAL restore, a new barman cloud-wal-restore command was introduced to fetch WAL files directly from cloud storage during recovery. This command can be used as the restore_command in PostgreSQL and supports parallel fetching for improved performance.

  Also, when a server has wals_directory configured to use cloud storage, get-wal is now always required for restore operations. If --no-get-wal is specified or get-wal is absent from recovery_options, Barman will automatically enable get-wal and issue a warning so the restore can proceed without interruption.

  This completes the cloud backup lifecycle, enabling seamless backup and recovery workflows entirely in the cloud.

  References: BAR-929.

• Add new barman export-backup command for exporting backups to tarball

  Introduced a new barman export-backup command that exports a backup to a tarball format. The command takes a server name, backup ID, and destination directory as arguments, and creates a tarball containing the backup data. This provides an easy way to share or archive backups.

  References: BAR-1180.

• Add the barman import-backup command for importing backups from tarball

  Introduced a new barman import-backup command that imports a backup from a tarball format. The command takes a server name and tarball path as arguments, and provides a way to register previously exported backups back into a Barman catalog.

  References: BAR-1223.

Minor changes

• Support alternative GCP universes via GOOGLE_CLOUD_UNIVERSE_DOMAIN environment variable

  Barman now supports alternative GCP universes (e.g. S3NS/T-Systems) by reading the GOOGLE_CLOUD_UNIVERSE_DOMAIN environment variable. When set, the value is passed as client_options to the GCS storage client, allowing barman-cloud-* commands to operate against non-standard GCP endpoints. This feature was contributed by community member @mgarstecki.

  References: BAR-1017.

• Add support for parallel WAL restore in barman-cloud-wal-restore

  Support for parallelism has been added to the barman-cloud-wal-restore command, allowing users to specify a number of WALs to be downloaded in parallel during the recovery of WALs. This enhancement improves the overall performance of WAL restoration by prefetching multiple WAL files concurrently. Check the documentation of barman-cloud-wal-restore for more details.

  References: BAR-1253.

• Add aws_check_object_lock config option to check S3 object lock before deletion

  Introduced a new aws_check_object_lock configuration option. When enabled, Barman checks for S3 Object Lock before attempting to delete base backup files from S3 storage. If an object is locked, the deletion is aborted. This aligns Barman's behavior with barman-cloud-delete for locked objects. Only applies to S3 storage; a warning is logged if this option is enabled with a non-S3 cloud provider.

  References: BAR-1113.

• Make in-progress cloud backups visible in the backup catalog

  In-progress cloud backups are now immediately visible in barman-cloud-backup-list with STARTED in the archival status column and an empty end time. Previously, a backup only became visible once it completed successfully. barman-cloud-backup-delete, barman-cloud-restore, and the last/latest/first/oldest shortcuts all treat in-progress backups safely by excluding them from redundancy counts, auto-restore selection, and shortcut resolution respectively.

  References: BAR-1235.

• Removed setuptools as a runtime dependency

  Setuptools is no longer required as a runtime dependency for Barman. Setuptools was previously included to provide the deprecated distutils module for Python 3.12+ compatibility, but it has been replaced with another implementation. Setuptools remains available during build time for packaging purposes.

  References: BAR-1170.

• Add --partial-wal flag to barman restore for opt-in .partial WAL file copying

  A new --partial-wal flag has been added to barman restore --no-get-wal. When set, Barman includes .partial WAL files in the recovery, stripping the .partial suffix so that PostgreSQL can find them during replay. Two sources are supported:

  • The streaming WALs directory: the in-progress segment being written by pg_receivewal at the time of the restore. Including it reduces RPO by making any transactions written since the last completed WAL segment available during recovery.
  • The WAL archive (wals/): segments archived with the .partial suffix, e.g. when a standby is promoted and PostgreSQL calls archive_command with an in-progress segment. Compressed and encrypted files are handled transparently.

  The flag has no effect when --get-wal is used, as .partial files are already handled transparently in that case.

  References: BAR-695.

• Add parallel WAL archiving support to barman cloud-wal-archive

  barman cloud-wal-archive now supports a --parallel flag (and the corresponding cloud_wal_archive_parallel configuration option) that enables opportunistic prefetching of additional WAL files during archival. When --parallel N is set (N > 1), up to N - 1 extra WAL files that are ready in pg_wal/archive_status are identified and uploaded concurrently in background worker processes after the primary WAL has been successfully archived. This can significantly reduce WAL archival backlog during periods of high WAL generation. If a WAL file was already uploaded by a previous invocation, subsequent calls to archive_command for that WAL will detect it and exit immediately with 0, avoiding redundant uploads.

  References: BAR-1101.

Bugfixes

• Fix backup metadata not being updated in the cloud storage

  NOTE: This fix is for the cloud integration of Barman servers i.e. those configured with backup_method = local-to-cloud or backup_method = postgres which uses a cloud storage as backup destination. This is not an issue in the barman-cloud-* scripts (e.g. barman-cloud-backup).

  Backup metadata (backup.info files) was not being updated in the cloud storage, which led, for example, to the status of the backup in the cloud being outdated compared to the local one. This can be a problem during the restore phase, where the metadata from the cloud might be the primary source of information. This issue is now fixed.

  References: BAR-1227.

• Fix barman restore --no-get-wal copying unusable .partial WAL files

  When running barman restore --no-get-wal, .partial WAL files present in the WAL archive were copied to the recovery destination. However, the restore_command generated by Barman uses cp from the barman_wal directory, which does not account for .partial suffixes — so these files were never used by PostgreSQL during recovery. Barman now skips .partial files by default. To explicitly include them (with the suffix stripped so PostgreSQL can find them), use the new --partial-wal flag.

  References: BAR-1265.

• Fix --no-get-wal restore not copying WALs from newer timelines on PostgreSQL 12+

  Since PostgreSQL 12, the default for recovery_target_timeline changed from current to latest. When restoring with PITR options (e.g., --target-time) in --no-get-wal mode, Barman was only copying WAL files from the backup's original timeline. This could cause restores to fail when the recovery target is on a newer timeline.

  Barman now correctly copies WAL files from all timelines up to the latest available when performing PITR on PostgreSQL 12+, matching the default Postgres recovery behavior.

  References: BAR-1054.

• Fix multiple warnings about intermediary files not being removed

  When using WAL compression, Barman creates intermediary files in the archive directory during the compression process. Intermediary file paths are stored in a list and removed at the end of the file archival.

  However, when archiving multiple files in batch, the list of intermediary files was not being cleared after each processed file, causing later archivals to attempt to remove files that no longer exist, resulting in warnings like the below:

  WARNING: Could not remove intermediary file /home/gustavo/pg/streaming/0000000100000013000000FD: [Errno 2] No such file or directory: '/home/gustavo/pg/streaming/0000000100000013000000FD'

  This bug was introduced in version 3.18, commit 5db8ca9b. It is now fixed and such warnings should no longer occur.

  References: BAR-1228, CP-59700.

Barman release notes

© Copyright EnterpriseDB UK Limited 2025 - All rights reserved.

3.18.0 (2026-03-12)

Notable changes

• Add support for incremental backups in cloud storages

  Added support for block-level incremental backups in cloud storages, allowing users to efficiently manage backup storage and reduce costs by only uploading changed data.

  This new feature relies on streaming native Postgres backups (taken with pg_basebackup) to Barman and from Barman directly to a cloud storage dynamically, without ever storing the full backup in the Barman host, only using a small staging area. The staging area location and size can be configured via the new cloud_staging_directory and cloud_staging_max_size configuration options, respectively.

  To configure this feature, set backup_method = postgres and basebackups_directory and wals_directory to a cloud storage URL (e.g., s3://my-bucket/barman).

  Example configuration:

  [myserver]
  backup_method = postgres
  basebackups_directory = s3://my-bucket/barman
  wals_directory = s3://my-bucket/barman
  cloud_staging_directory = /tmp/barman/cloud-staging
  cloud_staging_max_size = 30Gi

  The backup structure in the cloud storage follows the same patterns as the current barman-cloud-* scripts i.e. backup files are archived with tar and live under directories named after the server name and the backup ID, e.g. my-bucket/barman/<server_name>/base/<backup_id>/..., while WAL files are stored in a wals subdirectory under the server directory, i.e. my-bucket/barman/<server_name>/wals/.... In this sense, basebackups_directory and wals_directory act as a prefix for the backup and WAL paths in the cloud storage. This ensures compatibility with existing backup management practices.

  Important notes:

  • This is an experimental feature, and there are some limitations to be aware of (see the documentation for details).
  • Restoring backups taken with this method is currently not supported directly in Barman, and it's the user's responsibility to perform this manually or through custom scripts/processes. Restoring such backups will come in a future release.
  • This is the first step toward unifying the barman cloud experience and simplifying cloud backup operations, and more features and improvements will be added in future releases.

  References: BAR-928.

• Add local-to-cloud backup method to barman CLI

  Introduced support for direct cloud backups through the main barman CLI by adding a new local-to-cloud backup method. Previously, cloud backups were only available through standalone barman-cloud-* scripts.

  With this enhancement, you can now configure cloud backups directly in the barman configuration file using backup_method = local-to-cloud along with a cloud storage URL in basebackups_directory (e.g., s3://bucket/path). This provides a unified interface for all backup methods and is the first step toward deprecating the standalone barman-cloud-* scripts.

  The new CloudBackupExecutor integrates seamlessly with the existing barman backup infrastructure, coordinating with PostgreSQL using the low-level backup API and uploading backups directly to cloud object storage.

  Example configuration:

  [myserver]
  backup_method = local-to-cloud
  basebackups_directory = s3://my-bucket/barman/backups
  conninfo = host=postgres-host dbname=postgres

  This is the first step toward unifying the barman cloud experience and simplifying cloud backup operations.

  The following configuration options were reused or added to the Barman configuration to provide feature parity with the barman-cloud scripts:

  • cloud_upload_min_chunk_size
  • aws_region
  • aws_read_timeout
  • aws_encryption
  • aws_sse_kms_key_id
  • bandwidth_limit
  • cloud_delete_batch_size
  • cloud_upload_max_archive_size

  References: BAR-1095, BAR-1116, BAR-1122, BAR-1109, BAR-1120, BAR-1121, BAR-1117, BAR-1112, BAR-1115.

• Add 'barman cloud-wal-archive' command for local-to-cloud WAL archiving

  Introduced a new barman cloud-wal-archive command that enables direct WAL file archiving from the PostgreSQL pg_wal directory to cloud object storage when using the 'local-to-cloud' backup method. This command is designed to be used as the PostgreSQL archive_command when the Barman server runs on the same host as the PostgreSQL instance.

  WAL files sent to cloud object storage can also be compressed before uploading, using the existing compression and compression_level configuration options. Compressed WAL files are stored with the appropriate file extension (e.g. .gz, .lz4), consistent with the convention already used by barman-cloud-wal-archive.

  The following in-memory compression algorithms are supported: gzip, bzip2, xz, snappy, zstd, and lz4. pigz and custom are not supported for cloud WAL storage because they rely on external processes.

  Example configuration:

  [myserver]
  backup_method = local-to-cloud
  archiver = on
  wals_directory = s3://my-bucket/barman/wals
  compression = gzip
  compression_level = 6

  References: BAR-1098, BAR-1124.

Minor changes

• Add --addressing-style option for S3-compatible storage providers

  A new --addressing-style option is now available for barman-cloud commands when using AWS S3 or S3-compatible storage providers. This option allows users to explicitly set the S3 addressing style to auto, virtual, or path. This is useful when working with S3-compatible storage systems that require virtual-hosted-style addressing, as boto3 automatically defaults to path-style addressing for non-S3 endpoints.

  Special thanks to @ChandonPierre who reported and contributed to this feature in the PR #1134.

  References: BAR-1011.

• Add Python 3.14 compatibility support for cloud operations

  Added support for Python 3.14 by fixing a breaking change in functools.partial that affected cloud backup operations. In this version, functools.partial became a method descriptor which changed its behavior when used as a class attribute. This update ensures Barman cloud operations continues to work seamlessly when upgrading to Python 3.14.

  This patch is based on the original idea by @pvbiesen, who suggested the feature and contributed in the PR #1143. A similar fix was also suggested by @mjlshen in PR #1109.

  References: BAR-1012.

• Prevent usage of barman-cloud-backup as hook for backups with compression

  The usage of barman-cloud-backup as a hook for backups taken with compression is now prevented by erroring out with an appropriate message.

  This change ensures that backups with compression are not inadvertently used with cloud backup hooks, given that such usage was never supported.

  The behavior is also documented with a warning note.

  References: BAR-1015.

• Add LZ4 compression support for Barman cloud

  Added support for LZ4 compression in barman-cloud-backup command. You can now specify the --lz4 option to compress backup files using LZ4 compression before uploading to cloud storage. This option is mutually exclusive with other compression options (--gzip, --bzip2, --snappy), and it requires the lz4 Python library to be installed.

  This feature was suggested and implemented by @vietcgi in the PR #1144.

  References: BAR-1013.

• Experimental support for WarehousePG database ID configuration

  Addition of experimental support for WarehousePG, which includes a new configuration option warehousepg_dbid that allows users to specify the database ID of the WarehousePG segment when using the PostgreSQL backup method. This configuration is intended to enable better integration with WarehousePG for backup and restore operations.

  There's also an improvement in the collection of Postgres parameters due to archive_timeout not being exposed in pg_settings on WarehousePG segments.

  References: BAR-1092.

• Add custom restore command support for barman recover operations

  Added a new --restore-command option to the barman recover command that allows users to override Barman's default restore command with a custom command. While the default restore command built by Barman is suitable for most cases, this option allows you to specify an alternative command if your setup requires it.

  Previously, users had to manually edit PostgreSQL recovery configuration files after recovery to change the restore command, which was error-prone and required additional manual intervention. With this new option, users can now specify a custom restore command directly through the command line.

  This enhancement was applied due to an issue reported in #881 by @PaganMuffin.

  References: BAR-201.

Bugfixes

• Fix file handle leak for long-running WAL archiving services

  Fixed a resource leak in the cloud WAL archiving functionality where file handles were not being properly closed after uploading WAL files to cloud storage. This issue could primarily affect long-running WAL archiving services that process multiple WAL files in sequence, where the accumulating open file handles could eventually cause "Too many open files" errors, preventing further WAL archiving operations.

  The fix ensures that file handles are properly closed immediately after each upload operation completes, regardless of whether compression is used and even when upload failures occur. This prevents handle exhaustion in services that perform continuous or high-frequency WAL archiving to cloud providers.

  Special thanks to @ethiebaut

…(truncated)

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-port to barman restore command

  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.

Barman release notes

© Copyright EnterpriseDB UK Limited 2025 - All rights reserved.

3.16.2 (2025-11-04)

Bugfixes

• Improve barman-cloud delete workaround to inspect error message content

  Some S3-compatible storages return an "InvalidRequest" error instead of "MissingContentMD5" during delete operations. Since we cannot rely on the error code alone, this updates the logic to also inspect the error message text to detect MissingContentMD5-like issues and apply the appropriate fallback.

  References: BAR-947.

Barman release notes

© Copyright EnterpriseDB UK Limited 2025 - All rights reserved.

3.16.1 (2025-10-14)

Notable changes

• Automatic bucket creation added to barman-cloud-check-wal-archive

  The barman-cloud-check-wal-archive command now verifies whether the target bucket exists in the configured cloud storage (e.g., AWS S3) and automatically creates it if it does not.

  Previously, automatic bucket creation was handled by barman-cloud-backup. This change restores compatibility with CloudNativePG (CNPG) automations that depend on this behavior, which were affected after the release of Barman 3.16.0.

  In collaboration with the CloudNativePG team, we have reintroduced this functionality specifically in barman-cloud-check-wal-archive to ensure seamless operation of CNPG workflows and internal tests — all while preserving the intended behavior and simplicity for regular Barman users.

  References: BAR-931.

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.

3.15.0 (2025-08-05)

Notable changes

• Allow incremental backups to be taken with compression and encryption

  Previously, Barman prevented incremental backups to be taken if compression was enabled or if the parent backup was already compressed. Since encryption in Barman requires compression, this also meant that incremental backups could not be taken with encryption.

  This limitation existed due to the complexity of restoring such backups, which involves multiple staging phases for decryption, decompression, and combination of backups.

  After a significant refactoring effort, Barman now fully supports taking incremental backups with both compression and/or encryption. This allows for more flexible backup strategies, enabling users to take advantage of all available features without restrictions.

  References: BAR-764, BAR-801, BAR-841.

• Deprecate local_staging_path and recovery_staging_path configuration options

  The local_staging_path and recovery_staging_path configuration options have been deprecated in favor of the new staging_path and staging_location options. The old options will continue to work for backwards compatibility, but users are encouraged to migrate to the new configuration options for better clarity and flexibility.

  References: BAR-571, BAR-801.

• Improve flexibility and consistency of staging area configuration

  Whenever restoring a compressed, encrypted or incremental backup, Barman needs a staging area to handle intermediate files, such as decompressed or decrypted files, or the combined incremental backup data.

  Previously, Barman used to have different configuration options for each scenario:

  • For incremental backups, the staging area was specified via the local_staging_path in the Barman configuration, which could only be a path in the Barman host.

  • For compressed backups, the staging area was specified via the recovery_staging_path, which could be a path in the Barman host (in case of local recovery) or a path in the target server (in case of remote recovery to a different server).

  • For encrypted backups, the staging area was specified via the local_staging_path in the Barman configuration, which could only be a path in the Barman host. Note that, since encryption requires compression to be enabled, when restoring an encrypted backup, users needed to specify both recovery_staging_path and local_staging_path.

  Barman now provides a single, unified and more flexible staging area configuration:

  • The new staging_path configuration option can be used to specify an absolute path for the staging area, where intermediate files will be stored. The default value is /tmp.

  • The new staging_location configuration option can be used to specify whether the staging area is on the Barman host (local) or on the remote server (remote). The default value is local.

  This means that, besides having a unified configuration for the staging path, users are now also able to specify with more flexibility where the staging area should be located, either on the Barman host or on the remote Postgres server.

  Storage usage has also been optimized to reduce resource consumption whenever possible. This includes:

  • Removing intermediate files as soon as they are no longer needed.
  • Avoid using the staging area when not necessary, e.g. when restoring a compressed backup locally, no staging is needed and the backup is decompressed directly to its final destination.

  This change simplifies configuration and improves consistency and resource usage, making the recovery management more transparent and predictable for end users.

  References: BAR-764, BAR-765, BAR-801, BAR-841.

Minor changes

• Add --staging-path and --staging-location to barman restore

  Added --staging-path and --staging-location options to barman restore command to allow the user to specify a custom path for the staging area during the restore process. --staging-path is the absolute path to be used while --staging-location defines its location i.e. local or remote. They also have its equivalent configuration options in barman.conf as staging_path and staging_location respectively.

  References: BAR-570.

• Add option --if-not-exists to barman receive-wal --create-slot

  A new --if-not-exists flag has been added to the barman receive-wal --create-slot command. This prevents the command from failing when attempting to create a replication slot that has already been created, making it more reliable for use in scripts.

  Special thanks to @crazybolillo <antonio@zoftko.com> a.k.a @antonag32 for creating a PR and contributing to Barman.

  References: BAR-527.

• Fail gracefully when an unexpected field is found in the backup metadata.

  This update improves how Barman handles backup metadata that includes fields unknown to the current version. This situation can occur when attempting to restore a backup created with a newer version of Barman using an older one. For example, if a newer version adds metadata about encryption, and the older version doesn't recognize that field. That's a case where this change is relevant.

  Previously, this would cause an unhelpful exception. Now, Barman will display a clearer message explaining that the backup was created with a newer version and may not be compatible with the current version.

  References: BAR-763.

• Improve orphan backup warning for proper cleanup

  The warning message for orphan backups has been improved to help users fully clean up incomplete or manually removed backups. Previously, the message did not mention the location of the backup.info file, which led to confusion. The updated message now clearly indicates the location of the backup.info file to help users properly remove it.

  References: BAR-793.

• Improve tag handling in cloud commands to fix parsing errors

  The --tags command-line option in barman-cloud-backup and barman-cloud-wal-archive has been replaced to improve parsing reliability and align with standard CLI practices. The previous space-separated format could cause parsing errors, especially when placed before positional arguments.

  The commands now accept multiple --tag flags, one for each key-value pair.

  Before: barman-cloud-backup ... --tags key1,val1 key2,val2

  After: barman-cloud-backup ... --tag key1,val1 --tag key2,val2

  The --tags option is now deprecated. While existing scripts using the old --tags format will continue to work, users are encouraged to update their scripts to the new format. This change is backward compatible and does not introduce a breaking change.

  References: BAR-441.

• Clarify WAL Number label in barman show-backup output

  Rename misleading WAL Number label in barman show-backup output to Number of WALs.

  References: BAR-791.

• Change "No of files" to "Number of files" in show-backup command

  In the Wal Information section of the show-backup command, the output of "No of files" was changed to "Number of files".

  References: BAR-798.

• Validate options passed for servers and models through config-update

  The barman config-update command now performs extra validation on each provided section before enqueuing changes. It verifies, among other things, that all required fields are present, that the provided values conform to the expected types, and that each value also passes its respective parser. In addition, the command will now error out if any of the checks fail. This prevents partial or malformed updates from being applied.

  References: BAR-142.

• Add --check-timeout argument to barman check and barman backup commands

  A new CLI option has been introduced for the barman check and barman backup commands to address situations where the check operation duration exceeds the configured check_timeout, preventing backups from being scheduled. This option allows users to disable the timeout or override the default or configured check_timeout value.

  References: BAR-219.

• Add --list-empty-directories to barman list-files command

  Adds a new --list-empty-directories argument to the list-files command to add empty directories to the listing.

  References: BAR-220.

• Improve archiving check with automatic WAL switching and archiving

  To improve the user experience, especially during initial server configuration, the barman check command is now more robust.

  Previously, when the WAL archive was empty, the check would fail and require manual intervention.

  Barman now intelligently handles this by first attempting to archive any existing WAL present in the Barman server. If none exists, it automatically triggers a WAL switch in the Postgres server and tries to archive the resulting file. This enhancement automates a common manual step and makes the initial health check more reliable out-of-the-box.

  References: BAR-718.

• Support shortcuts as backup IDs in Barman cloud scripts

  It is now possible to specify the shortcuts first/oldest, last/latest and last-failed when referencing backups in the Barman cloud commands. Barman now automatically parses these shortcuts and returns their associated backup ID.

  References: BAR-717.

Bugfixes

• Ignore data files of temporary tables during backups

  Files that match the pattern of temporary relation files will now be ignored during a rsync backup, similar to the exclusion implicitly performed by pg_basebackup. This is needed to avoid errors when runn

…(truncated)

3.14.1 (2025-06-18)

Bugfixes

• Fix WAL archiving performance issues

  The Barman WAL archiving process was suffering from a performance degradation due to processing of WAL files that would not be archived in the current run. There was also an oversight in the encryption logic introduced in 3.14, that caused Barman to check for encryption in WAL files streamed to the server, which is unnecessary as streamed WALs are never GPG-encrypted, nor compressed. With both issues fixed, the archiving process will be significantly faster and more resource-efficient.

  Thanks to @thealex55 for the detailed analysis in the issue #1087.

  References: BAR-775.

3.14.0 (2025-05-15)

Notable changes

• Implementation of GPG encryption for tar backups and WAL files

  Implement GPG encryption of tar backups. Encryption starts at the end of the backup, encrypting the backup of PGDATA and tablespaces present in the backup directory. Encrypted backup files will have the .gpg extension added.

  Barman supports the decryption and restoration of GPG-encrypted backups using a passphrase obtained through the new encryption_passphrase_command configuration option. During the restore process, decrypted files are staged in the local_staging_path setting on the Barman host, ensuring a reliable and safe restore process.

  New configuration options required for encryption and decryption of backups and WAL files needed to be added. The new options are encryption, encryption_key_id, and encryption_passphrase_command.

  WAL files are all encrypted with GPG when encryption = gpg. This includes changing the way that xlogdb records are read and written (maintaining backwards compatibility), and a new logic to detect when files are encrypted and the encryption process itself.

  Decryption of GPG-encrypted WAL files during the restore process when using the get-wal and no-get-wal flags of the barman restore command. This extends the functionality added for decrypting backups via the encryption_passphrase_command configuration option.

  There's a new field in show-backup to expose if a backup was encrypted, and specifies the encryption method that was used, if any.

  The barman check command verifies if the user's encryption settings are correctly configured in the Barman server and functioning as expected.

  References: BAR-683, BAR-687, BAR-693, BAR-669, BAR-671, BAR-692, BAR-685, BAR-680, BAR-670, BAR-681, BAR-702.

• Deprecation of Python versions 3.6 and 3.7

  As of version 3.14 of Barman, we are deprecating support for Python 3.6 and 3.7, which are not supported by the Python community anymore. Barman still supports Python 3.8 as it's the newest version available on RHEL 8 systems which contains all needed modules.

  References: BAR-737.

Minor changes

• Allow compression level to be specified for WAL compression in Barman server

  Add a new compression_level parameter to the Barman configuration. This option accepts a valid integer value or one of the predefined options: low, medium, and high. Each option corresponds to a different level depending on the compression algorithm chosen.

  References: BAR-540.

• Add client-side compression to barman-wal-archive

  Client-side compression options have been added to barman-wal-archive, supporting the same algorithms that are available on a Barman server. When enabled, compression is applied on the client side before sending the WAL to the Barman server. The --compression-level parameter allows specifying a desired compression level for the chosen algorithm.

  References: BAR-262.

• Add --compression-level parameter to barman-cloud-wal-archive

  A parameter called compression-level was added to barman-cloud-wal-archive, which allows a level to be specified for the compression algorithm in use.

  References: BAR-557.

• Add Snappy compression algorithm to Barman server

  The Snappy compression, previously only available in barman-cloud-wal-archive, is now also available for standard Barman server. As with all other algorithms, it can be configured by setting snappy in the compression configuration parameter.

  References: BAR-557.

• Introduce the new list-processes sub-command for listing the server processes

  Add a new list-processes command that outputs all active subprocesses for a Barman server. The command displays each process's PID and task.

  References: BAR-664.

• Introduce the new terminate-process sub-command for terminating Barman subprocesses

  Add a new terminate-process command that allows users to terminate an active Barman subprocess for a given server by specifying its task name. Barman will terminate the subprocess as long as it belongs to the specified server and it is currently active.

  References: BAR-665.

• Remove the pin from boto3 version used in cloud scripts

  After thorough investigation of issues with boto3 >= 1.36, we've decided to remove the pin that kept the dependency at version 1.35.

  Both AWS and MinIO object stores work correctly with the latest version, and using a version of boto3 that is >= 1.36 ensures the Barman cloud scripts work in a FIPS-compliant environment.

  References: BAR-637.

Bugfixes

• Ensure minimum redundancy check considers only 'non-incremental backups'

  An issue was reported where the minimum_redundancy rule could be violated due to the inclusion of incremental backups in the redundancy count. As an example: in a scenario where the catalog contained one full backup and two dependent incremental backups, and the user had minimum_redundancy = 2, the rule was incorrectly considered satisfied. As a result, deleting the full backup triggered cascading deletion of its incremental dependents, leaving zero backups in the catalog.

  This issue has been fixed by updating the minimum_redundancy logic to consider only non-incremental backups (i.e. only full, rsync, snapshot). This ensures that full backups cannot be deleted if doing so would violate the configured minimum redundancy level.

  References: BAR-707.

• Fix usage of barman-wal-restore with --keep-compression using gzip, bzip2, and pigz compression algorithms

  Fix an issue in barman-wal-restore where, when trying to restore WALs compressed with gzip, bzip2 or pigz while having --keep-compression specified, leading to unexpected errors.

  References: BAR-722.