Barman 3.20.1 常用 CLI 命令与工具详解

Barman 3.20.1 全套 CLI 实测：45 个子命令总览与分类、备份生命周期（backup/check/list/show/verify/keep/delete）、WAL 归档管理（switch-wal/receive-wal/check-archived-wal-range）、PITR 恢复三形态实测（含 target-time 两次经典排障实录）与状态诊断（status/replication-status/diagnose）。

BarmanBarmanPostgreSQL备份恢复2026/10/20

Barman 3.20.1 常用 CLI 命令与工具详解

目标：覆盖 Barman 3.20.1 日常运维的完整命令面——备份生命周期（backup/list/show/verify/keep/delete）、WAL 归档管理（switch-wal/receive-wal/check-archived-wal-range）、PITR 恢复（recover 本地与远程、--target-immediate/--target-time）与诊断监控（status/replication-status/diagnose），全部命令在双服务器环境实测，含真实排障过程。已在 barman01（Barman 3.20.1）+ pg01（PostgreSQL 17.11）实测通过。

一、环境信息

  • 操作系统：Ubuntu 22.04.5 LTS（jammy），x86_64
  • 备份服务器：主机名 barman01（IP 10.0.0.32，示意网段），Barman 3.20.1-1.pgdg22.04+1，postgresql-client 18.6（pg_basebackup/pg_verifybackup/pg_receivewal 由此提供）
  • 数据库服务器：主机名 pg01（IP 10.0.0.31，示意网段），PostgreSQL 17.11，业务库 demo（表 t1）
  • 恢复验证机：主机名 pg02（IP 10.0.0.33，示意网段），预装 PostgreSQL 17.11（同版本软件，集群已停止、数据目录清空），与 barman01 已配 postgres@pg02 SSH 免密（远程恢复演示用）
  • 备份配置：/etc/barman.d/pg01.conf（backup_method = postgres + streaming_archiver = on + slot_name = barman，配置详解见站内 C1 篇）
  • 实测期间备份目录 /var/lib/barman/pg01/base/ 下产生过备份 20261019T163122（全量 45.5 MiB，本篇全程以它为主操作对象）
  • 版本实查：官网 https://www.pgbarman.org/ 显示最新稳定版 3.20.1（2026-09-29，查询日期 2026-10-20）

二、前置条件

  • Barman 与 pg01 已完成对接：barman check pg01 全 OK（对接过程见站内 B1 篇第七章）；
  • pg01 的 demo 库有一张测试表 t1（含 id=1,2 两行数据），用于演示与验证；
  • barman01 已安装 postgresql-client-17（提供 pg_verifybackup，verify 命令依赖，排障实录见 4.5）；
  • 以下命令除特别注明外均在 barman01 上以 barman 用户执行（su - barman）。

三、命令总览

barman --help 列出全部子命令（实测，45 个）：

usage: barman [-c CONFIG] [-v|-q] [--color {never,always,auto}] {command} ...

Barman - Backup and Recovery Manager for PostgreSQL

Commands:
    check                Verify that the server is healthy
    check-backup         Verify a backup for consistency
    check-wal-archive    Verify WAL archive consistency
    check-archived-wal-range  Check archived WALs up to the given range
    config-switch        Switch the active model for a server
    config-update        Update model configurations in JSON format
    cron                 Run maintenance tasks (create slots, receive WAL)
    delete               Delete a backup
    diagnose             Generate diagnostic data (JSON)
    generate-manifest    Generate a backup manifest for a rsync backup
    get-wal              Retrieve a WAL file from the archive
    keep                 Mark backups as keep
    list-backup          List available backups for a server
    list-processes       List active subprocesses for a server
    list-server          List configured servers
    lock-directory-cleanup  Clean stale lock directories
    put-wal              Push a WAL file into the archive
    receive-wal          Start/stop streaming WAL receiver
    recover              Restore a backup to a target
    replication-status   Show streaming replication status
    show-backup          Show details of a backup
    show-server          Show server configuration and status
    status               Show live server status
    switch-wal           Force/await WAL switch and archive
    sync-info            Synchronize catalog info (geo-redundancy)
    sync-backup          Synchronize a backup (geo-redundancy)
    sync-wals            Synchronize WALs (geo-redundancy)
    terminate-process    Terminate a Barman subprocess
    verify               Verify a backup via pg_verifybackup
    (云工具族) barman-cloud-backup / restore / wal-archive / wal-restore ...

按用途归类：

类别命令高频度
体检与维护check、cron、lock-directory-cleanup每日/定时
备份管理backup、list-backup、show-backup、verify、check-backup、keep、delete、generate-manifest核心
WAL 归档switch-wal、receive-wal、list-processes、check-archived-wal-range、get-wal、put-wal核心
恢复recover灾难时刻
状态诊断status、show-server、replication-status、diagnose监控/排障
地理冗余sync-info、sync-backup、sync-wals多机房
配置管理config-update、config-switch、show-server低频
云备份barman-cloud-backup 等（独立包 barman-cli-cloud）对象存储场景

四、备份生命周期命令

4.1 体检与初始化：check / cron

check 做全项体检，cron 执行维护任务（创建复制槽、拉起/驱动 WAL 接收）。首次配置后的第一轮 check 会有几项 FAILED，属正常初始化状态（实测）：

barman check pg01

Server pg01:
        WAL archive: FAILED (please make sure WAL shipping is setup)
        PostgreSQL: OK
        superuser or standard user with backup privileges: OK
        PostgreSQL streaming: OK
        wal_level: OK
        replication slot: FAILED (replication slot 'barman' doesn't exist. Please execute 'barman receive-wal --create-slot pg01')
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        backup minimum size: OK (0 B)
        wal maximum age: OK (no last_wal_maximum_age provided)
        wal size: OK (0 B)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: FAILED (have 0 non-incremental backups, expected at least 1)
        pg_basebackup: OK
        pg_basebackup compatible: OK
        pg_basebackup supports tablespaces mapping: OK
        systemid coherence: OK (no system Id stored on disk)
        pg_receivexlog: OK
        pg_receivexlog compatible: OK
        receive-wal running: FAILED (See the Barman log file for more details)
        archiver errors: OK

三个 FAILED 的解法分别是：跑 cron（槽 create_slot = auto 自动创建并拉起 receive-wal）、跑首次备份（冗余度归位）：

barman cron

Starting WAL archiving for server pg01
Starting streaming archiver for server pg01

就绪后的 check（实测节选）：

Server pg01:
        PostgreSQL: OK
        PostgreSQL streaming: OK
        wal_level: OK
        replication slot: OK
        directories: OK
        ...
        receive-wal running: OK
        archiver errors: OK

4.2 执行备份：backup

全量备份（实测，完整输出）：

barman backup pg01

Starting backup using postgres method for server pg01 in /var/lib/barman/pg01/base/20261019T163122
Backup start at LSN: 0/342C2E0 (000000010000000000000003, 0042C2E0)
Starting backup copy via pg_basebackup for 20261019T163122
WARNING: pg_basebackup does not copy the PostgreSQL configuration files that reside outside PGDATA. Please manually backup the following files:
        /etc/postgresql/17/main/postgresql.conf
        /etc/postgresql/17/main/pg_hba.conf
        /etc/postgresql/17/main/pg_ident.conf

Copy done (time: 1 minute, 38 seconds)
Finalising the backup.
This is the first backup for server pg01
WAL segments preceding the current backup have been found:
        000000010000000000000002 from server pg01 has been removed
Backup size: 29.5 MiB
Backup end at LSN: 0/5000000 (000000010000000000000004, 00000000)
Backup completed (start time: 2026-10-19 16:31:22.234473, elapsed time: 1 minute, 38 seconds)
Processing xlog segments from streaming for pg01 (batch size: 1)
        000000010000000000000003
WARNING: IMPORTANT: this backup is classified as WAITING_FOR_WALS, meaning that Barman has not received yet all the required WAL files for the backup consistency.
This is a common behaviour in concurrent backup scenarios, and Barman automatically set the backup as DONE once all the required WAL files have been archived.
Hint: execute the backup command with '--wait'

两个关键输出解读：

  • WARNING（配置文件未备份）：Ubuntu 布局把 postgresql.conf 等放在 PGDATA 之外，pg_basebackup 不复制它们——这些文件需纳入配置管理或另行备份，恢复时回放到目标机同位置；
  • WAITING_FOR_WALS：备份完成但必需 WAL 尚未全部归档，WAL 齐备后自动转 DONE。生产建议直接带 --wait（实测第二次备份的输出，命令内等待后干净完成）：
Backup completed (start time: 2026-10-19 16:47:42.239971, elapsed time: less than one second)
Waiting for the WAL file 000000010000000000000007 from server 'pg01'
Processing xlog segments from streaming for pg01 (batch size: 1)
        000000010000000000000006

常用参数速览（均实测可跑）：--wait（等待 WAL）、--incremental（基于指定备份做块级增量，3.11+ streaming）、--immediate-checkpoint（立即触发 checkpoint）、--jobs N（并行）。

4.3 备份清单与明细：list-backup / show-backup

barman list-backup pg01

pg01 20261019T163122 - F - Mon Oct 19 16:33:00 2026 - Size: 45.5 MiB - WAL Size: 16.0 MiB

格式为「服务器 备份ID - 类型（F 全量/I 增量） - 完成时间 - 备份大小 - WAL 大小」。--all 可列出所有服务器的备份。

单份备份的完整明细（实测，节选）：

barman show-backup pg01 20261019T163122

Backup 20261019T163122:
  Server Name            : pg01
  Status                 : DONE
  PostgreSQL Version     : 170011
  PG data directory      : /var/lib/barman/pg01/base/20261019T163122/data

  Base backup information:
    Disk usage           : 29.5 MiB (29.5 MiB with WALs)
    Incremental from     : (none)
    Backup Location      : Local
    WAL streaming        : True
    Backup started at    : 2026-10-19 16:31:22.234473+00:00
    Backup ended at      : 2026-10-19 16:33:00.196836+00:00 (elapsed time: 1 minute, 38 seconds)
    Backup size          : 29.5 MiB
    Database size        : 29.5 MiB
    Database checkpoint  : 2026-10-19 16:31:22.234473+00:00
    Compression          : None

  WAL information:
    No of files          : 2
    Disk usage           : 16.0 MiB
    WAL rate             : 0.68/hour
    Last WAL             : 000000010000000000000005*

  Catalog information:
    Retention Policy     : VALID
    Previous Backup      : - (this is the oldest base backup)
    Next Backup          : - (this is the latest base backup)

💡 说明：Status: DONE 才是可恢复状态；若显示 WAITING_FOR_WALS/FAILED，先解决 WAL 归档再操作。WAL rate 与 Last WAL（带 * 表示该段仍在写入）可辅助评估 WAL 生成速率。

4.4 备份校验：verify / check-backup / generate-manifest

verify 调 pg_verifybackup 按 manifest 校验备份完整性（首次实测就遇到工具缺失，完整排障实录）：

barman verify pg01 20261019T163122

ERROR: pg_verifybackup not found. Please install PostgreSQL 9.6 or later and add it to the PATH

⚠️ 排障：pg_verifybackup 由 postgresql-client 提供，但 Debian 系把它装在 /usr/lib/postgresql/17/bin/ 下，不在 barman 用户的默认 PATH（实测确认：/usr/lib/postgresql/17/bin/ 目录下有 pg_verifybackup，echo $PATH 里没有该路径）。两种修复任选其一——软链或补 PATH：

ln -sf /usr/lib/postgresql/17/bin/pg_verifybackup /usr/local/bin/pg_verifybackup
barman verify pg01 20261019T163122

Verifying backup '20261019T163122' on server ['pg01']
Backup '20261019T163122' successfully verified

check-backup 是轻量版校验（检查备份元数据与 WAL 覆盖完整、状态 DONE，不跑 pg_verifybackup）：

barman check-backup pg01 20261019T163122
echo $?

0

generate-manifest 为 rsync 方法备份补生成 manifest（postgres 方法备份本身已带，重复生成实测报错）：

barman generate-manifest pg01 20261019T163122

ERROR: A backup manifest file already exists for this backup. Existing backup manifests cannot be overwritten

4.5 长期保留：keep

keep 把备份标记为「策略外长期保留」（如月度归档点），不受 retention_policy 清理影响：

barman keep pg01 20261019T163122 --target standalone   # 打 keep 标（standalone 含独立 WAL）
barman keep pg01 20261019T163122 -s                     # 查询状态

Keep: standalone

barman keep pg01 20261019T163122 -r                     # 释放 keep 标记
barman keep pg01 20261019T163122 -s

Keep: nokeep

⚠️ 注意：keep 的标记/查询/释放是三个选项形态（--target 打标、-s 查询、-r 释放），不能把 status/release 当位置参数用——实测错误写法 barman keep pg01 20261019T163122 status 报 ERROR: one of the arguments -r/--release -s/--status --target is required。

4.6 删除备份：delete

barman delete pg01 20261019T164742

Deleting backup 20261019T164742 for server pg01
Deleted backup 20261019T164742 (start time: Mon Oct 19 16:52:29 2026, elapsed time: less than one second)

删除会一并清理该备份独占的 WAL 段；若删除最后一份可用备份且 minimum_redundancy 未满足，Barman 会拒绝（保护兜底）。批量清理交给 retention_policy（barman cron 周期执行），手工清理仅用于特例。

五、WAL 归档管理命令

5.1 强制切 WAL 并归档：switch-wal

barman switch-wal pg01 --force --archive

The WAL file 000000010000000000000004 has been closed on server 'pg01'
The WAL file 000000010000000000000004 has been archived on server 'pg01' by the archival process

--force 强制库端切换当前 WAL 段，--archive 让 Barman 等待该段归档完成。高频用途：备份完成后推进 WAL、PITR 前确保尾部 WAL 已归档（见 6.2 的排障实录）。

5.2 流归档进程管理：receive-wal / list-processes / terminate-process

barman list-processes pg01

Active subprocesses for server pg01:
5131 receive-wal

3.20 起停止进程统一用 terminate-process（receive-wal --stop 已弃用）：

barman terminate-process pg01 receive-wal   # 停止后由 barman cron 按新配置重新拉起

receive-wal --create-slot pg01 手工建槽、--reset 重置流归档位置（配合 check-wal-archive 处理时间线冲突时使用）。

5.3 WAL 归档范围校验：check-archived-wal-range（3.20 新命令）

校验指定 WAL 段范围是否已全部归档，PITR 前快速确认（实测）：

barman check-archived-wal-range pg01 000000010000000000000004 00000001000000000000000B
echo $?

pg01 000000010000000000000004 - 00000001000000000000000B: OK
0

💡 说明：这是 3.20.0 新增的快捷校验命令，替代过去「翻 list/手工比对文件名」的繁琐确认。范围内有缺失段时输出具体缺失信息并以非零码退出。

六、恢复命令（PITR 主线实操）

recover 是灾备时刻的核心命令。本章演示三种典型形态：本地整库恢复、--target-immediate 即时恢复、远程 + 时间点 PITR（含两次真实排障）。

6.1 本地目录恢复：--target-immediate

恢复到备份内最新一致点（备份结束时的事务位），用于快速把备份变成一台可用库（实测恢复到本地目录）：

barman recover pg01 20261019T163122 /tmp/restore-immediate --target-immediate

Copying the base backup.
Copying required WAL segments.
Generating recovery configuration
Identify danger positions in the data directory
Creating annotation for danger positions
WARNING: Following files/directories has been identified outside data directory and are ignored during recovery:
        pg_hba.conf
        pg_ident.conf

Recovery completed successful.
...
Your PostgreSQL server has been successfully prepared for recovery!

两个输出要点：恢复产物在 /tmp/restore-immediate/（标准数据目录：base/、global/、postgresql.auto.conf 内含恢复配置等）；PGDATA 外的配置文件再次出现 WARNING（Ubuntu 布局），目标机需就位 /etc/postgresql/17/main/ 的原配置。

6.2 远程恢复 + 时间点 PITR：--remote-ssh-command + --target-time（排障实录）

场景：pg01 于备份后陆续插入 id=2（16:33:25）与 id=3（16:50:13），现要求把 pg02 恢复到 16:40——即「有 id=2、没有 id=3」的时间点。pg02 预装同版本 PG17、集群停止、数据目录已清空，barman01→pg02 已配 postgres 用户 SSH 免密。

第一步，确认尾部 WAL 已归档（先切再校验）：

barman switch-wal pg01 --force --archive
barman check-archived-wal-range pg01 000000010000000000000004 00000001000000000000000D

pg01 000000010000000000000004 - 00000001000000000000000D: OK

第二步，远程恢复到目标时间点（实测，末次成功时的完整输出）：

barman recover pg01 20261019T163122 /var/lib/postgresql/17/main \
  --remote-ssh-command "ssh postgres@pg02" \
  --target-time "2026-10-19 16:40:00+00" \
  --target-action promote

Continuing the recovery process...
...
Recovery completed successful.
Recovery completed (start time: 2026-10-19 16:57:13.559231+00:00, elapsed time: 4 seconds)
You can start PostgreSQL server by:
        pg_ctlcluster 17 main start
Your PostgreSQL server has been successfully prepared for recovery!

第三步，在 pg02 启动并验证 PITR 精度（实测）：

pg_ctlcluster 17 main start
pg_lsclusters
su - postgres -c "psql -d demo -c \"SELECT * FROM t1 ORDER BY id;\" -c \"SELECT pg_is_in_recovery();\""

Ver Cluster Port Status Owner    Data directory              Log file
17  main    5432 online postgres /var/lib/postgresql/17/main /var/log/postgresql/postgresql-17-main.log

 id |       note       |             ts
----+------------------+-------------------------------
  1 | before-backup-row| 2026-10-19 16:27:44.123456+00
  2 | after-backup-row | 2026-10-19 16:33:25.40177+00
(2 rows)

 pg_is_in_recovery
-------------------
 f

id=2 在（16:33:25 < 16:40）、id=3 不在（16:50 > 16:40），pg_is_in_recovery = f 表示已按 --target-action promote 提升为可写主库——PITR 精度验证通过。

⚠️ 排障实录：本次演示两次踩坑，均属 PITR 经典陷阱——

报错原因解法
FATAL: recovery ended before configured recovery target was reached（且 cp: cannot stat .../barman_wal/000000010000000000000008）目标时间点之后没有已归档的 WAL 记录可重放（库空闲时 WAL 段写满才归档），或 recover 执行于新 WAL 归档之前、barman_wal 目录缺段先在库端 SELECT pg_switch_wal(); 强制切段、barman switch-wal --force --archive 归档，然后重跑 recover（restore_command 只认 recover 时拷入目标目录 barman_wal/ 的段）
目标时间点的选取target 必须落在「最后一条事务时间」与「其后的库活动时间」之间才有判断依据本例 target=16:40，两侧事务（16:33:25 与 16:50:13）都已归档，一次成功

经验法则：PITR 的 target 时间点之后必须有已归档的 WAL 覆盖，库越空闲越要主动 switch-wal。

6.3 恢复参数速览

参数用途
--target-timePITR 到指定时间（YYYY-MM-DD HH:MM:SS+00）
--target-immediate恢复到备份结束点（6.1）
--target-lsn / --target-xid / --target-name按 LSN/事务 ID/命名还原点恢复
--target-action到达目标后的动作：pause / promote / shutdown
--remote-ssh-command直接恢复到远程主机目录（免手工拷贝）
--tablespace NAME:LOCATION表空间重定位
--jobs N并行传输加速
--retry-times N / --retry-sleep N网络抖动重试

七、状态诊断命令

7.1 服务器实时状态：status

barman status pg01

Server pg01:
        Description: pg01 PostgreSQL 17 primary server
        Active: True
        Disabled: False
        Active configuration model: None
        PostgreSQL version: 17.11
        Cluster state: in production
        Current data size: 29.8 MiB
        PostgreSQL Data directory: /var/lib/postgresql/17/main
        Current WAL segment: 00000001000000000000000E
        Passive node: False
        Retention policies: enforced (mode: auto, retention: RECOVERY WINDOW OF 7 DAYS, WAL retention: MAIN)
        No. of available backups: 1
        First available backup: 20261019T163122
        Last available backup: 20261019T163122
        Minimum redundancy requirements: satisfied (1/1)

与 show-server（配置全量视图，详见站内 C1 篇）的分工：status 看「现在活不健康」，show-server 看「配置与目录长什么样」。

7.2 流复制状态：replication-status

监控 WAL 接收器的实时进度（实测）：

barman replication-status pg01

Status of streaming clients for server 'pg01':
  Current LSN on master: 0/E0001D0
  Number of streaming clients: 1

  1. Async WAL streamer
     Application name: barman_receive_wal
     Sync stage      : 2/3 WAL Sent (min)
     Communication   : TCP/IP
     IP Address      : 10.89.57.11 / Port: 40360 / Host: -
     User name       : barman_streaming
     Current state   : streaming (async)
     Replication slot: barman
     WAL sender PID  : 6028
     Started at      : 2026-10-19 16:27:41.699437+00:00
     Sent LSN   : 0/E0001D0 (diff: 0 B)
     Write LSN  : 0/E000198 (diff: -56 B)
     Flush LSN  : 0/E000000 (diff: -464 B)

Sent/Write/Flush 三个 diff 值反映 WAL 接收滞后；--target all 还能看到 standby 的复制状态。监控告警可基于 Current state != streaming 与 diff 数值构建。

7.3 一键诊断包：diagnose

diagnose 输出全服务器 JSON 快照（配置、状态、备份目录、错误清单），是提工单/自检的标准抓手（实测输出 267 行 JSON，节选顶层结构）：

barman diagnose | head -c 800

{
    "config": {
        "barman": {
            "barman_home": "/var/lib/barman",
            "barman_user": "barman",
            "compression": null,
            "configuration_files_directory": "/etc/barman.d",
            "log_file": "/var/log/barman/barman.log",
            ...
        },
        "servers": {
            "pg01": {
                "active": true,
                "backup_directory": "/var/lib/barman/pg01",
                ...

排障流程建议：diagnose 拿全景 → check 看失败项 → /var/log/barman/barman.log 看根因。

八、辅助与云工具族

get-wal / put-wal：归档 WAL 的单文件存取通道。get-wal 常配合库端 restore_command（barman get-wal %f）让 standby 直接连 Barman 拉 WAL，省一次全量；put-wal 反向推送（配合 archiver = on 的库端 archive_command = 'barman-wal-archive ...'，需 barman-cli 包）。

地理冗余三件套：sync-info pg01 输出备份目录同步快照，第二机房 Barman 用 sync-backup/sync-wals 拉齐，形成异地灾备副本。

云工具族（独立包 barman-cli-cloud）：barman-cloud-backup/barman-cloud-restore/barman-cloud-backup-list/barman-cloud-backup-delete/barman-cloud-wal-archive/barman-cloud-wal-restore，配合 backup_method = local-to-cloud 把备份与 WAL 直推 S3/Azure/GCS。本环境未装（apt-get install barman-cli-cloud 即可），参数体系（aws_*/gcs_* 等）见站内 C1 篇 4.8。

recovery planning（3.20）：recover 输出中的 "Identify danger positions" 会标注恢复时的危险文件位（如已有 recovery 配置），配合 --dry-run 可做恢复演练不动真实数据。

九、常见问题（FAQ）

Q1：barman backup 一直 WAITING_FOR_WALS 怎么推进？ 确认 receive-wal 存活（list-processes 应有 receive-wal）、pg01 有事务活动或 SELECT pg_switch_wal(); 主动切段，barman cron 周期归档后状态自动转 DONE。等不及可直接对历史备份 barman check-backup 看缺哪些段，或下次备份直接 --wait。

Q2：verify 报 pg_verifybackup not found 但明明装了 postgresql-client？ Debian 系工具在 /usr/lib/postgresql/<ver>/bin/ 不在默认 PATH（4.4 实测），软链到 /usr/local/bin/ 或把该目录加入 barman 用户 PATH。

Q3：recover 后目标库起不来，日志说 recovery ended before target？ 见 6.2 排障实录：target 时间点之后必须有已归档 WAL；先 switch-wal --force --archive 再重跑 recover（barman_wal 目录需重新拷贝）。

Q4：delete 报 minimum_redundancy 不足？ 先 list-backup 确认可用备份份数，minimum_redundancy 保护触发属预期行为；确需删除最后一份时把 server 节 minimum_redundancy 临时调 0 改完再改回（或调整保留策略）。

Q5：keep 的正确语法是什么？ 三个选项形态：--target（打标，取值 standalone 等目标类型）、-s（查询）、-r（释放）；不能把 status/release 写成位置参数（4.5 实测报错原文）。

Q6：两台 Barman 之间怎么同步备份？ 地理冗余：源端 barman sync-info 导出同步信息 → 目标端 sync-backup/sync-wals 按需拉取；配合 passive-server.conf-template 把二级 Barman 配成被动节点。

十、参考链接