pgBackRest 的并行备份并不是简单地把数据文件复制拆成多个线程。它会在备份过程中同时处理文件压缩、校验和传输，并且通过 WAL 归档保证一致性。并行度的真正来源是进程池，每个进程负责一批文件，这样在多核服务器上可以显著缩短备份时间。
一、并行备份的核心机制
pgBackRest 为每个 PostgreSQL 实例定义一个 stanza，通常命名为 main。备份时，它会从 PostgreSQL 的数据目录读取数据文件，同时调用压缩和校验逻辑。默认情况下，备份类型分为 full、diff 和 incr。full 会复制所有数据文件，diff 只复制自上次 full 以来变化的文件，incr 则复制自上次任意备份以来变化的文件。并行进程会把需要处理的文件集合拆成多个任务，每个进程独立完成读取、压缩和写入仓库的操作，因此 process-max 直接决定同时运行的任务数。
仓库路径在配置文件中通过 repo1-path 指定。pgBackRest 在仓库中维护 backup 和 archive 两个核心目录，backup 保存各次备份的清单与数据文件，archive 保存从 PostgreSQL 推过来的 WAL 段。备份过程中，WAL 归档必须持续可用，否则在备份结束时无法完成一致性校验。建议在 postgresql.conf 中开启 archive_mode，并把 archive_command 指向 pgBackRest 的 archive-push。
[global] repo1-path=/var/lib/pgbackrest repo1-retention-full=2 repo1-retention-diff=2 process-max=4 compress-type=zst compress-level=3 start-fast=y stop-auto=y [main] pg1-path=/var/lib/postgresql/14/main
上面这段配置把全局并行度设置为 4，使用 zstd 压缩，保留两个全量备份和两个差异备份。start-fast=y 会尽快结束在线备份的一致性标记阶段，减少对写事务的影响。stop-auto=y 则允许在备份完成后自动关闭由工具启动的备份模式。
执行备份时，可以通过命令行临时覆盖并行度。例如下面的命令直接指定 --process-max=4。full 备份的数据量最大，通常建议在业务低峰执行，diff 和 incr 作为日常增量策略。
sudo -u postgres pgbackrest --stanza=main --type=full backup --process-max=4 sudo -u postgres pgbackrest --stanza=main --type=diff backup --process-max=4 sudo -u postgres pgbackrest --stanza=main --type=incr backup --process-max=4
需要注意，process-max 不是简单的线程数。它对应 pgBackRest 同时运行的进程数，每个进程还可能使用本地缓存或临时文件操作。如果设置过高，磁盘随机读写和压缩 CPU 开销会互相争抢，反而降低整体吞吐。
二、并行还原的关键步骤
还原阶段同样受并行度控制。pgBackRest 在还原时会把仓库中的数据文件解压、校验并写回 PostgreSQL 数据目录，--process-max 同样适用。与备份不同，还原通常会直接覆盖或写入一个空目录。为了减少停机时间，可以在测试环境先验证还原流程。
如果是完整还原，建议先停止 PostgreSQL 服务，然后使用 --delta 参数保留目录中与仓库一致的文件，只恢复差异部分。这样可以避免每次全量复制所有文件。下面是一个常规完整还原的命令序列。
sudo systemctl stop postgresql sudo -u postgres pgbackrest --stanza=main --delta restore --process-max=8 sudo systemctl start postgresql
这里把并行度提高到 8，前提是服务器有足够的 CPU 和磁盘带宽。还原完成后，PostgreSQL 会从最后归档的 WAL 位置开始恢复。如果只做全量还原而不做时间点恢复，默认会恢复到备份结束时的状态。
如果要做时间点恢复，需要指定目标时间或事务 ID。pgBackRest 会自动生成对应的 recovery 配置。下面的命令演示了按时间点恢复，并在恢复完成后将实例提升为主库。
sudo -u postgres pgbackrest --stanza=main --delta restore \ --type=time --target='2025-06-15 14:30:00' \ --target-action=promote --process-max=8
时间点恢复依赖完整的 WAL 归档。如果 archive_command 没有配置，或者归档目录缺失早期 WAL，恢复会在到达目标时间前失败。因此，在启用并行备份之前，必须先用 pgbackrest --stanza=main check 检查归档链路是否正常。
三、并行度调优与资源匹配
并行备份和还原的性能上限通常由 CPU、磁盘和网络三者中最低的一项决定。process-max 设置得过大，会造成大量进程争抢同一个磁盘队列；设置得过小，又无法利用多核 CPU 的压缩能力。一般做法是从核心数的一半开始测试，例如 8 核服务器先设置 process-max=4，观察备份时间和系统负载，再逐步增加。
压缩算法对并行效率影响明显。zstd 是综合压缩率和速度较好的选择，lz4 压缩速度更快但体积更大，gz 兼容性最好但 CPU 开销相对较高。可以用下面的表格对比常见配置。
| 压缩类型 | CPU 开销 | 压缩率 | 适用场景 |
|---|---|---|---|
| zstd | 中 | 高 | 通用生产环境 |
| lz4 | 低 | 低 | CPU 紧张或需要最快备份 |
| gz | 中高 | 中 | 旧版本兼容或跨平台交换 |
磁盘 IO 也是绕不开的瓶颈。如果备份仓库在机械盘上，并行压缩再高也受限于顺序写速度；如果使用 NVMe 或 SSD，可以适当调大 process-max。对于远程仓库，例如通过 NFS 或对象存储，网络带宽和延迟往往成为主要约束，此时应优先考虑增大压缩等级来减少传输量，而不是盲目增加进程数。
可以通过 pgbackrest info 查看最近备份的耗时和大小，通过操作系统工具观察每个 pgbackrest 进程的 CPU 与 IO 占用。调优时建议每次只改变一个变量，例如压缩类型或并行度，避免多变量同时变化导致无法判断收益。
四、常见坑点与恢复验证
还原失败最常见的两个原因是数据目录非空和文件属主错误。pgBackRest 还原默认要求目标目录为空，除非显式使用 --delta。如果目录中存在旧实例残留文件，可能造成 PostgreSQL 启动时校验失败。执行还原前，应确认服务已停止，并确保数据目录属于 postgres 用户。
另一个容易被忽略的是归档连续性。增量备份和 PITR 恢复都依赖 WAL 归档没有断档。可以用下面的命令查看归档状态和备份信息。
sudo -u postgres pgbackrest --stanza=main check sudo -u postgres pgbackrest --stanza=main info
如果 check 输出中 archive 项目有报错，应优先检查 postgresql.conf 中的 archive_command 是否已生效，以及 archive-push 是否能成功写入仓库。确认配置后，重新加载 PostgreSQL 并手动执行一次 SELECT pg_switch_wal();，观察归档文件是否出现在仓库目录。
最后，并行备份与还原的价值需要通过实际恢复演练来验证。建议每季度在隔离环境执行一次完整还原和时间点恢复，记录备份时长、还原时长和 RPO/RTO 指标。只有经过演练，才能确定 process-max 和压缩参数是否真正适合当前硬件与业务窗口。
pgBackRestPostgreSQL备份并行还原修改时间：2026-09-30 16:00:54