Why do LLMs like this kind of writing? Why did you need to “plainly” name the competition as opposed to “flamboyantly” naming them?
This is a cool idea but the README is absurdly not-to-the-point.
“I should not pretend other implementations don’t exist. I should name them plainly.” Unable to tell itself that it puts this in output so that it can tell itself there.
Same with the “not X but Y” style. It is self-steering introspection leaking into output for one reason or the other. Recent poor language use by model is probably an attempt to minimize this by being concise. But it really needs more thinking to solve problem and so it does some of it in output.
With GPT-5.6 I get reasonable results with "use natural, plain English". I tried "use ASD-STE100 Simplified Technical English" but I've found "natural plain English" to work better. Still not on the level I would write, but better.
In the mean time, I hear that Claude resists changing its writing style. A PO used Claude to write release notes and it was full of Claudeisms and tried changing the text into a TED talk. Then he prompted Claude to rewrite in ASD-STE100 Simplified Technical English, and Claude barely changed its writing. Then he switched to GPT-5.6 Terra, and GPT revised everything and made the text much better.
I'm willing to use (semi-)vibecoded projects under certain circumstances, but I like to know up front what I'm getting. The github contributors list makes that easy to see as long as people don't try to hide it.
The most common scenario for me was: I implement backup, done by a daily cron calling pg_dump. It worked and I moved on, until one day I needed to restore and the backups did not work. Typically at some point the VM failed to run the commands to clear temporary backup files, the disk would fill up and the new backups would be truncated mid way.
psql is pretty awful at identifying this which must be a very common scenario. Instead of a header check leading to "Corrupted backup, aborting" or something, it simply executes the SQL commands until it reaches the very last line, which will be truncated midway and thus invalid SQL.
Anyway, it took some time to figure out, but later I did basically what your tool does, probably simpler: another daily cron job that downloads the file and checks if it ends with the correct pg_dump success signature. It has worked so far.
just it’s surprising to me that devops folk aren’t in an org that has backup software, cause this kind of testing is standard load out for most backup softwares, and they even solve the space and isolation issue with various instant restore / publishing capabilities where data from the backup is mounted directly to some staging server with postgres or whatever installed in an isolated area
not trying to knock the idea you are correct most ppl don’t test their backups, but it’s a bit strange no one you talked to used any of the most common backup softwares
definitely in favor of free solutions as backup software field is awful like many ent tech fields, but like the workflows do exist
the isolation part is something that is more difficult due to space and resource constraints, and a lot of backup apps handle that but expect the user to handle the bespoke testing part
your tool covers both but expects the user to provide both which isn’t always feasible for the application teams (not impossible but lot of red tape to request resources and a lot of resistance if the company already has recovery verification tooling)
if i were you i would refocus your pitch on making it work as part of those backup software workflows, “tell your backup team about this test suite and include it in their recovery verification workflows” and i’m sure you’ll get a lot of attention
most of the dba’s probably have a backup and recovery verification solution at their company with the isolation and resources but they don’t have the bespoke application testing
Does not help that the description reads like AI slop.
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.
Seems like you put a lot of thought and effort into it which is awesome, so the LLM readme was ruining first impressions. It's a shame but given the explosion in low effort projects it's important to stand out I think.