release/3.11.1

Version 3.11.1 - 22 August 2024

Bug fixes

• Fix failures in barman-cloud-backup-delete. This command was failing when
  applying retention policies due to a bug introduced by the previous release.

release/3.11.0

Version 3.11.0 - 22 August 2024

Features

• Add support for Postgres 17+ incremental backups. This major feature is
  composed of several small changes:

  • Add --incremental command-line option to barman backup command. This is
    used to specify the parent backup when taking an incremental backup. The
    parent can be either a full backup or another incremental backup.

  • Add latest-full shortcut backup ID. Along with latest, this can be used
    as a shortcut to select the parent backup for an incremental backup. While
    latest takes the latest backup independently if it is full or incremental,
    latest-full takes the latest full backup.

  • barman keep command can only be applied to full backups when
    backup_method = postgres. If a full backup has incremental backups that
    depend on it, all of the incrementals are also kept by Barman.

  • When deleting a backup all the incremental backups depending on it, if any,
    are also removed.

  • Retention policies do not take incremental backups into consideration. As
    incremental backups cannot be recovered without having the complete chain of
    backups available up to the full backup, only full backups account for
    retention policies.

  • barman recover needs to combine the full backup with the chain of incremental
    backups when recovering. The new CLI option --local-staging-path, and the
    corresponding local_staging_path configuration option, are used to specify
    the path in the Barman host where the backups will be combined when recovering
    an incremental backup.

• Changes to barman show-backup output:

  • Add the “Estimated cluster size” field. It's useful to have an estimation
    of the data directory size of a cluster when restoring a backup. It’s
    particularly useful when recovering compressed backups or incremental
    backups, situations where the size of the backup doesn’t reflect the size of the
    data directory in Postgres. In JSON format, this is stored as
    cluster_size.

  • Add the “WAL summarizer” field. This field shows if summarize_wal was
    enabled in Postgres at the time the backup was taken. In JSON format, this
    is stored as server_information.summarize_wal. This field is omitted for
    Postgres 16 and older.

  • Add “Data checksums” field. This shows if data_checkums was enabled in
    Postgres at the time the backup was taken. In JSON format, this is stored as
    server_information.data_checksums.

  • Add the “Backup method” field. This shows the backup method used for this
    backup. In JSON format, this is stored as
    base_backup_information.backup_method.

  • Rename the field “Disk Usage” as “Backup Size”. The latter provides a more
    comprehensive name which represents the size of the backup in the Barman
    host. The JSON field under base_backup_information was also renamed from
    disk_usage to backup_size.

  • Add the “WAL size” field. This shows the size of the WALs required by the
    backup. In JSON format, this is stored as
    base_backup_information.wal_size.

  • Refactor the field “Incremental size”. It is now named “Resources saving”
    and it now shows an estimation of resources saved when taking incremental
    backups with rsync or pg_basebackup. It compares the backup size with
    the estimated cluster size to estimate the amount of disk and network
    resources that were saved by taking an incremental backup. In JSON format,
    the field was renamed from incremental_size to resource_savings under base_backup_information.

  • Add the system_id field to the JSON document. This field contains the
    system identifier of Postgres. It was present in console format, but was
    missing in JSON format.

  • Add fields related with Postgres incremental backups:

    • “Backup type”: indicates if the Postgres backup is full or incremental. In
      JSON format, this is stored as backup_type under base_backup_information.

    • “Root backup”: the ID of the full backup that is the root of a chain of
      one or more incremental backups. In JSON format, this is stored as
      catalog_information.root_backup_id.

    • “Parent backup”: the ID of the full or incremental backup from which this
      incremental backup was taken. In JSON format, this is stored as
      catalog_information.parent_backup_id.

    • “Children Backup(s)”: the IDs of the incremental backups that were taken
      with this backup as the parent. In JSON format, this is stored as
      catalog_information.children_backup_ids.

    • “Backup chain size”: the number of backups in the chain from this
      incremental backup up to the root backup. In JSON format, this is
      stored as catalog_information.chain_size.

• Changes to barman list-backup output:

  • It now includes the backup type in the JSON output, which can be either
    rsync for backups taken with rsync, full or incremental for backups
    taken with pg_basebackup, or snapshot for cloud snapshots. When printing
    to the console the backup type is represented by the corresponding labels
    R, F, I or S.

  • Remove tablespaces information from the output. That was bloating the
    output. Tablespaces information can still be found in the output of
    barman show-backup.

• Always set a timestamp with a time zone when configuring
  recovery_target_time through barman recover. Previously, if no time zone
  was explicitly set through --target-time, Barman would configure
  recovery_target_time without a time zone in Postgres. Without a time zone,
  Postgres would assume whatever is configured through timezone GUC in
  Postgres. From now on Barman will issue a warning and configure
  recovery_target_time with the time zone of the Barman host if no time zone
  is set by the user through --target-time option.

• When recovering a backup with the “no get wal” approach and --target-lsn is set,
  copy only the WAL files required to reach the configured target. Previously
  Barman would copy all the WAL files from its archive to Postgres.

• When recovering a backup with the “no get wal” approach and --target-immediate
  is set, copy only the WAL files required to reach the consistent point.
  Previously Barman would copy all the WAL files from its archive to Postgres.

• barman-wal-restore now moves WALs from the spool directory to pg_wal
  instead of copying them. This can improve performance if the spool directory
  and the pg_wal directory are in the same partition.

• barman check-backup now shows the reason why a backup was marked as FAILED
  in the output and logs. Previously for a user to know why the backup was
  marked as FAILED, they would need to run barman show-backup command.

• Add configuration option aws_await_snapshots_timeout and the corresponding
  --aws-await-snapshots-timeout command-line option on barman-cloud-backup.
  This specifies the timeout in seconds to wait for snapshot backups to reach
  the completed state.

• Add a keep-alive mechanism to rsync-based backups. Previously the Postgres
  session created by Barman to run pg_backup_start() and pg_backup_stop() would
  stay idle for as long as the base backup copy would take. That could lead to a
  firewall or router dropping the connection because it was idle for a long
  time. The keep-alive mechanism sends heartbeat queries to Postgres
  through that connection, thus reducing the likelihood of a connection
  getting dropped. The interval between heartbeats can be controlled through the new
  configuration option keepalive_interval and the corresponding CLI
  option --keepalive-interval of the barman backup command.

Bug fixes

• When recovering a backup with the “no get wal” approach and --target-time
  set, copy all WAL files. Previously Barman would attempt to “guess” the WAL
  files required by Postgres to reach the configured target time. However,
  the mechanism was not robust enough as it was based on the stats of the WAL
  file in the Barman host (more specifically the creation time). For example:
  if there were archiving or streaming lag between Postgres and Barman, that
  could be enough for recovery to fail because Barman would miss to copy all
  the required WAL files due to the weak check based on file stats.

• Pin python-snappy to 0.6.1 when running Barman through Python 3.6 or
  older. Newer versions of python-snappy require cramjam version 2.7.0 or
  newer, and these are only available for Python 3.7 or newer.

• barman receive-wal now exits with code 1 instead of 0 in the following
  cases:

  • Being unable to run with --reset flag because pg_receivewal is
    running.

  • Being unable to start pg_receivewal process because it is already
    running.

• Fix and improve information about Python in barman diagnose output:

  • The command now makes sure to use the same Python interpreter under which
    Barman is installed when outputting the Python version through
    python_ver JSON key. Previously, if an environment had multiple Python
    installations and/or virtual environments, the output could eventually be
    misleading, as it could be fetched from a different Python interpreter.

  • Added a python_executable key to the JSON output. That contains the path
    to the exact Python interpreter being used by Barman.

Barman 3.10.1

Version 3.10.1 - 12 June 2024

Bug fixes

• Make argcomplete optional to avoid installation issues on some
  platforms.
• Load barman.auto.conf only when the file exists.
• Emit a warning when the cfg_changes.queue file is malformed.
• Correct in documentation the postgresql version where
  pg_checkpoint is available.
• Add --no-partial option to barman-cloud-wal-restore.

release/3.10.0

Version 3.10.0 - 24 January 2024

Features

• Limit the average bandwidth used by barman-cloud-backup when backing
  up to either AWS S3 or Azure Blob Storage according to the value set by
  a new CLI option --max-bandwidth.
• Add the new configuration option lock_directory_cleanup
  That enables cron to automatically clean up the barman_lock_directory
  from unused lock files.
• Add support for a new type of configuration called model.
  The model acts as a set of overrides for configuration options
  for a given Barman server.
• Add a new barman command barman config-update that allows the creation
  and the update of configurations using JSON

Bug fixes:

• Fix a bug that caused --min-chunk-size to be ignored when using
  barman-cloud-backup as hook script in Barman.

Barman 3.9.0

Version 3.9.0 - 3 October 2023

Features

• Allow barman switch-wal --force to be run against PG>=14 if the
  user has the pg_checkpoint role (thanks to toydarian for this patch).

• Log the current check at info level when a check timeout occurs.

• The minimum size of an upload chunk when using barman-cloud-backup
  with either S3 or Azure Blob Storage can now be specified using the
  --min-chunk-size option.

• backup_compression = none is supported when using pg_basebackup.

• For PostgreSQL 15 and later: the allowed backup_compression_level
  values for zstd and lz4 have been updated to match those allowed by
  pg_basebackup.

• For PostgreSQL versions earlier than 15: backup_compression_level = 0
  can now be used with backup_compression = gzip.

Bug fixes:

• Fix barman recover on platforms where Multiprocessing uses spawn by
  default when starting new processes.

Barman 3.8.0

Version 3.8.0 - 31 August 2023

Features

• Clarify package installation. barman is packaged with default python version
  for each operating system.

• The minimum-redundancy option is added to barman-cloud-backup-delete.
  It allows to set the minimum number of backups that should always be available.

• Add a new primary_checkpoint_timeout configuration option. Allows define
  the amount of seconds that Barman will wait at the end of a backup if no
  new WAL files are produced, before forcing a checkpoint on the primary server.

Bug fixes:

• Fix race condition in barman retention policies application. Backup
  deletions will now raise a warning if another deletion is in progress
  for the requested backup.

• Fix barman-cloud-backup-show man page installation.

Barman 3.7.0

Version 3.7.0 - 25 July 2023

Features

• Support is added for snapshot backups on AWS using EBS volumes.

• The --profile option in the barman-cloud-* scripts is renamed
  --aws-profile. The old name is deprecated and will be removed in
  a future release.

• Backup manifests can now be generated automatically on completion
  of a backup made with backup_method = rsync. This is enabled by
  setting the autogenerate_manifest configuration variable and can
  be overridden using the --manifest and --no-manifest CLI options.

Bug fixes:

• The barman-cloud-* scripts now correctly use continuation
  tokens to page through objects in AWS S3-compatible object
  stores. This fixes a bug where barman-cloud-backup-delete
  would only delete the oldest 1000 eligible WALs after backup
  deletion.

• Minor documentation fixes.

Barman 3.6.0

Version 3.6.0 - 15 June 2023

Features

• PostgreSQL version 10 is no longer supported.

• Support is added for snapshot backups on Microsoft Azure using
  Managed Disks.

• The --snapshot-recovery-zone option is renamed --gcp-zone for
  consistency with other provider-specific options. The old name
  is deprecated and will be removed in a future release.

• The snapshot_zone option and --snapshot-zone argument are
  renamed gcp_zone and --gcp-zone respectively. The old names
  are deprecated and will be removed in a future release.

• The snapshot_gcp_project option and --snapshot-gcp-project
  argument are renamed to gcp_project and --gcp-project. The
  old names are deprecated and will be removed in a future release.

Bug fixes:

• Barman will no longer attempt to execute the replication-status
  command for a passive node.

• The backup_label is deleted from cloud storage when a
  snapshot backup is deleted with barman-cloud-backup-delete.

• Man pages for the generate-manifest and verify-backup
  commands are added.

• Minor documentation fixes.

Barman 3.4.1

Version 3.4.1 - 31 March 2023

Bug fixes:

• Fix a bug which prevented barman-cloud-backup-show from
  displaying the backup metadata for backups made with
  barman backup and uploaded by barman-cloud-backup as a
  post-backup hook script.

• Fix a bug where the PostgreSQL connection used to validate backup
  compression settings was left open until termination of the
  Barman command.

• Fix an issue which caused rsync-concurrent backups to fail when
  running for a duration greater than idle_session_timeout.

• Fix a bug where the backup name was not saved in the backup
  metadata if the --wait flag was used with barman backup.

Acknowledgements

We thank the following who contributed to this release:

• barthisrael
• epolkerman
• hzetters

Barman 3.5.0

Version 3.5.0 - 29 March 2023

Features

• Python 2.7 is no longer supported. The earliest Python version
  supported is now 3.6.

• The barman, barman-cli and barman-cli-cloud packages for
  EL7 now require python 3.6 instead of python 2.7. For other
  supported platforms, Barman packages already require python
  versions 3.6 or later so packaging is unaffected.

• Support for PostgreSQL 10 will be discontinued in future Barman
  releases; 3.5.x is the last version of Barman with support for
  PostgreSQL 10.

• Backups and WALs uploaded to Google Cloud Storage can now be
  encrypted using a specific KMS key by using the --kms-key-name
  option with barman-cloud-backup or barman-cloud-wal-archive.

• Backups and WALs uploaded to AWS S3 can now be encrypted using a
  specific KMS key by using the --sse-kms-key-id option with
  barman-cloud-backup or barman-cloud-wal-archive along with
  --encryption=aws:kms.

• Two new configuration options are provided which make it possible
  to limit the rate at which parallel workers are started during
  backups with backup_method = rsync and recoveries.
  parallel_jobs_start_batch_size can be set to limit the amount of
  parallel workers which will be started in a single batch, and
  parallel_jobs_start_batch_period can be set to define the time
  in seconds over which a single batch of workers will be started.
  These can be overridden using the arguments --jobs-start-batch-size
  and --jobs-start-batch-period with the barman backup and
  barman recover commands.

• A new option --recovery-conf-filename is added to barman recover.
  This can be used to change the file to which Barman should write the
  PostgreSQL recovery options from the default postgresql.auto.conf
  to an alternative location.

Bug fixes

• Fix a bug which prevented barman-cloud-backup-show from
  displaying the backup metadata for backups made with
  barman backup and uploaded by barman-cloud-backup as a
  post-backup hook script.

• Fix a bug where the PostgreSQL connection used to validate backup
  compression settings was left open until termination of the
  Barman command.

• Fix an issue which caused rsync-concurrent backups to fail when
  running for a duration greater than idle_session_timeout.

• Fix a bug where the backup name was not saved in the backup
  metadata if the --wait flag was used with barman backup.

Acknowledgements

We thank the following who contributed to this release:

• barthisrael
• epolkerman
• hzetters
• mhkarimi1383
• mojtabash78