pgBackRest在备份阶段可以开启并行压缩来缩短备份窗口，这一点多数资料都有介绍，但还原环节的并行能力经常被忽视。实际上恢复操作往往发生在最紧张的时刻——数据库宕机、业务等待、管理层催促，此时还原速度每提升一倍，故障时间就缩短一半。本文通过一组真实环境下的测试，验证process-max参数在restore阶段带来的实际收益，并分析并行度提升后性能收益递减的原因。
测试环境与方案设计
测试环境为一台配备NVMe SSD的服务器，8核CPU，32GB内存，操作系统为CentOS Stream 9，PostgreSQL版本15.6，pgBackRest版本2.50。备份仓库repo放在本地另一块SSD上，同时准备了一台NFS服务器模拟网络存储场景。测试数据库是通过pgbench初始化生成，规模约200GB，包含10万个数据文件，这样能够比较真实地反映并行处理大量文件时的调度开销。
测试方案的设计思路是控制变量。每次测试前彻底删除PGDATA目录并清理文件系统缓存，使用echo 3 > /proc/sys/vm/drop_caches确保冷启动状态，否则操作系统页缓存会让测试数据严重失真。还原命令统一使用相同的配置，只调整--process-max参数，取值分别为1、2、4、8。每种配置连续执行三次取平均值，排除偶发的I/O抖动。
# 冷缓存后的并行还原测试 sudo systemctl stop postgresql-15 sudo rm -rf /pgdata/15/data/* sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' # 以4进程并行还原 pgbackrest --stanza=main --delta --process-max=4 restore # 记录耗时 time pgbackrest --stanza=main --process-max=8 restore
需要说明的是，--delta选项在本次测试中刻意关闭了部分轮次，因为增量比对逻辑会跳过未变化的文件，影响原始还原能力的评估。另外还原完成后统一执行了一次pgbackrest check确认数据完整性，避免追求速度却牺牲了正确性。
不同并行度下的实测数据对比
本地SSD场景下，还原200GB数据库的耗时表现相当有规律。单进程耗时约31分钟，两进程降到17分钟，四进程进一步压缩到9分40秒，八进程则为6分10秒。换算成吞吐量，单进程大约110MB/s，八进程达到约560MB/s。数据说明并行还原的收益是真实存在的，但从四进程到八进程这一段，加速比从3.2倍只提升到5倍，明显低于线性增长。
| process-max | 还原耗时 | 吞吐量 | 加速比 |
|---|---|---|---|
| 1 | 31分02秒 | 110MB/s | 1.0 |
| 2 | 17分15秒 | 198MB/s | 1.8 |
| 4 | 9分40秒 | 352MB/s | 3.2 |
| 8 | 6分10秒 | 560MB/s | 5.0 |
NFS场景的数据则揭示了另一层问题。当repo部署在网络存储上时，单进程还原耗时暴涨到58分钟，网络带宽成为第一瓶颈。八进程并行后耗时降到11分钟，加速比反而接近5.3倍，比本地SSD场景更接近线性。原因在于网络存储的单流传输无法占满链路带宽，多进程并发请求能够更充分地利用网络吞吐能力，这恰恰说明并行还原在网络仓库场景下的价值更大。
压缩格式对结果也有明显影响。备份时使用--compress-type=zst --compress-level=3的仓库，还原时需要额外承担解压开销。测试中发现zst格式解压速度很快，四进程并行时CPU占用率约60%，并未成为瓶颈；而如果压缩级别调到9，单进程解压CPU占用直接顶满，此时增加并行度的收益会被CPU竞争部分抵消。所以在规划备份压缩策略时，要考虑到将来还原时的解压成本。
并行收益递减的原因分析与调优建议
并行度提升后收益递减，核心原因有三个。第一是小文件调度开销。pgBackRest按文件分配给各工作进程，大量KB级别的小文件会导致进程间负载不均，某些进程早早完成任务处于空闲状态。从测试日志可以观察到，八进程模式下尾部阶段经常只有两三个进程还在工作。第二是目标磁盘的写入能力上限。本地SSD顺序写入约600MB/s，八进程并行时的560MB/s已经接近这个天花板。第三是文件系统元数据操作，创建目录、设置权限、更新时间戳这些操作无法完全并行，文件数量越多占比越大。
针对这些瓶颈，有几条实用的调优建议。首先是并行度不必盲目拉满，一般设置为CPU核心数的一半到四分之三即可，本例中4到6进程是性价比最高的区间。其次要关注表空间分布，如果数据库有多个表空间且位于不同物理磁盘，pgBackRest可以同时对不同表空间操作，天然获得额外并行度，这种情况下每个表空间的并行数可以适当下调。第三，如果使用网络仓库，务必确认网络带宽大于所有进程并发传输的总需求，万兆网络下建议并行度不超过8，避免拥塞引发重传反而拖慢速度。
# /etc/pgbackrest/pgbackrest.conf 关键配置 [global] repo1-path=/backup/repo repo1-type=posix repo1-retention-full=2 process-max=4 compress-type=zst compress-level=3 start-fast=y [main] pg1-path=/pgdata/15/data
最后提醒一点，还原完成只是恢复的一半，之后PostgreSQL还要执行WAL回放才能达到一致状态。如果备份后产生了大量WAL，回放时间可能不亚于还原本身。这种情况下可以考虑结合PITR策略，在备份完成后定期执行pg_switch_wal减少回放量，或者在备库上做恢复演练，把回放压力从生产环境剥离出去。综合来看，pgBackRest的并行还原能力配合合理的参数规划，完全可以将数百GB数据库的恢复窗口控制在十分钟级别，这对绝大多数业务的RTO要求来说已经足够。
pgBackRest并行还原PostgreSQL备份恢复修改时间：2026-09-16 03:02:35