From 182fb6b0993a7c82e5cc28f5cb4c1c982c312004 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Thu, 21 Nov 2024 15:19:44 +0000 Subject: [PATCH] Automated release notes for 3.12.0 --- RELNOTES.md | 211 ++++++++++++++++++++++++++++++++++++++ release_notes/bar-155.yml | 21 ---- release_notes/bar-242.yml | 14 --- release_notes/bar-244.yml | 15 --- release_notes/bar-264.yml | 9 -- release_notes/bar-265.yml | 9 -- release_notes/bar-331.yml | 9 -- release_notes/bar-337.yml | 16 --- release_notes/bar-348.yml | 19 ---- release_notes/bar-356.yml | 12 --- release_notes/bar-366.yml | 23 ----- release_notes/bar-374.yml | 12 --- release_notes/bar-389.yml | 8 -- release_notes/bar-409.yml | 23 ----- release_notes/bar-417.yml | 10 -- release_notes/bar-423.yml | 9 -- release_notes/bar-435.yml | 11 -- 17 files changed, 211 insertions(+), 220 deletions(-) delete mode 100644 release_notes/bar-155.yml delete mode 100644 release_notes/bar-242.yml delete mode 100644 release_notes/bar-244.yml delete mode 100644 release_notes/bar-264.yml delete mode 100644 release_notes/bar-265.yml delete mode 100644 release_notes/bar-331.yml delete mode 100644 release_notes/bar-337.yml delete mode 100644 release_notes/bar-348.yml delete mode 100644 release_notes/bar-356.yml delete mode 100644 release_notes/bar-366.yml delete mode 100644 release_notes/bar-374.yml delete mode 100644 release_notes/bar-389.yml delete mode 100644 release_notes/bar-409.yml delete mode 100644 release_notes/bar-417.yml delete mode 100644 release_notes/bar-423.yml delete mode 100644 release_notes/bar-435.yml diff --git a/RELNOTES.md b/RELNOTES.md index 0630d3cc1..dc431e0c7 100644 --- a/RELNOTES.md +++ b/RELNOTES.md @@ -2,6 +2,217 @@ © Copyright EnterpriseDB UK Limited 2024 - All rights reserved. +## 3.12.0 (2024-11-21) + +### Minor changes + +- Add FIPS support to Barman + + The `md5` hash algorithm is not FIPS compliant, so it is going to be replaced by + `sha256`. `sha256` is FIPS compliant, vastly used, and is considered secure for most + practical purposes. + Up until this release, Barman's WAL archive client used `hashlib.md5` to generate + checksums for tar files before they were sent to the Barman server. Here, a tar file is + a file format used for bundling multiple files together with a `MD5SUMS` file that lists + the checksums and their corresponding paths. + In this release, the `md5` hashing algorithm is replaced by `sha256` as the default. + As a result, checksums for the tar files will be calculated using `sha256`, and the + `MD5SUMS` file will be named `SHA256SUMS`. Barman still has the ability to use the + nondefault `md5` algorithm and the `MD5SUMS` file from the client if there is a use + case for it. The user just needs to add the `--md5` flag to the `barman-wal-archive` + `archive_command`. + + References: BAR-155, CP-34954, CP-34391. + +- Removed el7, debian10, and ubuntu1804 support; updated Debian and SLES. + + Support for el7, debian10, and ubuntu1804 has been removed. Additionally, version 12 + and version name "bookworm" has been added for Debian, addressing a previously + missing entry. The SLES image version has also been updated from sp4 to sp5. + + References: BAR-389. + +- Add support for Postgres Extended 17 (PGE) and Postgres Advanced Server 17 (EPAS) + + Tests were conducted on Postgres Extended 17 (PGE) and Postgres Advanced Server 17 + (EPAS), confirming full compatibility with the latest features in Barman. This + validation ensures that users of the latest version of PGE and EPAS can leverage all the new + capabilities of Barman with confidence. + + References: BAR-331. + +- Improve WAL compression with `zstd`, `lz4` and `xz` algorithms + + Introduced support for xz compression on WAL files. It can be enabled by specifying + `xz` in the `compression` server parameter. WALs will be compressed when entering + the Barman's WAL archive. For the cloud, it can be enabled by specifying `--xz` + when running `barman-cloud-wal-archive`. + + Introduced support for zstandard compression on WAL files. It can be enabled by + specifying `zstd` in the `compression` server parameter. WALs will be compressed + when entering the Barman's WAL archive. For the cloud, it can be enabled by + specifying `--zstd` when running `barman-cloud-wal-archive`. + + Introduced support for lz4 compression on WAL files. It can be enabled by + specifying `lz4` in the `compression` server parameter. WALs will be compressed + when entering the Barman's WAL archive. For the cloud, it can be enabled by + specifying `--lz4` when running `barman-cloud-wal-archive`. + + References: BAR-265, BAR-423, BAR-264. + +- Improve WAL upload performance on S3 buckets by avoiding multipart uploads + + Previously, WAL files were being uploaded to S3 buckets using multipart uploads + provided by the boto3 library via the `upload_fileobj` method. It was noticed that + multipart upload is slower when used for small files, such as WAL segments, + compared to when uploading it in a single PUT request. + This has been improved by avoiding multipart uploads for files smaller than 100MB. + The average upload time of each WAL file is expected to be reduced by around 15% + with this change. + + References: BAR-374. + +- Modify behavior when enforcing retention policy for `KEEP:STANDALONE` full backups + + When enforcing the retention policy on full backups created with + `backup_method = postgres`, Barman was previously marking all dependent (child) + incremental backups as `VALID`, regardless of the KEEP target used. However, this + approach is incorrect: + + - For backups labeled `KEEP:STANDALONE`, Barman only retains the WAL files needed to + restore the server to the exact state of that backup. Because these backups are + self-contained, any dependent child backups are no longer needed once the root + backup is outside the retention policy. + + - In contrast, backups marked `KEEP:FULL` are intended for point-in-time recovery. + To support this, Barman retains all WALs, as well as any child backups, to ensure + the backup's consistency and allow recovery to the latest possible point. + + This distinction ensures that `KEEP:STANDALONE` backups serve as snapshots of a + specific moment, while `KEEP:FULL` backups retain everything needed for full + point-in-time recovery. + + References: BAR-366. + +- Update documentation and user-facing features for Barman's recovery process. + + Barman docs and the tool itself used to use the terms "recover"/"recovery" both for + referencing: + + - The Postgres recovery process; + - The process of restoring a backup and preparing it for recovery. + + Both the code and documentation have been revised to accurately reflect the usage of + the terms "restore" and "recover"/"recovery". + + Also, the `barman recover` command was renamed to `barman restore`. The old name is + still kept as an alias for backward compatibility. + + References: BAR-337. + +- Add --keep-compression flag to barman-wal-restore and get-wal + + A new `--keep-compression` option has been added to both `barman-wal-restore` and + `get-wal`. This option controls whether compressed WAL files should be decompressed + on the Barman server before being fetched. When specified with `get-wal`, default + decompression is skipped, and the output is the WAL file content in its original + state. When specified with `barman-wal-restore`, the WAL file is fetched as-is and, + if compressed, decompressed on the client side. + + References: BAR-435. + +- Ransomware protection - Add AWS Snapshot Lock Support + + Barman now supports AWS EBS Snapshot Lock, a new integrated feature to prevent + accidental or malicious deletions of Amazon EBS snapshots. When a snapshot is + locked, it can't be deleted by any user but remains fully accessible for use. This + feature enables you to store snapshots in WORM (Write-Once-Read-Many) format for a + specified duration, helping to meet regulatory requirements by keeping the data + secure and tamper-proof until the lock expires. + + Special thanks to Rui Marinho, our community contributor who started this feature. + + References: BAR-242. + +- Prevent orphan files from being left from a crash while deleting a backup + + This commit fixes an issue where backups could leave behind files if the system + crashed during the deletion of a backup. + + Now, when a backup is deleted, it will get a "delete marker" at the start. + If a crash happens while the backup is being deleted, the marker will help + recognize incomplete backup removals when the server restarts. + + The Barman cron job has been updated to look for these deleted markers. If it finds + a backup with a "delete marker", it will complete the process. + + References: BAR-244. + +- Add support for using tags with snapshots + + Barman now supports tagging the snapshots when creating backups using the + barman-cloud-backup script command. A new argument called --tags was added. + + Special thanks to Rui Marinho, our community contributor who started this feature. + + References: BAR-417. + +### Bugfixes + +- Fix barman check which returns wrong results for Replication Slot + + Previously, when using architectures which backup from a standby node and stream WALs + from the primary, Barman would incorrectly use `conninfo` (pointing to a standby server) + for replication checks, leading to errors such as: + + `replication slot (WAL streaming): FAILED (replication slot 'barman' doesn't exist. + Please execute 'barman receive-wal --create-slot pg17')` + + This fixes the following issue + [#1024](https://github.com/EnterpriseDB/barman/issues/1024) by ensuring + `wal_conninfo` is used for WAL replication checks if it's set. + + `wal_conninfo` takes precedence over `wal_streaming_conninfo`, when both are set. + With this change, if only `wal_conninfo` is set, it will be used and will not fall + back to `conninfo`. + + Also, in the documentation, changes were made so it is explicit that when `conninfo` + points to a standby server, `wal_conninfo` must be set and used for accurate + replication status checks. + + References: BAR-409. + +- Fix missing options for `barman keep` + + The error message that the Barman CLI emitted when running `barman keep` + without any options suggested there were shortcut aliases for status and + release. These aliases, -s and -r, do not exist, so the error message was + misleading. + This fixes the issue by including these short options in the Barman CLI, + aligning it with other tools like `barman-cloud-backup-keep`, where these + shortcuts already exist. + + References: BAR-356. + +- Lighten standby checks related to conninfo and primary_conninfo + + When backing up a standby server, Barman performs some checks to assert + that `conninfo` is really pointing to a standby (in recovery mode) and + that `primary_conninfo` is pointing to a primary (not in recovery). + + The problem, as reported in the issues #704 and #744, is that when a + failover occurs, the `conninfo` will now be pointing to a primary + instead and the checks will start failing, requiring the user to change + Barman configs manually whenever a failover occurs. + + This fix solved the issue by making such checks non-critical, which + means they will still fail but Barman will keep operating regardless. + Essentially, Barman will ignore `primary_conninfo` if `conninfo` does + not point to a standby. Warnings about this misconfiguration will also + be emitted whenever running any Barman command so the user can be aware. + + References: BAR-348. + ## 3.11.1 (2024-08-22) ### Bugfixes diff --git a/release_notes/bar-155.yml b/release_notes/bar-155.yml deleted file mode 100644 index f624902c5..000000000 --- a/release_notes/bar-155.yml +++ /dev/null @@ -1,21 +0,0 @@ -- summary: Add FIPS support to Barman - description: | - The `md5` hash algorithm is not FIPS compliant, so it is going to be replaced by - `sha256`. `sha256` is FIPS compliant, vastly used and is considered secure for most - practical purposes. - Up until this release, Barman's WAL archive client used `hashlib.md5` to generate - checksums for tar files before they are sent to the Barman server. Here, a tar file is - a file format used for bundling multiple files together with a `MD5SUMS` file that lists - the checksums and their corresponding paths. - In this release, the `md5` hashing algorithm is replaced by `sha256` as the default. - As a result, checksums for the tar files will be calculated using `sha256`, and the - `MD5SUMS` file will be named `SHA256SUMS`. Barman still has the ability to use the - non default `md5` algorithm and the `MD5SUMS` file from the client if there is a use - case for it. The user just needs to add the `--md5` flag to the `barman-wal-archive` - `archive_command`. - type: minor_change - jira_tickets: - - BAR-155 - support_tickets: - - CP-34954 - - CP-34391 diff --git a/release_notes/bar-242.yml b/release_notes/bar-242.yml deleted file mode 100644 index 605c36252..000000000 --- a/release_notes/bar-242.yml +++ /dev/null @@ -1,14 +0,0 @@ -- summary: | - Ransomware protection - Add AWS Snapshot Lock Support - description: | - Barman now supports AWS EBS Snapshot Lock, a new integrated feature to prevent - accidental or malicious deletions of Amazon EBS snapshots. When a snapshot is - locked, it can't be deleted by any user, but remains fully accessible for use. This - feature enables you to store snapshots in WORM (Write-Once-Read-Many) format for a - specified duration, helping to meet regulatory requirements by keeping the data - secure and tamper-proof until the lock expires. - - Special thanks to Rui Marinho, our community contributor that started this feature. - type: minor_change - jira_tickets: - - BAR-242 diff --git a/release_notes/bar-244.yml b/release_notes/bar-244.yml deleted file mode 100644 index a33089e21..000000000 --- a/release_notes/bar-244.yml +++ /dev/null @@ -1,15 +0,0 @@ ---- -- summary: Prevent orphan files from being left from a crash while deleting a backup - description: | - This commit fixes an issue where backups could leave behind files if the system - crashed during the deletion of a backup. - - Now, when a backup is deleted, it will get a "delete marker" at the start. - If a crash happens while the backup is being deleted, the marker will help - recognize incomplete backup removals when the server restarts. - - The Barman cron job has been updated to look for these delete markers. If it finds - a backup with a "delete marker", it will complete the process. - type: minor_change - jira_tickets: - - BAR-244 diff --git a/release_notes/bar-264.yml b/release_notes/bar-264.yml deleted file mode 100644 index 4666dfe40..000000000 --- a/release_notes/bar-264.yml +++ /dev/null @@ -1,9 +0,0 @@ -- summary: Add lz4 compression for WAL files - description: | - Introduced support for lz4 compression on WAL files. It can be enabled by - specifying `lz4` in the `compression` server parameter. WALs will be compressed - when entering the Barman's WAL archive. For the cloud, it can ne enabled by - specifying `--lz4` when running `barman-cloud-wal-archive`. - type: minor_change - jira_tickets: - - BAR-264 diff --git a/release_notes/bar-265.yml b/release_notes/bar-265.yml deleted file mode 100644 index 7d43d345e..000000000 --- a/release_notes/bar-265.yml +++ /dev/null @@ -1,9 +0,0 @@ -- summary: Add xz compression for WAL files - description: | - Introduced support for xz compression on WAL files. It can be enabled by specifying - `xz` in the `compression` server parameter. WALs will be compressed when entering - the Barman's WAL archive. For the cloud, it can ne enabled by specifying `--xz` - when running `barman-cloud-wal-archive`. - type: minor_change - jira_tickets: - - BAR-265 diff --git a/release_notes/bar-331.yml b/release_notes/bar-331.yml deleted file mode 100644 index c3f00bb8b..000000000 --- a/release_notes/bar-331.yml +++ /dev/null @@ -1,9 +0,0 @@ -- summary: Add support for Postgres Extended 17 (PGE) and Postgres Advanced Server 17 (EPAS) - description: | - Tests were conducted on Postgres Extended 17 (PGE) and Postgres Advanced Server 17 - (EPAS), confirming full compatibility with the latest features in Barman. This - validation ensures that users of the latest version of PGE and EPAS can leverage all the new - capabilities of Barman with confidence. - type: minor_change - jira_tickets: - - BAR-331 diff --git a/release_notes/bar-337.yml b/release_notes/bar-337.yml deleted file mode 100644 index 5453f44dc..000000000 --- a/release_notes/bar-337.yml +++ /dev/null @@ -1,16 +0,0 @@ -- summary: Update documentation and user-facing features for Barman's recovery process. - description: | - Barman docs and the tool itself used to use the terms "recover"/"recovery" both for - referencing: - - * The Postgres recovery process; - * The process of restoring a backup and preparing it for recovery. - - Both the code and documentation have been revised to accurately reflect the usage of - the the terms "restore" and "recover"/"recovery". - - Also, the `barman recover` command was renamed to `barman restore`. The old name is - still kept as an alias for backward compatibility. - type: minor_change - jira_tickets: - - BAR-337 diff --git a/release_notes/bar-348.yml b/release_notes/bar-348.yml deleted file mode 100644 index e405aaa53..000000000 --- a/release_notes/bar-348.yml +++ /dev/null @@ -1,19 +0,0 @@ -- summary: Lighten standby checks related to conninfo and primary_conninfo - description: | - When backing up a standby server, Barman performs some checks to assert - that `conninfo` is really pointing to a standby (in recovery mode) and - that `primary_conninfo` is pointing to a primary (not in recovery). - - The problem, as reported in the issues #704 and #744, is that when a - failover occurs, the `conninfo` will now be pointing to a primary - instead and the checks will start failing, requiring the user to change - Barman configs manually whenever a failover occurs. - - This fix solved the issue by making such checks non-critical, which - means they will still fail but Barman will keep operating regardless. - Essentially, Barman will ignore `primary_conninfo` if `conninfo` does - not point to a standby. Warnings about this misconfiguration will also - be emited whenever running any Barman command so the user can be aware. - type: bugfix - jira_tickets: - - BAR-348 diff --git a/release_notes/bar-356.yml b/release_notes/bar-356.yml deleted file mode 100644 index e5ce75784..000000000 --- a/release_notes/bar-356.yml +++ /dev/null @@ -1,12 +0,0 @@ -- summary: Fix missing options for `barman keep` - description: | - The error message that the Barman CLI emitted when running `barman keep` - without any options suggested there were shortcut aliases for status and - release. These aliases, -s and -r, do not exist, so the error message was - misleading. - This fixes the issue by including these short options in the Barman CLI, - aligning it with other tools like `barman-cloud-backup-keep`, where these - shortcuts already exist. - type: bugfix - jira_tickets: - - BAR-356 diff --git a/release_notes/bar-366.yml b/release_notes/bar-366.yml deleted file mode 100644 index c2b990fd1..000000000 --- a/release_notes/bar-366.yml +++ /dev/null @@ -1,23 +0,0 @@ -- summary: | - Modify behavior when enforcing retention policy for `KEEP:STANDALONE` full backups - description: | - When enforcing the retention policy on full backups created with - `backup_method = postgres`, Barman was previously marking all dependent (child) - incremental backups as `VALID`, regardless of the KEEP target used. However, this - approach is incorrect: - - - For backups labeled `KEEP:STANDALONE`, Barman only retains the WAL files needed to - restore the server to the exact state of that backup. Because these backups are - self-contained, any dependent child backups are no longer needed once the root - backup is outside the retention policy. - - - In contrast, backups marked `KEEP:FULL` are intended for point-in-time recovery. - To support this, Barman retains all WALs, as well as any child backups, to ensure - the backup's consistency and allow recovery to the latest possible point. - - This distinction ensures that `KEEP:STANDALONE` backups serve as snapshots of a - specific moment, while `KEEP:FULL` backups retain everything needed for full - point-in-time recovery. - type: minor_change - jira_tickets: - - BAR-366 diff --git a/release_notes/bar-374.yml b/release_notes/bar-374.yml deleted file mode 100644 index 55d585770..000000000 --- a/release_notes/bar-374.yml +++ /dev/null @@ -1,12 +0,0 @@ -- summary: Improve WAL upload performance on S3 buckets by avoiding multipart uplaods - description: | - Previously, WAL files were being uploaded to S3 buckets using multipart uploads - provided by the boto3 library via the `upload_fileobj` method. It was noticed that - multipart upload is slower when used for small files, such as WAL segments, - compared to when uploading it in a single PUT request. - This has been improved by avoiding multipart uploads for files smaller than 100MB. - The average upload time of each WAL file is expected to be reduced in around 15% - with this change. - type: minor_change - jira_tickets: - - BAR-374 diff --git a/release_notes/bar-389.yml b/release_notes/bar-389.yml deleted file mode 100644 index 5677f7257..000000000 --- a/release_notes/bar-389.yml +++ /dev/null @@ -1,8 +0,0 @@ -- summary: Removed el7, debian10, and ubuntu1804 support; updated Debian and SLES. - description: | - Support for el7, debian10, and ubuntu1804 has been removed. Additionally, version 12 - and version name "bookworm" have been added for Debian, addressing a previously - missing entry. The SLES image version has also been updated from sp4 to sp5. - type: minor_change - jira_tickets: - - BAR-389 diff --git a/release_notes/bar-409.yml b/release_notes/bar-409.yml deleted file mode 100644 index ff837eaf8..000000000 --- a/release_notes/bar-409.yml +++ /dev/null @@ -1,23 +0,0 @@ -- summary: | - Fix check server returns wrong results for Replication Slot - description: | - Previously, Barman would incorrectly use `conninfo` (pointing to a standby server) - for replication checks, leading to errors such as: - - `replication slot (WAL streaming): FAILED (replication slot 'barman' doesn't exist. - Please execute 'barman receive-wal --create-slot pg17')` - - This fixes the issue from github - [#1024](https://github.com/EnterpriseDB/barman/issues/1024) by ensuring - `wal_conninfo` is used for WAL replication checks if set. - - `wal_conninfo` takes precedence over `wal_streaming_conninfo`, when both are set. - With this change, if only `wal_conninfo` is set, is will be used and will not fall - back to `conninfo`. - - Also, in the documentation, changes were made so it is explicit that when `conninfo` - points to a standby server, `wal_conninfo` must be set and used for accurate - replication status checks. - type: bugfix - jira_tickets: - - BAR-409 diff --git a/release_notes/bar-417.yml b/release_notes/bar-417.yml deleted file mode 100644 index 276aa2a90..000000000 --- a/release_notes/bar-417.yml +++ /dev/null @@ -1,10 +0,0 @@ -- summary: | - Add support for using tags with snapshots - description: | - Barman now supports tagging the snapshots when creating backups using the - barman-cloud-backup script command. A new argument called --tags was added. - - Special thanks to Rui Marinho, our community contributor that started this feature. - type: minor_change - jira_tickets: - - BAR-417 diff --git a/release_notes/bar-423.yml b/release_notes/bar-423.yml deleted file mode 100644 index 61523112d..000000000 --- a/release_notes/bar-423.yml +++ /dev/null @@ -1,9 +0,0 @@ -- summary: Add zstandard compression for WAL files - description: | - Introduced support for zstandard compression on WAL files. It can be enabled by - specifying `zstd` in the `compression` server parameter. WALs will be compressed - when entering the Barman's WAL archive. For the cloud, it can ne enabled by - specifying `--zstd` when running `barman-cloud-wal-archive`. - type: minor_change - jira_tickets: - - BAR-423 diff --git a/release_notes/bar-435.yml b/release_notes/bar-435.yml deleted file mode 100644 index 2b7983c83..000000000 --- a/release_notes/bar-435.yml +++ /dev/null @@ -1,11 +0,0 @@ -- summary: Add --keep-compression flag to barman-wal-restore and get-wal - description: | - A new `--keep-compression` option has been added to both `barman-wal-restore` and - `get-wal`. This option controls whether compressed WAL files should be decompressed - on the Barman server before being fetched. When specified with `get-wal`, default - decompression is skipped, and the output is the WAL file content in its original - state. When specified with `barman-wal-restore`, the WAL file is fetched as-is and, - if compressed, decompressed on the client side. - type: minor_change - jira_tickets: - - BAR-435