PostgreSQL物理备份工具pg_rman和pgBackRest的对比及适用场景

工具

设计定位

开发维护主体

核心目标

pg_rman

轻量级、类 RMAN 备份工具

NTT DATA（日本团队）

简化备份流程，贴近 Oracle DBA 习惯

pgBackRest

企业级、高性能备份恢复解决方案

开源社区（EnterpriseDB 等支持）

支持大规模、分布式环境，保障高可用

维度

pg_rman

pgBackRest

架构模式

单节点 “直连式” 架构：工具直接连接 PostgreSQL 实例，备份文件存储在本地或共享存储（如 NFS），无独立服务端。

客户端 - 服务器（C/S）架构：支持独立的备份服务器，客户端（PG 节点）将数据发送到服务端存储，支持多客户端连接。

优点

- 架构简单，无需部署服务端，上手快；- 资源消耗低，适合单实例场景。

- 支持分布式备份（多 PG 节点备份到同一服务端）；- 备份存储与数据库节点分离，降低数据库节点 IO 压力；- 便于集中管理备份策略。

缺点

- 不支持分布式部署，多实例备份管理繁琐；- 备份存储与数据库共享节点资源，可能影响数据库性能。

- 架构复杂，需部署 / 维护服务端，初期配置成本高；- 依赖网络稳定性（客户端与服务端通信）。

维度

pg_rman

pgBackRest

全量备份

支持，但仅支持 “单线程” 备份，无并行能力；备份速度依赖单线程 IO 效率。

支持多线程并行备份（可配置 process-max），能充分利用 CPU 和 IO 资源，大规模实例（TB 级）备份速度远超 pg_rman。

增量备份

- 基于 “文件修改时间 + WAL 位置” 判断增量数据，精度较低，可能备份不必要的文件；- 仅支持 “差异增量”（基于最近一次全量 / 增量），不支持 “累计增量”。

- 基于块级校验和判断变化（仅备份修改的块），精度高，增量数据量小；- 支持 “差异增量” 和 “累计增量”（基于最近一次全量），灵活适配不同恢复需求。

归档日志备份

需手动配置 archive_command 将 WAL 归档到 pg_rman 目录，再由工具定期备份；日志清理需手动触发。

- 自动集成 WAL 归档（配置 archive_command 指向 pgBackRest 客户端），支持实时归档；- 可自动清理过期归档日志（基于备份保留策略），无需手动干预。

优点

- 增量逻辑简单，易于理解；- 无额外校验开销，小实例（GB 级）增量备份速度尚可。

- 备份效率极高，尤其适合 TB 级大规模实例；- 增量精度高，节省存储成本；- 归档日志管理自动化，降低运维成本。

缺点

- 增量精度低，可能浪费存储；- 无并行能力，大规模实例备份耗时久；- 归档日志管理繁琐。

- 块级校验和计算有轻微性能开销（可通过配置优化）；- 增量策略配置较复杂，需理解 “差异” 与 “累计” 的区别。

维度

pg_rman

pgBackRest

时间点恢复（PITR）

支持基于 WAL 归档的 PITR，但需手动指定恢复时间 / WAL 位置；恢复过程需手动启停实例。

支持全自动 PITR（仅需指定恢复时间 / LSN），工具可自动识别所需备份集和归档日志；支持 “即时恢复”（Recovery-in-Place），无需额外拷贝数据文件。

实例恢复

仅支持 “全实例恢复”（恢复整个 PostgreSQL 实例），不支持单数据库 / 表空间恢复（受限于 PG 本身的备份粒度，但工具未做扩展）。

支持 “全实例恢复”，同时通过 “部分恢复” 功能（配合 PG 的表空间分离），可实现单数据库 / 表空间的恢复（需提前规划表空间）。

集群恢复

不支持多实例集群（如流复制集群）的统一恢复，需逐个实例操作。

支持流复制集群的 “主从同步恢复”，可快速将备库恢复到与主库一致的状态，适配高可用集群场景。

恢复验证

需手动执行 pg_rman validate 命令验证备份集完整性，不支持自动验证。

支持备份后自动验证（配置 validate=y），可自动检查备份集的完整性和可恢复性；还支持 “模拟恢复”（dry-run），提前验证恢复流程。

优点

- 恢复逻辑简单，适合简单的单实例 PITR 场景；- 操作命令贴近 Oracle RMAN，熟悉 RMAN 的 DBA 易上手。

- 恢复场景覆盖全面（PITR、部分恢复、集群恢复）；- 自动化程度高，减少手动操作失误；- 恢复验证机制完善，降低 “备份不可用” 风险。

缺点

- 恢复灵活性差，不支持部分恢复和集群恢复；- 无自动验证，备份可用性依赖人工检查；- 大规模实例恢复速度慢（单线程）。

- 复杂恢复场景（如部分恢复）需提前规划表空间，配置门槛高；- 恢复参数多，需深入理解工具逻辑才能高效使用。

维度

pg_rman

pgBackRest

配置文件

配置简单，核心参数仅需指定 PG 实例路径、备份目录、归档目录等，通常一个 pg_rman.conf 即可覆盖需求。

配置复杂，需区分 “客户端配置” 和 “服务端配置”，支持数百个参数（如并行数、压缩算法、加密策略、云存储配置等），需针对性调优。

命令行接口

命令少且简洁（如 backup、restore、validate），语法贴近 Oracle RMAN（如 pg_rman backup incremental），学习成本低。

命令丰富但复杂，需指定更多参数（如 --type=full、--process-max=4），且客户端 / 服务端命令需匹配，学习成本高。

文档与社区

文档较简略，且部分核心文档为日文，英文文档更新不及时；社区规模小，问题反馈响应较慢。

官方文档极其详尽（包含大量示例、最佳实践和故障排查指南）；社区活跃（GitHub 星数超 3k），问题响应快，且有 EnterpriseDB 等厂商提供商业支持。

优点

- 配置和命令简单，上手快，适合新手或人力有限的团队；- 类 RMAN 语法，Oracle DBA 迁移成本低。

- 文档完善，问题易排查；- 社区和商业支持强，企业级场景可靠性有保障。

缺点

- 文档不足，复杂问题难找到解决方案；- 社区支持弱，bug 修复周期长。

- 配置门槛高，初期部署和调优耗时久；- 命令参数多，需长期学习才能熟练使用。

功能点

pg_rman

pgBackRest

云存储支持

不原生支持云存储（如 S3、Azure Blob），需通过挂载云存储目录（如 S3FS）间接实现，稳定性差。

原生支持 S3、Azure Blob、GCS 等主流云存储，可直接将备份存储到云端，支持云存储加密和生命周期管理。

备份加密

不支持原生加密，需依赖外部工具（如 GPG）对备份文件加密，操作繁琐。

支持传输加密（TLS）和存储加密（AES-256），可通过配置密钥实现自动加密，无需外部工具。

压缩

仅支持基础 gzip 压缩，无压缩级别调整，压缩效率一般。

支持 gzip、lz4、zstd 等多种压缩算法，可配置压缩级别，zstd 算法在压缩率和速度上均优于 gzip。

并行恢复

不支持并行恢复，恢复速度完全依赖单线程。

支持多线程并行恢复（同备份的 process-max 参数），大规模实例恢复速度可提升数倍。

增量备份合并

不支持将增量备份合并到全量备份（即 “合成全量”），需重新执行全量备份，耗时久。

支持合成全量备份（将增量备份与基础全量备份合并），无需重新读取数据库数据，大幅缩短全量备份时间。

优点

- 无额外配置负担，适合对高级功能无需求的场景。

- 高级功能全覆盖，完全满足企业级对安全、成本、效率的需求；- 合成全量、云存储等功能大幅降低运维复杂度。

缺点

- 缺乏企业级核心功能，无法适配大规模、高安全需求场景。

- 高级功能配置复杂（如加密密钥管理、云存储权限配置）；- 部分功能（如合成全量）对存储 IO 有一定要求。

维度

pg_rman

pgBackRest

备份性能

单线程备份，小实例（<100GB）性能尚可；大实例（>1TB）备份耗时极长，且占用数据库节点 IO 资源。

多线程并行备份，TB 级实例备份速度可达 pg_rman 的 3-5 倍；备份存储与数据库分离，不占用数据库节点 IO。

恢复性能

单线程恢复，大实例恢复可能耗时数小时甚至更久。

多线程并行恢复，恢复速度可随线程数线性提升（受 IO 限制）。

资源消耗

内存 / CPU 消耗低（单线程），对数据库实例影响小。

并行处理时 CPU / 内存消耗较高（如 4 线程备份可能占用 1-2 核 CPU）；服务端需额外的存储和计算资源。

优点

- 轻量级，对数据库节点资源影响小，适合资源紧张的环境。

- 高性能，适合大规模、高可用要求的生产环境。

缺点

- 大规模实例性能不足，备份 / 恢复窗口长。

- 资源消耗高，需为服务端预留足够资源。

对比维度

pg_rman

pgBackRest

架构

单节点直连

客户端 - 服务器

并行备份 / 恢复

不支持

支持

增量精度

文件级（时间戳）

块级（校验和）

云存储

不原生支持

原生支持（S3/Azure/GCS）

加密

无原生支持

原生 AES-256 加密

恢复灵活性

仅全实例 PITR

PITR / 部分恢复 / 集群恢复

社区支持

小，响应慢

活跃，商业支持强

学习成本

低

高

最佳规模

中小实例（<1TB）

大规模集群（TB 级）