Nobody disputes that backups need testing. Almost nobody actually does it, because there's no safe place to restore to and no time to build one. The people who do automate it usually end up with a cron job and a shell script that fails in its own quiet way. The real risk was never a bad backup. It's that quietly not running, or quietly restoring the same stale file, month after month, with nobody noticing.
restoredrill turns that drill into a single command. It grabs your latest backup, restores it into a disposable Docker container, runs whatever checks you configure, and writes out a JSON report with the restore time. Every check is fail-closed: if it can't run, that's a failure, not something quietly skipped.
Before writing a line of code I spent a couple weeks asking around r/devops and a few compliance subreddits how people actually handle this. Nobody had a clean answer, it was all bespoke scripts or nothing at all. A handful had already built close to this exact tool for themselves and hit the same wall every time: automating the restore was the easy part, getting a report format an auditor would sign off on took months. That's what shaped most of the report schema here.
The quickstart is meant to take about 10 minutes start to finish: pg_dump a Supabase or RDS database, point restoredrill at the file, run it against a local container. No production access, no S3, no CI required just to try it.
Worth naming the alternatives up front. Databasus is a solid self-hosted backup platform, several database engines, full dashboard, restore verification built in. BackupDrill does something close to this specifically for Supabase. restoredrill is narrower on purpose: no dashboard, a report built for an auditor (fail-closed checks, RPO/RTO evidence, your own SQL assertions), and it runs as a CI job instead of infrastructure you have to host.
Postgres only for the moment, pgBackRest and WAL support are on the roadmap. MIT licensed. Repo: https://github.com/ahmadpiran/restoredrill
Would like to hear what people think, especially if you've built something like this yourself and ran into the same report-format problem.