Barman 3.20.1 介绍与选型指南

Barman 3.20.1（EDB 开源 PostgreSQL 灾备服务器，2026-09-29 发布）版本基准、备份服务器架构与功能特性、官方快速开始流程，及与 pgBackRest/WAL-G/pg_dump 的量化选型对比，全部数据来自官方来源联网查证（查询日期 2026-10-20）。

BarmanBarmanPostgreSQL备份恢复2026/10/20

Barman 3.20.1 介绍与选型指南

目标：说清 Barman 是什么、截至查询日官方最新稳定版本是哪个、核心架构与备份恢复机制怎样，以及在 Barman 与 pgBackRest、WAL-G、pg_dump 之间如何做量化选型。本文为认知篇（A1）：不做本地安装实测，全部版本号、特性与量化数据均来自官方来源联网查证，关键论断随文标注来源与查询日期（2026-10-20）。

一、信息基准

本篇是纯认知与选型文档，先交代「信息从哪来、以哪个版本为基准」，便于读者判断时效并自行复核。

1.1 查询与版本基准

  • 查询日期：2026-10-20。
  • 基准版本：Barman 3.20.1。依据：Barman 官网首页发布横幅显示「Version 3.20.1（29 Sep 2026）」并链接到 GitHub Releases release/3.20.1 标签；官方文档站 docs.pgbarman.org 当前稳定版即为 3.20.1（页面页眉「Barman 3.20.1 documentation」）。
  • 版本背景：3.20.0 于 2026-08-27 发布，是 3.20 大线首个版本；3.20.1 是其 33 天后的安全维护版，修复 CVE-2026-93853（云快照权限提升问题，详见 2.2 节）。
  • 写作方式：不做本地安装实测；所有版本、特性、量化数据以官方来源为准，随文标注来源。

1.2 官方来源清单

信息项官方来源 URL用途
官网首页（版本横幅）https://www.pgbarman.org/确认最新稳定版 3.20.1（2026-09-29）
发布说明 RELNOTEShttps://github.com/EnterpriseDB/barman/blob/release/3.20.1/RELNOTES.md3.20.1/3.20.0 变更清单、CVE、Python 要求
官方文档站https://docs.pgbarman.org/release/3.20.1/架构、前置条件、备份方法演进
架构设计章节https://docs.pgbarman.org/release/3.20.1/user_guide/architectures.html备份服务器选址与 DR 设计建议
前置条件章节https://docs.pgbarman.org/release/3.20.1/user_guide/pre_requisites.html数据库账号与权限要求
GitHub 仓库https://github.com/EnterpriseDB/barman源码、README、许可
星数取证https://img.shields.io/github/stars/EnterpriseDB/barman.svg社区活跃度（shields.io 动态徽章）

二、软件概述

2.1 Barman 是什么

Barman（Backup and Recovery Manager）是 EnterpriseDB（EDB）开源的 PostgreSQL 专用备份与灾难恢复服务器软件：它把「备份服务器」做成一个独立角色，由一台（或多台）Barman 服务器集中管理任意数量 PostgreSQL 服务器的在线热备、WAL 归档、时间点恢复（PITR）与备份目录维护。官网对它的三句话定位是——「为高业务连续性要求的 PostgreSQL 数据库实施灾难恢复」「让 PostgreSQL 在线热备份像点一杯好咖啡一样简单」「在一个地方控制多台服务器」（来源：pgbarman.org 首页，查询日期 2026-10-20）。

基础事实（来源：GitHub 仓库 README.rst，查询日期 2026-10-20）：

  • 语言与形态：Python 编写的服务端工具，以 barman 命令行驱动，依赖 PostgreSQL 客户端工具（pg_basebackup、pg_receivewal、psql）完成实际数据传输。
  • 许可：GNU GPL v3（README「LICENSE: GNU GPL3」）。
  • 维护方：EnterpriseDB（EDB，PostgreSQL 商业发行版厂商），GitHub 仓库 EnterpriseDB/barman（2.13 起从 SourceForge 迁移至此）。
  • 社区规模：GitHub 星数 3.3k（shields.io 动态徽章实测，查询日期 2026-10-20）。

💡 技术拓展：数据库备份按「备份的是什么」分三大类，选型前必须分清——

类型原理代表工具能否 PITR
逻辑备份导出 SQL/数据行，恢复即重放pg_dump/pg_restore、mysqldump否（只能整库回放）
物理备份复制数据目录文件块 + WALBarman、pgBackRest、WAL-G、pg_basebackup是（重放到任意时间点）
存储快照卷/云盘打快照LVM snapshot、EBS Snapshot配合 WAL 可近似

Barman 属于物理备份类，是「备份服务器」形态；pg_dump 是逻辑备份工具，只适合小型库、单表导出与跨版本迁移，不能承担灾备主职。本文选型对比覆盖物理类三强与 pg_dump 对照。

2.2 版本格局：3.20.1 为当前稳定版

Barman 采用小步快跑的大版本节奏（3.x 系列内每几个月一个大线，安全修复随时出 patch）。截至查询日的版本格局（来源：pgbarman.org 首页、GitHub RELNOTES，查询日期 2026-10-20）：

版本状态发布日期关键内容
3.20.1最新稳定版2026-09-29修复 CVE-2026-93853 云快照权限提升；GCS multipart 修复；barman-cloud-wal-restore 完整性修复
3.20.03.20 大线 GA2026-08-27Python 最低版本升至 3.12；S3 SSE-C 支持；GCS 并行上传；云压缩备份恢复流水线并发化；check-archived-wal-range 新命令
3.19.x上一大线维护版2026 年中详见官方 RELNOTES 历史

3.20.1 的安全修复值得单独说明（来源：RELNOTES 3.20.1，查询日期 2026-10-20）：CVE-2026-93853 是一个权限提升问题——此前 Barman 删除快照备份时直接信任备份目录（backup.info）里记录的快照标识，能写坏目录对象的人可诱导 Barman 用自己的云凭据删掉不相关的云快照；3.20.1 起删除前先从云厂商读取元数据核验快照命名约定。使用云快照备份（AWS/Azure/GCP）的部署应优先升级。

3.20.0 的行为变化中，两条对升级影响最大：Python 最低版本要求从 3.8 提高到 3.12（老系统需先升级解释器）与云恢复强制依赖 tar 包。这两条在选择安装方式（apt 发行版包通常已处理好依赖）时是关键输入。

2.3 商业支持与生态位

Barman 由 EDB 开源维护，EDB 同时提供企业级商业支持，这是它与社区驱动项目（pgBackRest）在支持维度的差异。生态位上，Barman 深度绑定 PostgreSQL 生态：云原生 PostgreSQL 管理器 CloudNativePG 的一系列云工具（barman-cloud-backup 等）复用了 Barman 的云备份工具族；PGDG（apt.postgresql.org）为各发行版直接打包 barman，RHEL/Ubuntu 系生产环境可从官方仓库获得与源码同步的稳定版本（来源：PGDG 仓库实测可查询到 3.20.1 包；docs.pgbarman.org 安装章节，查询日期 2026-10-20）。

三、核心架构

3.1 「备份服务器」角色模型

Barman 的核心设计是把备份职责从数据库服务器上剥离：一台独立的 Barman 服务器通过网络远程管理 N 台 PostgreSQL 服务器（Barman 称每台为 a server，即一个配置节）。官方架构章节给出的部署建议是（来源：docs.pgbarman.org/user_guide/architectures.html，查询日期 2026-10-20）：

  • 把 Barman 装在专用服务器上，不要与 PostgreSQL 共享存储（否则备份与库一起损毁，灾备失去意义）；
  • Barman 服务器与数据库服务器不宜相距过远（控制备份/恢复时长），但应在 disaster recovery 设计里评估同机房/同城/异地的多种拓扑并做 SPOF（单点故障）与成本收益分析；
  • 把 Barman 纳入基础设施监控，并先测试再上生产。

一次 Barman 管理会话里的两类连接与两类数据流：

连接/数据流走什么用途
conninfo（管理连接）普通 SQL 连接备份起止协调（pg_backup_start/stop）、目录信息采集
streaming_conninfo（流复制连接）WAL 流复制协议pg_receivewal 实时接收 WAL、pg_basebackup 传输基线
基础备份数据流pg_basebackup（backup_method = postgres）或 rsync over SSH（backup_method = rsync）物理基线副本落盘
WAL 数据流流复制槽 + pg_receivewal，或 PG archive_command 推送持续归档，支撑 PITR

💡 技术拓展：WAL 归档到备份服务器有两条路线，Barman 两种都支持——

路线参数原理特点
文件归档archiver = onPG 的 archive_command 主动推 WAL 到 Barman依赖库端推送，库挂了尾部 WAL 可能丢
流归档streaming_archiver = onBarman 用 pg_receivewal + 复制槽主动拉无需改库端 archive_command，RPO 更低，3.x 推荐方式

两种可并存（archiver = on + streaming_archiver = on），Barman 会自动去重。本文选型描述以流归档为主线。

3.2 备份方法演进：rsync → streaming → 块级增量

Barman 官方文档对备份方法的演进表述（来源：docs.pgbarman.org/user_guide/backup.html，查询日期 2026-10-20）：

  • 2.0 之前：仅 rsync（标准备份与文件级增量）；
  • 2.0 起：引入 streaming 备份（backup_method = postgres，底层 pg_basebackup，无需 SSH）；
  • 3.11 起：通过 streaming 连接支持块级增量备份（block-level incremental，基于 PG17 的 pg_basebackup --incremental 与备份清单机制）。

三种备份方法对比：

方法传输通道是否需要 SSH增量支持适用
postgres（流式）pg_basebackup 流复制否3.11+ 块级增量现代默认选择
rsyncrsync over SSH是（免密 SSH）文件级增量（复用上次备份未变文件）老版本 PG、需要表空间映射细粒度控制
local-to-cloud/云快照云 API/快照否按云机制对象存储/云盘快照场景

3.3 备份目录（Catalog）与保留策略

每个 PostgreSQL 服务器在 Barman 本地有一个独立目录（/var/lib/barman/<server>/base），其下按 YYYYMMDDTHHMMSS 命名存放各次基础备份，backup.info 记录 LSN、时间线、WAL 范围等元数据；WAL 归档在 <server>/wals。官网把备份目录称为 Barman 最有魅力的特性之一——同一目录下可以 list、keep、delete、verify 多份全量备份（来源：pgbarman.org 首页，查询日期 2026-10-20）。保留策略支持两种口径：

  • retention_policy = RECOVERY WINDOW OF N DAYS：保留足以恢复到最近 N 天内任意时刻的备份链；
  • retention_policy = REDUNDANCY N：保留最近 N 份全量备份。

barman keep 可对指定备份打长期保留标记（如月度归档点），不受策略清理影响——这是审计与合规场景的常用机制。

四、功能特性

4.1 特性总表

特性说明引入/现状（来源：RELNOTES 与官方文档，查询日期 2026-10-20）
在线热备物理基线备份，业务不中断核心能力
PITR恢复到任意时间点/LSN/事务核心能力（基于 WAL 重放）
WAL 流归档pg_receivewal + 复制槽实时拉取2.x 起，3.x 推荐
块级增量备份streaming 连接增量，仅传变更块3.11 起
多服务器集中管理单台 Barman 管理多台 PG（每台一个配置节）核心能力
保留策略RECOVERY WINDOW / REDUNDANCY长期能力
备份校验barman check / check-backup 一致性验证长期能力
云对象存储备份barman-cloud-backup 等工具族：AWS S3、Azure Blob、GCS持续增强：3.20.0 加 S3 SSE-C、GCS 并行上传
云盘快照备份AWS EBS/Azure/GCP 快照备份与按快照恢复3.x 增强，3.20.1 修复快照删除 CVE
地理冗余Barman 服务器之间同步备份目录（sync-info）长期能力
Hook 脚本备份/归档前后置脚本与重试脚本长期能力
快速校验命令check-archived-wal-range 检测 WAL 归档缺口3.20.0 新增
进程管理terminate-process 终止后台接收进程（receive-wal --stop 已弃用）3.20.0 起
非活跃服务器管理active = false 的服务器目录仍可查询与维护3.20.0 行为统一

4.2 与恢复速度相关的两个设计点

  • --wait 备份收尾：并发备份场景下备份完成后状态先为 WAITING_FOR_WALS，Barman 会等所有必需 WAL 归档到位后自动转 DONE；备份命令加 --wait 可在备份内等待（避免用 barman backup 输出里的提示手工补跑）。
  • 恢复流水线并发化：3.20.0 把「云上压缩备份」的下载、解压、解包三阶段改为并发重叠执行，官方称可明显缩短恢复时间（来源：RELNOTES 3.20.0，查询日期 2026-10-20）；随之 tar 成为云恢复的必需依赖。

五、快速开始（官方最小流程转述）

以下为官方文档 Quick start / Pre-requisites 章节的最小可用流程转述（来源：docs.pgbarman.org/release/3.20.1/user_guide/，查询日期 2026-10-20），用于建立认知；完整的 Ubuntu 22.04 安装实测见本专栏 B1 篇（文末参考链接）。

  1. 准备两台主机：pghost（跑 PostgreSQL）与 barmanhost（跑 Barman）。
  2. 在 pghost 建专用账号（官方推荐用户名 barman）：
    • 简化路径：createuser -s -P barman（超级用户，实验/私有网络可用）；
    • 最小权限路径：createuser -P barman 后授予 GRANT EXECUTE ON FUNCTION pg_backup_start(text, boolean) TO barman; 与 GRANT EXECUTE ON FUNCTION pg_backup_stop(boolean) TO barman;，另建 barman_streaming 复制账号（REPLICATION 权限）。
  3. 在 barmanhost 安装 Barman 并编辑 /etc/barman.d/<server>.conf，写明 conninfo、streaming_conninfo、backup_method = postgres、streaming_archiver = on、slot_name。
  4. 初始化：barman cron（创建复制槽、启动 WAL 接收进程）→ barman check <server>（全 OK 后）→ barman backup <server> 完成首次全量 → barman list-backup <server> 查看 → barman recover <server> <backup_id> <目标目录> 恢复。

六、适用场景与限制

6.1 适合用 Barman 的场景

  • 多实例集中灾备：企业内有 3~30 台 PostgreSQL，希望一台备份服务器统一备份、统一保留策略、统一监控——Barman 的「一配置节一服务器」模型就是为此设计；
  • PITR 硬需求：误删表/误更新后需恢复到秒级时间点；
  • 异地容灾：利用地理冗余把备份目录同步到第二机房；
  • 对象存储归档：用 barman-cloud-* 把备份与 WAL 推 S3/Azure/GCS，本地零备份存储；
  • EDB 支持体系：已有 EDB 商业支持合同，希望灾备工具同源。

6.2 限制与注意

  • 仅 PostgreSQL：不支持 MySQL/Oracle 等其他数据库；
  • GPL-3.0：对嵌入商业产品分发的场景不如宽松许可友好（运维使用无影响）；
  • Python 3.12+（3.20 起）：老旧操作系统 pip 路线需先升级解释器（发行版包路线不受影响，如 PGDG 包自带依赖处理）；
  • 备份服务器自身是基础设施：需要独立容量规划（官方建议按集群大小 × 备份频率 × WAL 日增量 × 保留窗口估算）与监控，否则是新的 SPOF；
  • 首轮全量备份耗时：基线备份走网络全量传输（本文实测 29.5 MiB 小库也需计费到分钟级；大库需评估带宽与 pg_basebackup 的 I/O 影响）。

七、同类选型对比（含量化维度）

7.1 候选与数据来源

对比对象：Barman、pgBackRest、WAL-G（物理备份三强）与 pg_dump（逻辑备份基线）。星数统一用 shields.io 动态徽章取证（查询日期 2026-10-20），版本与特性以各项目官方文档为准。

7.2 量化对比总表

维度Barman 3.20.1pgBackRestWAL-Gpg_dump
GitHub 星数（shields.io，2026-10-20）3.3k4.5k4.3k—（PostgreSQL 主仓库组件）
开发/维护方EnterpriseDB社区（Crunchy Data 等参与）社区（开源协作）PostgreSQL Global Development Group
许可GPL-3.0PostgreSQL License（宽松）Apache-2.0PostgreSQL License
实现语言PythonCGoC
部署形态独立备份服务器（pull 集中管理）repo 主机 + 数据库主机装 agent单二进制 agent（push）数据库主机本地工具
多服务器集中管理原生（每 PG 一个配置节，统一 check/backup）一个 repo 多 stanza，集中度中等弱（每台独立推送，需外层编排）无
备份类型物理（pg_basebackup/rsync/云快照）物理（自有协议）物理 + 可选逻辑逻辑
增量备份块级增量（3.11+ streaming）；rsync 文件级块级增量 + differentialdelta 增量无
压缩gzip/bzip2/pigz 等（rsync 路线）多级压缩：lz4/zstd/gzip/bzip2 等lz4/zstd/s2/brotli 等无（可管道 gzip）
对象存储barman-cloud-*（S3/Azure/GCS，3.20 支持快照与 SSE-C）S3/Azure/GCS/SFTP 原生S3/Azure/GCS/Swift/SSH 等最广无
PITR支持支持支持不支持
远程恢复支持（recover 指定目标主机目录）支持需目标机装 WAL-G本机恢复
门槛中（理解配置节/两种归档）中（repo/ stanza 概念）低（环境变量+单命令）极低
典型规模中小集群数量多、集中管控诉求大型库、极致恢复速度云原生/K8s/多数据库微小库/单表导出

关键差异解读：三强的物理备份能力都覆盖「热备 + PITR + 云存储」，真正的分野在运维模型——Barman 是唯一把「备份服务器 + 多实例集中管理 + 备份目录」做成产品核心的（pgBackRest 的 stanza 管理集中在 repo 侧但每库仍需装 agent；WAL-G 是纯 agent 无中心目录）；pgBackRest 用 C 实现、压缩与并行恢复性能口碑最好，适合超大库；WAL-G 单二进制 + Go 交叉编译友好，云原生/K8s 集成最多；pg_dump 只作逻辑备份基线，不承担灾备。

「如果……则……」建议：多实例集中灾备、想要一台服务器统一管 N 台 PG 且保留策略/校验/目录开箱即用 → Barman；单库数百 GB~TB 级、追求最快恢复与最强压缩 → pgBackRest；已在 Kubernetes/对象存储体系、需要 Go 生态与最小侵入 → WAL-G；仅导出单表/小库做迁移 → pg_dump 足矣。

7.3 社区活跃度补充

  • Barman 3.3k 星在 PostgreSQL 备份工具中虽低于 pgBackRest/WAL-G，但其发布节奏稳定（3.20.0 → 3.20.1 间隔 33 天，安全响应及时）且由 EDB 商业公司长期维护——星数低更多反映「备份服务器形态的受众较窄」，而非维护停滞（综合 GitHub Releases 与 RELNOTES 观感，查询日期 2026-10-20）。
  • 三者均有生产级使用背书；PGDG 官方 apt 仓库直接收录 barman 与 pgbackrest 包，发行版集成度均高。

八、参考链接