如何利用Barman实现PostgreSQL远程备份与WAL流归档？

PostgreSQL 的高可用方案通常依赖两类基础能力：基础备份和 WAL 日志归档。基础备份负责建立数据文件的完整快照，WAL 归档则持续记录事务日志变化。二者组合才能实现任意时间点恢复。手动编写 Shell 脚本管理这两种文件虽然可行，但容易遇到归档路径混乱、备份过期策略不一致、恢复时需要手工拼接等问题。Barman（Backup and Recovery Manager）是专门为 PostgreSQL 设计的备份恢复工具，它把备份、WAL 归档、保留策略和恢复验证整合到一个服务中，适合在独立的备份服务器上运行。

远程备份的核心挑战是主库和备份服务器之间的网络衔接。Barman 支持两种通道：SSH 连接用于执行 rsync 文件同步，流复制连接用于 WAL 流式接收和 pg_basebackup 在线备份。两种通道可以组合使用，也可以只用流复制。流式归档让 WAL 文件在主库切换后几乎实时地传输到备份服务器，减少 RPO。接下来从架构、配置、恢复和问题排查几个方面展开。

一、Barman 远程备份的核心架构

Barman 并不是安装在 PostgreSQL 主库上的插件，而是一个独立运行在备份服务器上的服务。它通过配置文件与主库建立联系，使用 barman 系统用户执行备份任务。在推荐架构中，主库所在主机保留 postgres 系统用户，备份服务器保留 barman 系统用户，二者之间配置 SSH 免密登录。这样做的好处是备份逻辑与数据库实例解耦，即使主库操作系统出现严重故障，备份服务器上的 Barman 仍然可以独立完成恢复操作。

从数据库视角看，Barman 使用两种方式获取数据。第一种是基于 rsync 和 SSH 的文件级备份，它直接读取 PostgreSQL 数据目录和 WAL 目录，适合网络带宽充足且需要细粒度控制文件的场景。第二种是基于流复制协议的在线备份，Barman 调用 pg_basebackup 或使用复制协议连接主库，获取一致性的基础备份。流复制方式不依赖文件系统快照，对主库的侵入更小，也更适合云环境或容器化部署。对于大多数生产环境，推荐使用流复制方式作为基础备份手段，因为它的配置更简洁，并且天然支持在线备份。

WAL 归档同样有两条链路。传统方式是在主库的 postgresql.conf 中设置 archive_command，当每个 WAL 文件写完并切换后，PostgreSQL 会调用该命令把文件推送到 Barman 的 incoming 目录。另一条链路是 Barman 自带的 receive-wal 进程，它通过流复制协议和复制槽实时接收主库产生的 WAL 记录，几乎不需要等待 WAL 切换。两条链路可以并行工作，archive_command 保证已经关闭的 WAL 文件不会丢失，receive-wal 则负责降低最新 WAL 的传输延迟。

二、PostgreSQL 端与 Barman 端的配置

安装 Barman 之前，需要先准备一个独立的备份服务器。以 Debian 或 Ubuntu 为例，可以使用包管理器安装 Barman：

sudo apt update
sudo apt install barman

安装完成后，系统中会创建 barman 用户和 /var/lib/barman 目录。接下来配置 SSH 免密登录，让备份服务器上的 barman 用户可以连接主库的 postgres 用户。这一步不是必须的，但如果使用 rsync 方式归档 WAL 或执行文件级备份，就需要打通 SSH 通道。生成密钥并复制公钥的命令如下：

sudo -u barman ssh-keygen -t rsa -b 4096
sudo -u barman ssh-copy-id postgres@192.168.1.10

主库的 PostgreSQL 需要开启连续归档和复制能力。推荐参数至少包括：

ALTER SYSTEM SET wal_level = replica;
ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM SET archive_command = 'rsync -a %p barman@192.168.1.20:/var/lib/barman/pg/incoming/%f';
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET max_replication_slots = 10;
ALTER SYSTEM SET hot_standby = on;

同时还需要在主库创建一个用于流复制的数据库用户，并在 pg_hba.conf 中允许备份服务器连接。如果使用复制槽，max_replication_slots 必须大于 0。创建用户的 SQL 示例：

CREATE ROLE barman WITH LOGIN SUPERUSER PASSWORD 'your_password';
CREATE ROLE streaming_barman WITH LOGIN REPLICATION PASSWORD 'your_password';

Barman 服务器的核心配置位于 /etc/barman.conf，它负责全局参数。每个被备份的 PostgreSQL 实例单独放在 /etc/barman.d/ 目录下，例如创建一个 pg.conf 文件：

[pg]
description = Main PostgreSQL Server
conninfo = host=192.168.1.10 user=barman dbname=postgres
backup_method = postgres
streaming_conninfo = host=192.168.1.10 user=streaming_barman
streaming_archiver = on
slot_name = barman

这里的 conninfo 用于普通备份和检查，streaming_conninfo 用于流复制接收 WAL。配置完成后运行 barman check pg，Barman 会逐项检查连接、配置、归档目录权限和复制槽状态。所有项都显示为 OK，再开始正式备份。如果某些检查失败，通常会给出明确的错误提示，例如连接被拒绝、复制槽不存在或 SSH 权限不足。

三、启用 WAL 流式归档与执行备份

WAL 流式归档由 Barman 的 receive-wal 进程负责。当配置文件中出现 streaming_archiver = on 时，Barman 会通过 streaming_conninfo 连接主库，并尝试使用 slot_name 指定的复制槽。复制槽可以防止主库在备份服务器暂时不可用时提前回收 WAL 文件，但也意味着主库必须预留足够的磁盘空间来保存未被消费的 WAL。

可以手动启动 WAL 接收进程来观察日志输出：

barman receive-wal pg

该命令会保持前台运行，并持续显示收到的 WAL 文件名。如果一切正常，可以看到类似 Receiving WAL file 000000010000000000000001 的日志。实际生产环境中通常由 Barman 的 cron 任务或 systemd 服务自动拉起 receive-wal。例如可以配置 cron：

*/1 * * * * barman /usr/bin/barman receive-wal pg >/dev/null 2>&1

除了流式归档，主库的 archive_command 仍然建议保留。它可以处理那些因为网络抖动或复制槽暂时断开而未能接收的 WAL 文件。两条链路共同工作时，Barman 会合并来自不同来源的 WAL，不会产生重复数据。使用 barman status pg 可以查看当前归档数量、备份列表和 WAL 流状态。

完成基础配置并确认检查通过后，执行一次完整备份：

barman backup pg

如果使用流复制方式，Barman 会通过 pg_basebackup 建立基础备份，并在备份完成后自动从归档目录和复制槽中收集所需的 WAL 文件。备份命令支持并发和压缩选项，例如 barman backup --jobs 4 --compress pg 可以加快大数据量备份。默认情况下，Barman 会根据保留策略自动清理过期备份，策略参数可以在实例配置中设置，例如 retention_policy = RECOVERY WINDOW OF 7 DAYS 表示至少保留足够恢复到过去 7 天任意时间点的备份和 WAL。

验证备份是否可用，可以执行 barman list-backup pg 查看备份列表，确认状态是否为 DONE。如果状态为 FAILED，优先检查 barman check pg 输出和备份日志，日志通常位于 /var/log/barman/ 目录。常见的失败原因包括复制槽未创建、主库磁盘空间不足、备份服务器目录权限错误等。

四、恢复步骤与常见故障排查

当主库发生故障需要恢复时，Barman 可以在备份服务器上直接展开一份基础备份，并应用 WAL 日志到指定时间点。恢复命令的基本形式如下：

barman recover --target-time '2025-01-20 10:30:00' pg latest /var/lib/postgresql/restore

这条命令会把 pg 实例的最新备份恢复到指定目录，并且应用 WAL 直到 2025-01-20 10:30:00。恢复完成后，目标目录就是一个完整的 PostgreSQL 数据目录。如果需要恢复到最新状态，可以去掉 --target-time 参数。恢复后的数据目录还需要手动修改 postgresql.conf 或使用 pg_ctl 启动数据库。如果原主库已经不存在，建议先复制恢复目录到新服务器，再以 postgres 用户启动。

排查问题时，第一步永远是运行 barman check pg。它会检查连接、复制槽、WAL 归档目录、备份配置等关键项。如果 WAL 归档失败，确认主库的 archive_command 是否能成功执行，可以在主库上手动运行该命令测试。如果流式归档断开，查看 barman status pg 中的 receive-wal 状态，并检查复制槽是否还存在、主库的 max_replication_slots 是否足够、网络端口是否开放。

另一个容易忽略的问题是复制槽积压。Barman 的 receive-wal 进程如果长时间停止，复制槽会阻止主库回收 WAL 文件，最终导致主库磁盘写满。解决方法是尽快恢复 receive-wal 进程，或者在不影响业务的情况下删除失效的复制槽。使用 SQL 可以查看槽的状态：

SELECT slot_name, active, restart_lsn, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag
FROM pg_replication_slots;

如果 lag 值持续增长，说明备份服务器没有及时消费 WAL。需要检查 Barman 服务器上的 receive-wal 服务是否运行、网络带宽是否充足、磁盘空间是否足够。Barman 的 incoming 目录和备份目录都可能占用大量空间，建议配置容量告警，避免归档中断导致恢复窗口缩短。只要确保基础备份和 WAL 流归档同时正常工作，Barman 就能提供可靠的远程备份和恢复能力。

BarmanPostgreSQLWAL归档修改时间：2026-08-29 22:34:18