今年 4 月 27 日，pgBackRest 作者 David Steele 发了一条让 PostgreSQL 社区震动的公告：这个项目不再维护了。原因很现实——Crunchy Data 被出售后，他一直在独自扛项目、同时找能继续做这份工作的职位，但始终没有成功。赞助寻求也未果。一个被大量生产环境依赖的备份恢复工具，就这样突然面临停摆。
一个多月后，情况反转。Steele 宣布 pgBackRest 将继续维护开发，背后是多方资助到位。项目没死，但这段动荡本身值得每个依赖开源工具的团队认真想想。
pgBackRest 为什么重要
PostgreSQL 自带的 pg_dump 和 pg_basebackup 能覆盖基本场景，但面对生产级需求时短板明显：增量备份、异地容灾、备份保留策略、多仓库管理、并行备份与恢复——这些能力 pg_basebackup 都不提供。pgBackRest 填的就是这个空缺。
它的核心能力包括：
- 增量与差异备份：基于页级变化检测，不必每次全量拷贝，大幅缩短备份窗口和存储开销。
- 多备份仓库：可同时将备份推到本地和 S3 等远程存储，一份配置搞定异地容灾。
- 并行操作：备份和恢复都支持多线程压缩与传输，大数据库场景下速度差距显著。
- 备份保留与轮转：按策略自动清理过期备份，不需要自己写 cron 脚本拼逻辑。
- 完整性验证：备份完成后自动校验 checksum，恢复前也能先验证，避免"备份写了但数据坏了"的隐蔽灾难。
在 PostgreSQL 生态里，能做到这一层且久经生产验证的开源工具，pgBackRest 凟然大物。它被 Crunchy Data、EDB 以及大量企业用户用在关键业务上，停维护的消息一出，社区反应激烈，正是因为替代选项要么功能覆盖不足，要么成熟度远不及它。
动荡与资助：发生了什么
Steele 在公告中坦率说了困境：Crunchy Data 出售后，他失去了公司支撑，独自维护一个被广泛依赖的项目，同时还要解决自己的就业问题。赞助渠道也没能及时补位。这不是"作者不想做了"，而是"作者没法继续做了"——典型的单点维护者风险。
一个多月后，多方资助到位，项目继续。具体资助方和金额细节在原文中有更完整说明，但关键信号是：这不是单一公司接盘，而是多家联合出资。这种模式比"一家独揽"更健康——单一公司随时可能因战略调整再次放弃，多方分担则让项目命运不绑定于任何一家的商业周期。
实操：从零配置 pgBackRest 全量 + 增量备份
下面是一个可以在本地直接跑起来的最小配置示例，适合测试和学习。生产环境需要调整仓库路径、压缩算法和保留策略。
安装（Ubuntu/Debian）
# 添加 pgBackRest 官方 APT 源
sudo apt-get install -y curl
curl -fsSL https://www.pgbackrest.org/release.key | sudo gpg --dearmor -o /usr/share/keyrings/pgbackrest-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/pgbackrest-archive-keyring.gpg] https://apt.pgbackrest.org $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/pgbackrest.list
sudo apt-get update
sudo apt-get install -y pgbackrest
创建配置和备份仓库
# 创建备份仓库目录
sudo mkdir -p /var/lib/pgbackrest
sudo chown postgres:postgres /var/lib/pgbackrest
# 创建配置文件
sudo mkdir -p /etc/pgbackrest
sudo tee /etc/pgbackrest/pgbackrest.conf <<'EOF'
[global]
repo1-type=posix
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
repo1-retention-diff=3
process-max=2
log-level-console=info
log-level-file=detail
[mydb]
pg1-path=/var/lib/postgresql/16/main
EOF
sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf
PostgreSQL 需要开启 archive_mode
# 修改 postgresql.conf（路径根据你的版本调整）
sudo tee -a /etc/postgresql/16/main/postgresql.conf <<'EOF'
wal_level=replica
archive_mode=on
archive_command='pgbackrest --stanza=mydb archive-push %p'
EOF
# 重启 PostgreSQL
sudo systemctl restart postgresql
初始化 stanza 并执行首次全量备份
# 创建 stanza（检查配置并初始化仓库结构）
sudo -u postgres pgbackrest --stanza=mydb stanza-create
# 执行全量备份
sudo -u postgres pgbackrest --stanza=mydb --type=full backup
# 查看备份信息
sudo -u postgres pgbackrest --stanza=mydb info
执行增量备份
# 差异备份（基于最近一次全量）
sudo -u postgres pgbackrest --stanza=mydb --type=diff backup
# 增量备份（基于最近一次差异或增量）
sudo -u postgres pgbackrest --stanza=mydb --type=incr backup
模拟恢复
# 停掉 PostgreSQL
sudo systemctl stop postgresql
# 清空数据目录（模拟灾难）
sudo -u postgres rm -rf /var/lib/postgresql/16/main/*
# 恢复到最新状态
sudo -u postgres pgbackrest --stanza=mydb --type=immediate restore
# 启动 PostgreSQL
sudo systemctl start postgresql
注意：以上示例在单机本地仓库上运行。生产环境建议至少配置一个 S3 远程仓库（
repo2-type=s3），并调整repo1-retention-full保留足够多的全量备份周期。恢复时如果需要时间点恢复（PITR），用--type=time --target="2024-06-01 12:30:00"替代--type=immediate。
这次事件给团队的提醒
pgBackRest 活过来了，但这段插曲暴露的问题不会因为结局好就消失：
- 单点维护者是最脆弱的架构。一个被成千上万生产环境依赖的工具，维护者只有一个人，公司撤手后项目立刻停摆。评估你依赖的开源工具时，看维护者数量和资金来源比看 GitHub star 更重要。
- 多方资助比单一公司更抗风险。这次多方联合出资的模式值得注意——任何一家退出，项目不会立刻断粮。如果你所在公司重度依赖某个开源项目，参与联合资助是成本远低于"项目死了再迁移"的保险。
- 备份工具的选型要考虑生态韧性。pgBackRest 现在安全了，但下次呢？配置备份方案时，确保你的恢复流程不深度绑定工具的独有格式。pgBackRest 的备份输出是标准 PostgreSQL WAL + 数据文件，这意味着即使工具本身出问题，你仍然可以手动拼恢复路径——这是选型时容易被忽略但极其关键的属性。
- 定期验证备份可恢复性。工具活着不代表你的备份有效。pgBackRest 的
verify命令和定期恢复测试应该写在运维 checklist 里，而不是只在出事时才想起来。
pgBackRest 的故事结局不错，但它提醒了一件事：你每天跑的备份命令背后，是一个人在撑。让那个人撑得住，是整个生态的责任。