body:
Every developer has a backup script. Almost nobody verifies that the backup actually restores.
I learned this the hard way. Not in a production emergency — but close enough to make me uncomfortable. The script ran, the file was there, the cron job was green. Everything looked fine. Until I tried to restore it in a test environment and it failed silently.
That's the Schrödinger's backup problem: you don't know if your backup works until you open the box. And most people open the box during an emergency.
So I built Database Guardian Pro to solve this properly.
How it works:
The core idea is simple: don't just save the dump, actually restore it.
After every backup, the tool:
Takes the dump file:
Spins up an ephemeral Docker container with a clean database engine
Injects the dump and forces a full restore
Runs integrity checks — tables exist, data is readable
Destroys the container
If the restore fails, you get an alert on Discord or Slack immediately. If it succeeds, the backup is marked as valid. Not before.
No residue. No impact on your host system. No assumptions.
Why Docker:
The whole point is isolation. You don't want the verification to touch your production database or your host filesystem. Ephemeral containers are perfect for this — they exist for the duration of the test and nothing else.
Using the Docker SDK for Python made this straightforward. Spin up a container, run the restore, check the output, destroy it. The entire verification cycle takes seconds.
It also monitors live database health:
While I was building the backup verification, I added real-time monitoring for the databases themselves. It connects to MySQL, PostgreSQL, MongoDB, Redis and SQLite, checks connectivity and response times every 30 seconds, and streams status to a web dashboard via WebSocket.
Alerts only fire when state changes — not on every check. No spam.
What I learned building this:
The hardest part wasn't the Docker integration. It was resisting the urge to over-engineer it. The first version had too many abstractions, too many config options, too much "enterprise" thinking for a tool that needed to be simple to set up.
The version I'm happy with does two things well: it tells you if your databases are up, and it proves your backups actually work.
The repo:
The full source is on GitHub:
If you want the packaged version with Docker Compose, Grafana dashboards, and Nginx config, it's available on Gumroad for €10.
Happy to answer questions about the implementation in the comments
A comment that pushed me to go further:
After posting about the project on r/sideprojects, someone left a comment that stuck with me:
"Curious in your setup — are you just checking integrity at backup time or also verifying restore paths regularly? Because that's where we saw most things quietly break."
That was the question I hadn't fully answered yet. I was validating at backup time, but not running scheduled restore checks on older backups. Their team had seen backups that were technically completing but restoring outdated or incomplete data — because nothing was validating the full restore path end-to-end.
That comment is directly why the tool now runs a weekly restore check on the most recent backup and a monthly audit on a random sample of the last 6 months. It was the right call and I wouldn't have thought to structure it that way without that nudge.
This article was originally published by DEV Community and written by Atomic Mango.
Read original article on DEV Community