Log message:
py-barman: updated to 3.13.0
3.13.0 (2025-02-20)
Notable changes
- Add new xlogdb_directory configuration
Introduces a new `xlogdb_directory` configuration option. This parameter can be
set either globally or per-server, and allows you to specify a custom directory
for the `xlog.db` file. This file stores metadata of archived WAL files and is used
internally by Barman in various scenarios. If unset, it defaults to the value of
`wals_directory`. Additionally, the file was also renamed to contain the \
server name
as a prefix.
- Make "backup_id" optional when restoring a backup
Historically, Barman always required a "backup_id" to restore a \
backup, and would
use that backup as the source for the restore.
This feature removes the need for specifying which backup to use as a source for
restore, making it optional.
This change applies to both Barman and the barman-cloud scripts.
Now the user is able to restore a backup in the following ways:
1. Provide a "backup_id"
2. Do not provide a "backup_id". It will retrieve the most recent \
backup
3. Do not provide a "backup_id", but provide a recovery target, \
such as:
- "target_time" (mutually exclusive with target_lsn)
Will get the closest backup prior to the "target_time"
- "target_lsn" (mutually exclusive with "target_time")
Will get the closest backup prior to the "target_lsn"
- "target_tli" (can be used combined with \
"target_time" or "target_lsn")
Will get the most recent backup that matches the timeline. If combined with
other recovery targets, it will get the most recent backup prior to the
target_time or target_lsn that matches the timeline
The recovery targets `--target-xid`, `--target-name` and `--target-immediate`
are not supported, and will error out with a message if used.
This feature will provide flexibility and ease when restoring a postgres cluster.
Minor changes
- Add current active model to `barman show-server` and `barman status`
Previously, after applying a configuration model, the only way to check
which model is currently active for a server was via the `barman diagnose`
command. With this update, the `barman status` and `barman show-server`
commands now also display the current active configuration model for a
server, if any.
- Add `--staging-wal-directory` option to `barman restore` command to allow \
alternative WAL directory on PITR
A new command line option `--staging-wal-directory` was added to the \
`restore`/`recover`
command to allow an alternative destination directory for WAL files when performing
PITR. Previously, WAL files were copied to a `barman_wal` directory within
the restore destination directory. This enhancement provides greater \
flexibility, such as
storing WALs on separate partitions during recovery.
- Pin boto3 version to any version <= 1.35.99
Boto3 version 1.36 has changed the way S3 integrity is checked making this version
incompatible with the current Barman code, generating the following error:
An error occurred (MissingContentLength) when calling the PutObject operation
As a temporary workaround, the version for boto3 is pinned to any version \
<= 1.35.99
until support for 1.36 is implemented in Barman.
- Make barman-wal-archive smarter when dealing with duplicate WAL files
Under some corner cases, Postgres could attempt to archive the same WAL twice.
For example: if `barman-wal-archive` copies the WAL file over to the Barman host,
but the script is interrupted before reporting success to Postgres. New executions
of `barman-wal-archive` could fail when trying to archive the same file again
because the WAL was already copied from Postgres to Barman, but not yet \
processed by
the asynchronous Barman WAL archiver.
This minor change deals with this situation by verifying the checksum of the
existing and the incoming file. If the checksums match the incoming file is
ignored, otherwise an output info message is sent and the incoming file is moved to
the errors directory. The code will exit with 0 in both situations, avoiding WALs
piling up in the Postgres host due to a failing `archive_command`.
- Document procedure to clear WAL archive failure check
While redesigning the Barman docs we missed adding a note advising
users to run a `switch-wal` command if the server is idle and
`barman check` returns a failure on "WAL archiving".
This addresses the gap left from the previous documentation.
- Delete WALs by deleting the entire directory at once, when possible
Previously, when WAL files needed to be deleted (e.g., due to deletion of a \
backup),
Barman would iterate over every WAL file and delete them individually. This could
cause performance issues, mainly in systems which use ZFS filesystem. With this
change, the entire directory will be deleted whenever noticed that all files in
the directory are no longer needed by Barman.
- Add support for `DefaultAzureCredential` option on Azure authentication
Users can now explicitly use Azure's `DefaultAzureCredential` for authentication
by using the `default` option for `azure_credential` in the server configuration
or the `--azure-credential default` option in the case of `barman-cloud-*`.
Previously, that could only be set as a fallback when no credential was provided
and no environment variables were set.
- Improve diagnose output for retention policy info
Improves the output of the barman diagnose command to display a more user-friendly
string representations. Specifically, "REDUNDANCY 2" is shown instead of
"redundancy 2 b" for the 'retention_policy' attribute, and \
"MAIN" is shown instead
of "simple-wal 2 b" for the 'wal_retention_policy' attribute.
Bugfixes
- Fix PITR when using `barman restore` with `--target-tli`
Barman was not creating the `recovery.signal` nor filling \
`recovery_target_timeline`
in `postgresql.auto.conf` in these cases:
* The only recovery target passed to `barman restore` was `--target-tli`; or
* `--target-tli` was specified with some other `--target-*` option, but the
specified target timeline was the same as the timeline of the chosen backup.
Now, if any `--target-*` option is passed to `barman restore`, that will be
correctly treated as PITR.
- Fix bug when AWS 'profile' variable is referenced before assignment
An issue was introduced by BAR-242 as part of the Barman 3.12.0 release.
The issue was causing `barman-cloud-backup-delete` (and possibly other
commands) to fail with errors like this when `--aws-profile` argument or
`aws_profile` configuration were not set:
```bash
ERROR: Barman cloud backup delete exception: local
variable 'profile' referenced before assignment`
```
- Fix --zstd flag on barman-cloud-wal-archive
Fixed a bug with the `--zstd` flag on `barman-cloud-wal-archive` where it was
essentially being ignored and not really compressing the WAL file before upload.
|
Log message:
py-barman: updated to 2.19
Version 2.19 - 9 March 2022
- Change `barman diagnose` output date format to ISO8601.
- Add Google Cloud Storage (GCS) support to barman cloud.
- Support `current` and `latest` recovery targets for the `--target-tli`
option of `barman recover`.
- Add documentation for installation on SLES.
- Bug fixes:
- `barman-wal-archive --test` now returns a non-zero exit code when
an error occurs.
- Fix `barman-cloud-check-wal-archive` behaviour when `-t` option is
used so that it exits after connectivity test.
- `barman recover` now continues when `--no-get-wal` is used and
`"get-wal"` is not set in `recovery_options`.
- Fix `barman show-servers --format=json ${server}` output for
inactive server.
- Check for presence of `barman_home` in configuration file.
- Passive barman servers will no longer store two copies of the
tablespace data when syncing backups taken with
`backup_method = postgres`.
- We thank richyen for his contributions to this release.
Version 2.18 - 21 January 2022
- Add snappy compression algorithm support in barman cloud (requires the
optional python-snappy dependency).
- Allow Azure client concurrency parameters to be set when uploading
WALs with barman-cloud-wal-archive.
- Add `--tags` option in barman cloud so that backup files and archived
WALs can be tagged in cloud storage (aws and azure).
- Update the barman cloud exit status codes so that there is a dedicated
code (2) for connectivity errors.
- Add the commands `barman verify-backup` and `barman generate-manifest`
to check if a backup is valid.
- Add support for Azure Managed Identity auth in barman cloud which can
be enabled with the `--credential` option.
- Bug fixes:
- Change `barman-cloud-check-wal-archive` behavior when bucket does
not exist.
- Ensure `list-files` output is always sorted regardless of the
underlying filesystem.
- Man pages for barman-cloud-backup-keep, barman-cloud-backup-delete
and barman-cloud-check-wal-archive added to Python packaging.
- We thank richyen and stratakis for their contributions to this
release.
Version 2.17 - 1 December 2021
- Bug fixes:
- Resolves a performance regression introduced in version 2.14 which
increased copy times for `barman backup` or `barman recover` commands
when using the `--jobs` flag.
- Ignore rsync partial transfer errors for `sender` processes so that
such errors do not cause the backup to fail (thanks to barthisrael).
Version 2.16 - 17 November 2021
- Add the commands `barman-check-wal-archive` and `barman-cloud-check-wal-archive`
to validate if a proposed archive location is safe to use for a new PostgreSQL
server.
- Allow Barman to identify WAL that's already compressed using a custom
compression scheme to avoid compressing it again.
- Add `last_backup_minimum_size` and `last_wal_maximum_age` options to
`barman check`.
- Bug fixes:
- Use argparse for command line parsing instead of the unmaintained
argh module.
- Make timezones consistent for `begin_time` and `end_time`.
- We thank chtitux, George Hansper, stratakis, Thoro, and vrms for their
contributions to this release.
Version 2.15 - 12 October 2021
- Add plural forms for the `list-backup`, `list-server` and
`show-server` commands which are now `list-backups`, `list-servers`
and `show-servers`. The singular forms are retained for backward
compatibility.
- Add the `last-failed` backup shortcut which references the newest
failed backup in the catalog so that you can do:
- `barman delete <SERVER> last-failed`
- Bug fixes:
- Tablespaces will no longer be omitted from backups of EPAS
versions 9.6 and 10 due to an issue detecting the correct version
string on older versions of EPAS.
Version 2.14 - 22 September 2021
- Add the `barman-cloud-backup-delete` command which allows backups in
cloud storage to be deleted by specifying either a backup ID or a
retention policy.
- Allow backups to be retained beyond any retention policies in force by
introducing the ability to tag existing backups as archival backups
using `barman keep` and `barman-cloud-backup-keep`.
- Allow the use of SAS authentication tokens created at the restricted
blob container level (instead of the wider storage account level) for
Azure blob storage
- Significantly speed up `barman restore` into an empty directory for
backups that contain hundreds of thousands of files.
- Bug fixes:
- The backup privileges check will no longer fail if the user lacks
"userepl" permissions and will return better error messages if any
required permissions are missing
Version 2.13 - 26 July 2021
- Add Azure blob storage support to barman-cloud
- Support tablespace remapping in barman-cloud-restore via
`--tablespace name:location`
- Allow barman-cloud-backup and barman-cloud-wal-archive to run as
Barman hook scripts, to allow data to be relayed to cloud storage
from the Barman server
- Bug fixes:
- Stop backups failing due to idle_in_transaction_session_timeout
(https://github.com/EnterpriseDB/barman/issues/333)
- Fix a race condition between backup and archive-wal in updating
xlog.db entries
- Handle PGDATA being a symlink in barman-cloud-backup, which led to
"seeking backwards is not allowed" errors on restore
- Recreate pg_wal on restore if the original was a symlink
- Recreate pg_tblspc symlinks for tablespaces on restore
- Make barman-cloud-backup-list skip backups it cannot read, e.g.,
because they are in Glacier storage
- Add `-d database` option to barman-cloud-backup to specify which
database to connect to initially
- Fix "Backup failed uploading data" errors from barman-cloud-backup
on Python 3.8 and above, caused by attempting to pickle the boto3
client
- Correctly enable server-side encryption in S3 for buckets that do
not have encryption enabled by default.
In Barman 2.12, barman-cloud-backup's `--encryption` option did
not correctly enable encryption for the contents of the backup if
the backup was stored in an S3 bucket that did not have encryption
enabled. If this is the case for you, please consider deleting
your old backups and taking new backups with Barman 2.13.
If your S3 buckets already have encryption enabled by default
(which we recommend), this does not affect you.
Version 2.12.1 - 30 June 2021
- Bug fixes:
- Allow specifying target-tli with other target-* recovery options
- Fix incorrect NAME in barman-cloud-backup-list manpage
- Don't raise an error if SIGALRM is ignored
- Fetch wal_keep_size, not wal_keep_segments, from Postgres 13
Version 2.12 - 5 Nov 2020
- Introduce a new backup_method option called local-rsync which
targets those cases where Barman is installed on the same server
where PostgreSQL is and directly uses rsync to take base backups,
bypassing the SSH layer.
- Bug fixes:
- Avoid corrupting boto connection in worker processes
- Avoid connection attempts to PostgreSQL during tests
|