I have thought about it. I am not going to, and the reason matters.
The compose file works because it forces me to open an admin UI and scroll. The moment I replace scrolling with row-count assertions, I will start getting green ticks on the day the backup is silently wrong. A checksum says the bytes match. A row count says the count matches. Neither of those says the orders.status enum still decodes correctly, or that a bytea column came back as a string, or that a timestamp came back in UTC when the application wants it in IST. Those are the problems you catch by putting human eyes on the data.
There is a clean split in this system I want to protect. The making of backups is automated, scheduled, audited, alerted, and I trust it. The checking of backups is manual, slow, and not my favourite way to spend a Sunday morning. That is correct. Verification is a ritual, not a job. If I automate it away, I will lose the one thing that actually makes me look.
The UIs are hilarious in aggregate
A small appreciation, because these tools are a time capsule of twenty years of database tooling:
-
pgAdmin is the serious one. Loads slowly, does everything, is the reason I keep using Postgres.
-
phpMyAdmin is twenty years of PHP in a trench coat, and somehow still the fastest way to eyeball a MySQL dump. I do not know how. I have stopped asking.
-
Mongo Express is sparse but it does its one job.
-
Redis Commander is what I use to remember whether a cached key is JSON or a raw string.
-
Adminer is the single-file PHP hero of my generation, now driving my MSSQL tab because Microsoft's own tooling refuses to make this easier.
-
Kibana is absurd overkill for "did the Elasticsearch restore work", but when the only dump you have is an ES snapshot, you use what the ecosystem hands you.
All of them are pinned to latest, because this is not production. If any of them break after a version bump, I delete ./data and move on. That is a luxury the rest of my infrastructure does not get.
What I would still add
Two small items on the list, nothing structural.
A helper script for Redis, because restoring an .rdb snapshot is the one place where "drop the file into /dumps and import it" is not quite enough — you have to stop the container, replace dump.rdb at the right path, fix permissions, and restart. Every other engine is a one-liner. Redis is the awkward cousin at the dinner table, and I keep re-googling the procedure.
And bacpac support for MSSQL. The current setup handles .bak fine, but bacpac has bitten people I know, and I do not want to be fighting sqlpackage on the day a client actually needs their data back.
Go do the boring thing
If you have a backup setup you trust, the honest question is whether "trust" is built on a test drill or on a real restore. If it is the drill, go pull a real snapshot tonight. Not next quarter, not next incident review — tonight. Boot a throwaway database. Put eyes on a table you know by heart. If the rows are where you expect, that is a feeling worth having. If they are not, you have caught it on your terms instead of the worst possible day.
There is no repo for this one. backup-verify is just a folder on my laptop with the compose file above in it and a .gitignored data/ directory it writes to. It is not going to become a published project — the moment it grows a README, someone will file an issue, and then it stops being the thing I can delete without guilt when it breaks. The snippet in this post is the whole thing. Copy it, change the ports that collide with yours, drop the engines you will never restore, and you are done.
Not going to pretend this was a perfect writeup. But if even one part of it nudges someone to finally open a backup they have been politely ignoring, then it was worth putting down. See you in the next one.