EDB 荣幸地宣布发布 Barman 3.11.1 和 3.11.0。
`barman-cloud-backup-delete` 命令失败的问题。该命令由于上一个版本引入的 bug，在应用保留策略时会失败。增加了对 Postgres 17+ 增量备份的支持。这项主要功能由多个小改动组成。
为 `barman backup` 命令添加了 `--incremental` 命令行选项。用于在进行增量备份时指定父备份。父备份可以是完整备份，也可以是另一个增量备份。
添加了 `latest-full` 快捷备份 ID。与 `latest` 一起，可以用作选择增量备份父备份的快捷方式。`latest` 会选择最新的备份，无论它是完整备份还是增量备份，而 `latest-full` 则选择最新的完整备份。
当 `backup_method = postgres` 时，`barman keep` 命令只能应用于完整备份。如果一个完整备份有依赖于它的增量备份，Barman 也会保留所有这些增量备份。
删除备份时，所有依赖于该备份的增量备份（如果有）也会被删除。
保留策略不考虑增量备份。由于增量备份无法在没有完整备份链的情况下恢复，因此只有完整备份会考虑保留策略。
`barman recover` 在恢复时需要将完整备份与增量备份链结合起来。新的 CLI 选项 `--local-staging-path` 和相应的 `local_staging_path` 配置选项，用于指定 Barman 主机上组合备份的路径，以便在恢复增量备份时使用。
对 `barman show-backup` 输出的更改
添加了“估计集群大小”字段。在恢复备份时，了解集群数据目录大小的估计值非常有用。在恢复压缩备份或增量备份时尤其有用，因为这些情况下备份的大小可能无法反映 Postgres 中数据目录的大小。在 JSON 格式中，这存储为 `cluster_size`。
添加了“WAL 摘要器”字段。该字段显示在创建备份时 Postgres 是否启用了 `summarize_wal`。在 JSON 格式中，这存储为 `server_information.summarize_wal`。此字段在 Postgres 16 及更早版本中被省略。
添加了“数据校验和”字段。这显示在创建备份时 Postgres 是否启用了 `data_checksums`。在 JSON 格式中，这存储为 `server_information.data_checksums`。
添加了“备份方法”字段。这显示了用于此备份的备份方法。在 JSON 格式中，这存储为 `base_backup_information.backup_method`。
将“磁盘使用情况”字段重命名为“备份大小”。后者提供了更全面的名称，代表了 Barman 主机上备份的大小。`base_backup_information` 下的 JSON 字段也从 `disk_usage` 重命名为 `backup_size`。
添加了“WAL 大小”字段。这显示了备份所需的 WAL 的大小。在 JSON 格式中，这存储为 `base_backup_information.wal_size`。
重构了“增量大小”字段。现在它被命名为“资源节省”，它现在显示了使用 `rsync` 或 `pg_basebackup` 进行增量备份时节省资源的估计值。它将备份大小与估计的集群大小进行比较，以估计通过增量备份节省的磁盘和网络资源量。在 JSON 格式中，该字段已从 `incremental_size` 重命名为 `resource_savings`，位于 `base_backup_information` 下。
将 `system_id` 字段添加到 JSON 文档中。此字段包含 Postgres 的系统标识符。它存在于控制台格式中，但在 JSON 格式中缺失。
添加与 Postgres 增量备份相关的字段。
“备份类型”：指示 Postgres 备份是完整备份还是增量备份。在 JSON 格式中，这存储为 `base_backup_information` 下的 `backup_type`。
“根备份”：一个或多个增量备份链的根备份的完整备份 ID。在 JSON 格式中，这存储为 `catalog_information.root_backup_id`。
“父备份”：从中获取此增量备份的完整备份或增量备份的 ID。在 JSON 格式中，这存储为 `catalog_information.parent_backup_id`。
“子备份”：以该备份作为父备份创建的增量备份的 ID。在 JSON 格式中，这存储为 `catalog_information.children_backup_ids`。
“备份链大小”：从该增量备份到根备份的备份链中的备份数量。在 JSON 格式中，这存储为 `catalog_information.chain_size`。
对 `barman list-backup` 输出的更改
现在 JSON 输出中包含了备份类型，它可以是使用 rsync 备份的 `rsync`，使用 `pg_basebackup` 备份的 `full` 或 `incremental`，或者是云快照的 `snapshot`。在控制台输出时，备份类型由相应的标签 `R`、`F`、`I` 或 `S` 表示。
从输出中删除了表空间信息。这使输出变得臃肿。表空间信息仍然可以在 `barman show-backup` 的输出中找到。
在通过 `barman recover` 配置 `recovery_target_time` 时，始终设置带有时区的时戳。以前，如果通过 `--target-time` 未明确设置时区，Barman 会在 Postgres 中配置不带时区的 `recovery_target_time`。在没有时区的情况下，Postgres 会假定为 Postgres 中通过 `timezone` GUC 配置的任何内容。从现在开始，如果用户未通过 `--target-time` 选项设置时区，Barman 将发出警告并使用 Barman 主机的时区配置 `recovery_target_time`。
在以“不获取 WAL”方式恢复备份并设置了 `--target-lsn` 时，仅复制到达目标所需的 WAL 文件。以前 Barman 会将从其存档中的所有 WAL 文件复制到 Postgres。
在以“不获取 WAL”方式恢复备份并设置了 `--target-immediate` 时，仅复制到达一致点所需的 WAL 文件。以前 Barman 会将从其存档中的所有 WAL 文件复制到 Postgres。
`barman-wal-restore` 现在将 WAL 从 spool 目录移动到 `pg_wal` 而不是复制它们。如果 spool 目录和 `pg_wal` 目录在同一分区，这可以提高性能。
`barman check-backup` 现在在其输出和日志中显示备份被标记为 `FAILED` 的原因。以前，用户需要运行 `barman show-backup` 命令才能知道备份被标记为 `FAILED` 的原因。
在 `barman-cloud-backup` 中添加了配置选项 `aws_await_snapshots_timeout` 和相应的 `--aws-await-snapshots-timeout` 命令行选项。这指定了等待快照备份达到完成状态的超时时间（以秒为单位）。
为基于 rsync 的备份添加了心跳机制。以前，Barman 为运行 `pg_backup_start()` 和 `pg_backup_stop()` 创建的 Postgres 会话会保持空闲状态，直到基础备份复制完成。这可能导致防火墙或路由器因连接空闲时间过长而断开连接。心跳机制通过该连接向 Postgres 发送心跳查询，从而降低连接被断开的可能性。心跳之间的间隔可以通过新的配置选项 `keepalive_interval` 和 `barman backup` 命令的相应 CLI 选项 `--keepalive-interval` 来控制。
在以“不获取 WAL”方式恢复备份并设置了 `--target-time` 时，复制所有 WAL 文件。以前 Barman 会尝试“猜测”Postgres 到达配置目标时间所需的 WAL 文件。然而，该机制不够健壮，因为它基于 Barman 主机上 WAL 文件的统计信息（特别是创建时间）。例如：如果在 Postgres 和 Barman 之间存在归档或流式传输延迟，这可能足以导致恢复失败，因为 Barman 由于基于文件统计信息的薄弱检查而错过复制所有必需的 WAL 文件。
在通过 Python 3.6 或更早版本运行 Barman 时，将 `python-snappy` 固定到 `0.6.1`。较新版本的 `python-snappy` 需要 `cramjam` 版本 `2.7.0` 或更高版本，而这些仅适用于 Python 3.7 或更新版本。
`barman receive-wal` 在以下情况下现在退出代码为 `1`，而不是 `0`：
由于 `pg_receivewal` 正在运行，无法使用 `--reset` 标志运行。
由于 `pg_receivewal` 进程已在运行，无法启动它。
修复并改进了 `barman diagnose` 输出中关于 Python 的信息。
该命令现在确保在输出 `python_ver` JSON 键中的 Python 版本时，使用 Barman 安装所在的同一 Python 解释器。以前，如果环境有多个 Python 安装和/或虚拟环境，输出可能会产生误导，因为它可能来自不同的 Python 解释器。
向 JSON 输出添加了一个 `python_executable` 键。它包含 Barman 使用的确切 Python 解释器的路径。
这些信息也发布在 Barman 的 NEWS 文件中。
Backup and Recovery Manager（或 Barman）是一个开源的管理工具，用于在关键业务环境中远程备份和灾难恢复 PostgreSQL 服务器。它依赖于 PostgreSQL 强大而可靠的即时恢复（Point-In-Time Recovery）技术，允许 DBA 从一个位置远程管理多个远程服务器的完整备份目录和恢复阶段。Barman 在 GNU GPL 3 下分发，由 EDB 维护。