AI NewsInfrastructureAnnouncement
restoredrill tests a Postgres backup by restoring it into a temporary container
restoredrill fetches your latest PostgreSQL backup, restores it into a disposable container, runs checks you define, and writes a JSON report with a real timestamp and the restore time. MIT, written in Go.
Image: GitHub
Why it mattersEveryone knows they should test restores. The reason nobody does is that there is nowhere safe to do it, and this makes a safe place in one command.
restoredrill is a small Go tool that proves a PostgreSQL backup actually restores. It fetches the latest backup, restores it into a temporary Postgres container, runs checks you define, and writes a JSON report including the restore time. If something else has already restored a copy, it can connect to that instead and run the same checks.
MIT licensed, at version 0.3.0, Postgres only, and the README says things may still change.
The opening line sums up the project
"Untested backups aren't backups."
The author's explanation of why this keeps happening is accurate. Everyone knows restores should be tested. Almost nobody does, because there is nowhere safe to do it and never enough time. Scripts and cron jobs do not fix it, because they fail quietly too: the job stops running, or keeps running on old data, and nobody is told.
The scheduling decision
It runs on whatever schedule your recovery policy sets, deliberately not continuously.
The README's reason for this is worth knowing even if you never install the tool: most compliance frameworks warn against claiming continuous testing, because any gap then becomes an audit finding. Testing quarterly and proving you tested quarterly is a cleaner position than claiming always and having one week where the job did not run.
Why the report matters more than the restore
The argument the project makes about evidence is the strongest point in it.
A policy document is easy to fake, on purpose or by accident. Someone can write "we test quarterly" today even if nobody has run a test in a year, and the sentence looks identical either way.
A report with a real timestamp, produced by the tool at the moment the restore happened, is much harder to fake. For SOC 2, ISO 27001 or an AWS Foundational Technical Review, that is the kind of proof asked for: real logs from real restores, showing what ran and when.
What to weigh
It is early. Version 0.3.0, 96 stars, PostgreSQL only, one main contributor. That is fine for a tool that runs on a schedule and produces a report, and it would not be fine for something in the path that serves user requests.
The checks are yours to write, and they are where the value is. A restore that completes and produces an empty database has proved nothing. Row counts against expected ranges, a query against your most important table, a check that the most recent row is recent: those turn "the restore ran" into "the data is there".
Ten minutes to try, and the honest question it answers is one most teams have been avoiding.
Source
- ahmadpiran/restoredrill on GitHub, MIT licence. Star, version and date figures read from the GitHub API on 31 August 2026
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
