由 John Doe 四月 30, 2026
针对 PostgreSQL 的备份和恢复管理，社区有多种优秀的开源工具可供选择。这些工具在增量备份实现、并行处理能力、云存储（S3/对象存储）支持以及架构设计上各有侧重。
目录
核心特性对比表
| 特性 / 工具 | pg_basebackup | pg_rman | pg_probackup | pgBackRest | Barman |
|---|---|---|---|---|---|
| 工具定位 | PG 官方原生基础备份工具 | 早期广受欢迎的第三方备份管理工具 | 专为大规模数据和高级增量备份设计的工具 | 企业级、支持海量数据的标杆备份工具 | 集中式、多节点数据库备份与灾备管家 |
| 全量备份 | 支持 | 支持 | 支持 | 支持 | 支持 |
| 增量/差异 | PG 17 起支持块级增量 | 支持（基于文件更新时间和块） | 极强 (DELTA, PAGE, PTRACK) | 支持（文件级与块级） | 支持 (基于 rsync 硬链接，或 PG 17 块级) |
| 并行处理 | 不支持 | 不支持 | 支持 (并行备份、恢复、合并) | 极强 (并行备份、恢复及异步 WAL 处理) | 有限 (主要依赖底层 rsync 或原生工具) |
| 云存储(S3等) | 不支持 | 不支持 (仅支持本地或共享存储) | 不支持 (仅本地或 SSH 远程) | 原生支持 (S3, Azure, GCS) | 原生支持 (借助 barman-cloud 套件) |
| 保留策略管理 | 无 | 支持 | 支持 (合并与删除过期备份) | 支持 | 支持 |
| 适用场景 | 极简环境、编写自定义备份脚本的基础组件 | 传统的单机或带有共享存储的小型集群 | 追求极致备份性能、极大数据量、需要灵活增量模式的系统 | 大型企业级集群、云原生环境、TB级海量数据 | 需要统一管理多个 PG 实例、追求高可用集成的企业 |
工具详细特性分析
pg_basebackup
工作原理：PostgreSQL 自带的物理备份工具，通过流复制协议连接到数据库并拷贝整个数据目录。
优势：
- 开箱即用：无需安装任何第三方软件，兼容性和安全性最高。
- 支持 PG 17 新特性：从 PostgreSQL 17 开始，官方正式引入了原生的块级增量备份功能。
劣势：
功能比较基础。它仅仅是一个“执行备份”的命令，缺乏对备份生命周期的管理（如：自动清理过期备份、备份目录结构管理、元数据追踪等），通常需要 DBA 自己编写脚本来管理。
pg_rman
工作原理：老牌的备份管理工具（由日本开源社区开发），通过一条命令完成全量/增量备份，并记录备份目录元数据。
优势：
- 命令极其简洁（如
pg_rman backup/pg_rman restore）。 - 实现了自动化的备份目录管理、留存策略（Retention Policy）和备份验证（Validation）。
劣势：
- 架构限制：它强依赖于对 PGDATA 数据目录的物理文件访问。如果要在远程服务器进行备份，通常需要挂载共享存储（如 NFS），这在现代云架构中不够灵活。
- 不再处于活跃的创新期，缺乏对多线程并行和 S3 对象存储的支持。
pg_probackup
工作原理：由 PostgresPro 开发，是对 pg_rman 理念的极大扩展和现代化重构，专注解决 PB 级或 TB 级大型数据库的备份痛点。
优势：
- 丰富的增量模式：支持
DELTA（扫描所有文件找差异）、PAGE（扫描 WAL 日志找差异）和特有的PTRACK模式（在数据库内核级别实时跟踪变更块，速度极快）。 - 高级管理功能：支持并行处理、增量恢复（仅恢复坏块或变更块）、备份合并（Merge，将增量合并为全量以节省空间），以及部分数据库恢复。
劣势：
- 无原生对象存储支持：不直接支持 S3，远程备份只能依靠 SSH 协议完成，若要上云需借助外部文件系统挂载。
- 某些高级特性（如 PTRACK）可能需要安装特殊的 PG 扩展或修改版 Postgres。
pgBackRest
工作原理：采用自定义的 C 语言协议层，专为可靠性和性能设计的大型系统备份工具。
优势：
- 极高的性能与并行性：独创的并行、异步 WAL 推送与获取功能，极大提升了高写入量数据库的 WAL 归档和回放速度。
- 原生云支持：原生内置对 S3、Azure、GCS 等对象存储的支持，并支持存储库加密。
- 无感知增量（Delta Restore）：恢复时可通过校验和比对，只恢复损坏或缺失的文件，极大缩短恢复时间（RTO）。
劣势 / ⚠️ 近期重大变动：
- 维护状态变更：根据其官网的最新声明，pgBackRest 的原作者已宣布停止维护该项目。虽然该工具本身非常健壮且目前被大量企业使用（包括 Supabase 等），但未来的更新和漏洞修复将依赖于社区是否能成功 Fork 并接管。在选型时需要将其生命周期风险纳入考量。
Barman
工作原理：由 EDB (2ndQuadrant) 开发的 Python 级大管家。它旨在成为一台专用的备份服务器，集中管理网络中多个 PostgreSQL 实例的灾备。
优势：
- 灵活的底层机制：支持经典的
rsync方式（利用文件系统硬链接实现空间极度节约的增量备份），也支持基于流复制的pg_basebackup方式。 - 生态融合好：完美支持云原生环境（通过
barman-cloud-backup和barman-cloud-wal-archive支持 S3/对象存储），且与高可用工具（如 Patroni, repmgr）集成极佳。 - RPO = 0 的能力：支持接收同步流复制的 WAL，可以实现理论上的零数据丢失。
劣势：
对于仅仅需要备份单个数据库的小型团队来说，设置一台专用的 Barman 服务器（并配置 SSH 互信等）可能显得有些重。
选型建议总结
1. 如果您追求“开箱即用”且系统较小：
直接使用原生的 pg_basebackup 配合简单的 Crontab 定时任务即可。如果升级到了 PG 17，还可以直接享受原生增量备份。
2. 如果您的数据库非常庞大（TB 级），且对备份速度和磁盘 I/O 要求苛刻（非云环境）：
选择 pg_probackup。它的并行处理能力、自动合并机制以及极速的 PTRACK/PAGE 增量备份是本地机房大型集群的利器。
3. 如果您是云原生环境，需要直接将备份打入 S3 / OSS：
- 原本
pgBackRest是毫无争议的首选（性能最好，原生云支持）。但鉴于其作者刚宣布停止维护，短期内如果您需要企业级保障，可能需要谨慎评估其社区 Fork 状态。 - 现阶段更安全的选择是
Barman（利用其 Cloud 扩展），背后有 EDB 强大支持，生态完善，且能完美胜任向 S3 等云存储的归档与备份。
4. 如果您需要统一管理公司内几十上百个 PG 实例的备份：
Barman 是最好的集中式管家，它强调灾备文化，对元数据的管理最为直观和全面。