Show HN: Restoredrill – 证明您的 Postgres 备份恢复

未经测试的备份不是备份。 Restorerill 证明您的 PostgreSQL 备份确实恢复了。它获取最新的备份，将其恢复到一次性 Postgres 容器中，运行您定义的检查，并写入包含恢复时间的 JSON 报告。状态：v0.1.0，早期。仅限 Postgres。事情可能仍然会发生变化。每个人都知道他们应该测试恢复。几乎没有人这样做，因为没有安全的地方可以恢复，而且时间也不够。实现自动化的团队通常会手动执行一个 cron 作业和一个脚本，而这些都会悄然失败：演练停止运行，或者开始恢复相同的过时文件，一个月内没有人注意到。 Restoredrill 使练习成为一种单一命令的习惯，并且使跳过它变得大声。它按照您的恢复策略设置的任何时间表运行，而不是连续运行。许多 GRC 建议积极警告不要连续索赔，因为任何差距都会成为审计结果。这证明你按照计划做了你说过的事情。政策文件很容易被有意或无意地伪造。 “我们每季度进行测试”可能是上周写的，但一年内没有任何实际运行。带时间戳的机器生成的报告更难伪造。如果您正在进行 SOC 2、ISO 27001 或 AWS 基础技术审查，这就是他们要求的证据形式：来自真实恢复的真实日志，与运行的内容和时间相关联。这个领域还有其他工具。 Databasus 是一款适用于 Postgres、MySQL、MariaDB 和 MongoDB 的可靠自托管备份平台，具有完整的 Web UI 和内置恢复验证。如果您想要一个仪表板管理跨多个数据库引擎的备份，请从这里开始。 BackupDrill 专门为 Supabase 做了类似的事情，包括存储文件。 Restorerill 做了一件狭隘的事情：CI 原生检查，生成适合审计员的报告，而不是仪表板。随处失败关闭、RPO 新鲜度预检查、您自己的 SQL 断言、针对目标跟踪的 RTO、每个字段始终存在，因此它可以干净地复制到 SOC 2、ISO 27001 或 AWS FTR 证据数据包中。如果您已经有备份工具并且只需要证明它可以按计划恢复，那么就是这样。快速入门：十分钟，无生产访问权限 不测试恢复的常见借口是“没有安全的地方可以执行此操作”。有：您自己的笔记本电脑上有一个一次性容器。转储你拥有的所有 Postgres。 Supabase、RDS、您的本地开发盒并不重要： pg_dump -Fc -d "$DATABASE_URL" -f backup.dump 复制它旁边的 Examples/quickstart.yml （或将 backup.source 指向您保存它的位置）。运行它： $ returnedrill --config Quickstart.yml --trigger 手动restoredrill：PASS，restore花了4.2s，1/1检查通过，报告：restoredrill-report.json 就是这样。没有 S3、没有 CI、没有生产凭证。现在，您的笔记本电脑上有一个 JSON 文件，证明在大约十分钟内发生了真正的恢复，并带有时间戳。一旦工作正常，添加真正的检查（行数、新鲜度、您自己的 SQL 断言，请参阅示例/restoredrill.yml）并将其指向您的真实备份。检查是分层进行的。每个检查都是失败关闭的：如果检查无法运行，则视为失败，而不是跳过。在恢复开始之前进行预检查：备份文件是否足够大，其存档头是否可读，以及它是否实际上是最新的（RPO 检查）。这会捕获一个悄然死亡并留下相同过时文件的备份 cron。结构：恢复是否完成，是否有足够的表，并且序列与其表同步。滞后于其列最大值的序列仅在真正灾难发生后的第一次 INSERT 中显示。 Restorerill 现在捕获了它。读取路径：行计数、数据新鲜度以及您编写的任何 SQL 断言。恢复可以退出 0，并且在有人实际读取数据之前仍然处于撒谎状态。一个真实的事件：恢复过程干净地退出，而其背后的数据库却悄然损坏。这就是这些检查的目的。 RTO 证据：恢复实际花费了多长时间，根据目标进行检查（如果您设置了目标）。环境健全性：容器必须启动并接受连接，这也证明恢复环境有足够的工作空间。该报告是这里的真实产品。自动恢复是最简单的部分。获得审核员在第一次通过时接受的报告格式需要真正的迭代。这个模式来自于直接支付该成本的人：三次重写以及与真正的审计员进行数月的来回交流。每个字段始终存在，不会因为不适用而缺失。审计员经常将这些内容复制到电子表格中，并且有时会存在一个字段，有时不会破坏它。关键字段：triggered_by/triggered_by_user/pipeline_job_id：无论调度程序运行此操作还是有人按下按钮（--trigger manual --triggered-by you@example.com），都具有相同的架构。手动运行具有与计划运行相同的责任。 backup_resolved_key ：钻取的实际文件或对象，而不仅仅是配置的源。如果您的源是 S3 前缀，restoredrill 会选择最新的对象，但仅在检查后才进行