Barman恢复Postgres集群耗时过长，寻求技术协助

核心原因分析 #

你的情况大概率是以下两种或多种因素叠加：

1. 未指定恢复终止点：默认barman recover会尝试拉取从备份完成时刻到当前的所有WAL文件，如果原数据库在备份后仍有持续高写入，WAL会不断生成，恢复进程永远追不上最新状态。
2. 传输/IO瓶颈：SSH传输效率低、网络带宽不足，或者目标服务器磁盘IO性能差，导致WAL写入速度跟不上传输/生成速度，进程长期卡在WAL复制阶段。
3. WAL归档延迟：Barman端的WAL归档可能存在延迟，导致恢复时需要等待新的WAL文件归档完成才能继续。

分步解决方法 #

1. 立即限制恢复的终止点（优先操作） #

如果不需要恢复到数据库最新状态，指定具体的恢复时间点或事务ID，避免无限拉取WAL：

# 仅恢复备份本身，不追后续WAL
barman recover --remote-ssh-command "ssh postgres@newserverip" --target-action stop main-db-server backup-id /location

# 恢复到指定时间点（示例：2024-05-20 10:00:00）
barman recover --remote-ssh-command "ssh postgres@newserverip" --target-time "2024-05-20 10:00:00" --target-action stop main-db-server backup-id /location

--target-action stop会在到达指定点后停止恢复，不会继续等待新的WAL。

2. 排查并优化WAL传输效率 #

• 优化SSH传输：修改Barman的main-db-server配置文件（通常在/etc/barman.d/main-db-server.conf），添加SSH压缩参数减少传输量：

  ssh_options = -C
  

  终止当前恢复进程后重新执行。
• 手动预传已归档的WAL：在Barman服务器找到对应备份的WAL目录（默认/var/lib/barman/main-db-server/wals/YYYYMMDD/），用rsync直接传到目标服务器的/location/pg_wal/目录：

  rsync -avz /var/lib/barman/main-db-server/wals/YYYYMMDD/ postgres@newserverip:/location/pg_wal/
  

  确保目标目录权限为postgres用户所有，之后重启恢复进程会跳过已存在的WAL文件。
• 检查网络带宽：用iperf3测试原服务器到目标服务器的带宽，若低于100Mbps，考虑临时升级网络或切换高速传输链路。

3. 排查目标服务器磁盘IO瓶颈 #

用iostat -x 1查看磁盘指标：

• 若%util接近100%，说明磁盘满负载，WAL写入速度跟不上
• 若await超过50ms，说明磁盘响应慢

临时解决：

• 暂停目标服务器上其他占用磁盘的进程
• 云服务器可临时升级磁盘性能（如HDD切换为SSD）

4. 检查Barman日志定位具体问题 #

查看Barman服务器日志（默认/var/log/barman/barman.log），搜索recover相关条目，排查是否有：

• WAL文件下载失败、重复重试的记录
• postgres用户写入目标目录的权限错误
• Waiting for WAL file xxx to be archived这类归档延迟提示

后续预防建议 #

• 大体积备份恢复前，提前指定--target-time或--target-xid，避免无限制追WAL
• 定期监控原数据库的WAL生成速率，高写入场景下调整Barman归档策略
• 恢复前预传已归档的WAL文件，减少恢复阶段的传输时间

内容的提问来源于stack exchange，提问作者jack