未经测试的备份不算真正的备份。restoredrill 证明您的 PostgreSQL 备份确实能够恢复。它获取最新的备份，将其恢复到一个临时 Postgres 容器中，运行您定义的检查，并生成一个包含恢复时间的 JSON 报告。状态：v0.1.0，尚在早期阶段，仅支持 Postgres。事物可能仍会发生变化。为什么每个人都知道他们应该测试恢复，但几乎没有人做，因为没有安全的地方可以恢复，也总是没有足够的时间。通常将其自动化的团队都会手动编写一个 cron 任务和一个脚本，而这些通常会在自己的方式中静默失败。真正的危险不是糟糕的备份，而是演练静默未运行，或静默恢复了一个过时的文件，结果一个月都没有人注意到。restoredrill 使得演练变成一个一键的习惯，并使得跳过它的行为变得显眼。它根据您的恢复策略设置的时间表运行。它并不假定您需要持续测试（很多 GRC 建议实际上会警告反对这样做，因为在“持续”声明中的任何间隙都可能成为审计发现）。它只是证明您按计划做了您所说的事情。政策文档很容易伪造，无论是故意还是意外。“我们每季度测试一次”可能是在上周写的，但实际上在一年中没有真正进行过。带有时间戳的机器生成报告更难伪造。如果您正在进行 SOC 2、ISO 27001 或 AWS 基础技术评审，这是他们所要求的证据形式：来自真实恢复的真实日志，关联到执行的内容和时间。与其他工具相比的发展这个领域还有其他工具。值得直接命名，而不是假装它们不存在。Databasus 是一个可靠的自托管备份平台，支持 Postgres、MySQL、MariaDB 和 MongoDB，具有完整的 Web 用户界面和内置的恢复验证功能。如果你想要一个仪表盘来管理跨多个数据库引擎的备份，首先查看那里。BackupDrill 专门为 Supabase 提供类似的功能，包括存储文件。restoredrill 并不试图成为其中的任何一个。它是一个单一用途、原生 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 指向您保存的位置）。运行它：$ restoredrill --config quickstart.yml --trigger manual restoredrill: PASS，恢复耗时 4.2 秒，1/1 检查通过，报告：restoredrill-report.json 就这样。没有 S3，没有 CI，没有生产凭据。您现在有一个证明真实恢复发生的 JSON 文件，带有时间戳，在您的笔记本电脑上，大约用十分钟完成。一旦这个成功，就添加真实的检查（行数、时效性、您自己的 SQL 断言，见 examples/restoredrill.yml）并指向您的真实备份。它检查的内容检查分为几个层次。每个检查都是关闭失败的：如果检查无法运行，则视为失败，而不是跳过。预检查，在恢复开始之前：备份文件是否足够大，其归档头是否可读，并且它是否确实是最新的（RPO 检查）。这捕捉到一个悄然失效的备份 cron，现场留下了同样过时的文件。结构性检查：恢复是否完成，是否有足够的表，以及序列是否与其表同步。一个落后的序列只有在真正的灾难后首次 INSERT 时才会显示。restoredrill 现在就可以捕获到。读取路径：行数、数据时效性，以及您编写的任意 SQL 断言。恢复可以干净退出 0，但仍然可能在数据读取之前撒谎。一个真实的事件：一个恢复过程正常退出，但后面的数据库却悄然损坏。這正是这些检查的目的。RTO 证据：恢复实际耗时，检查是否与您设定的目标相比。环境完整性：容器必须能够启动并接受连接，这也证明恢复环境有足够的空间进行操作。证据报告报告是这里真正的产品。自动化恢复是简单的部分。获取审计师第一次通过接受的报告格式需要真实的迭代。这个模式来源于某个直接支付该成本的人：经过三次重写和几个月与真正审计师的反复沟通。每个字段始终存在，绝不会因为不适用而缺失。审计师通常会将这些复制到电子表格中，而某个字段有时存在有时不存在会破坏这一点。关键字段：triggered_by / triggered_by_user / pipeline_job_id：无论是调度程序运行的情况，还是手动触发的情况，都是相同的模式。