Restoredrill: 验证Postgres备份能否真正恢复
Show HN: Restoredrill – proves your Postgres backups restore
Restoredrill 专为解决‘备份未验证等于无备份’的痛点而生。它自动拉取最新备份，在临时 Postgres 容器中执行恢复，并运行自定义检查，最终生成包含恢复时长的 JSON 报告。无需生产环境权限，10 分钟即可在本地完成验证。该工具生成的带时间戳报告专为 SOC 2、ISO 27001 等审计场景设计，确保你的恢复策略真实有效，而非纸上谈兵。
真正的危险并非备份损坏，而是演练脚本悄无声息地失效，或静默恢复了陈旧文件，而团队在整整一个月里都毫无察觉。
HN 评论区
22- sebmellen
这个领域还有其他工具。与其假装它们不存在，不如坦率地提出来。
为什么 LLM 喜欢这种写法？你为什么需要“坦率”地提及竞争对手，而不是“张扬”地提？
这个点子很酷，但 README 写得实在过于离题。
- lbrito
这是个很棒的想法，我也曾遇到过这种情况，并不得不手动实现过。
我遇到的最常见场景是：我实现了备份功能，由每日的 cron 任务调用 pg_dump。起初运行正常，我便没再管它，直到某天需要恢复时，发现备份文件无法使用。通常情况是，在某个时间点，VM 未能执行清除临时备份文件的命令，导致磁盘被占满，新的备份文件在写入中途被截断。
psql 在识别这类问题上非常糟糕，而这应该是非常普遍的情况。它不会在检查文件头时直接报错“备份损坏，中止”，而是继续执行 SQL 命令，直到最后一行——该行因被截断而成为无效的 SQL。
总之，花了一些时间才排查清楚。后来我基本上做了和你这个工具类似（可能更简单）的事情：设置另一个每日 cron 任务，下载文件并检查其结尾是否包含正确的 pg_dump 成功签名。到目前为止一直运行良好。
- mannyv
这个工具的存在让人隐隐感到恐惧。数据库转储怎么可能恢复失败？你的转储命令为什么不会告诉你它失败了？