A green backup dashboard is a lie until you've restored it — so I restored this blog

I write "back up your stuff" in these posts like everyone does, with the quiet confidence of someone who has a cron job that dumps a database and a green checkmark that says it ran. Then I read a statistic that embarrassed me — around 82% of disaster-recovery setups are never actually tested — and realised my confidence was in the backup, not the restore. So I did the honest thing and actually restored this blog from scratch. Here's exactly what happened, numbers and all.

The drill

The rule I'd been ignoring: you don't have backups until you've restored from them. A job that completes tells you the dump ran. It tells you nothing about whether that dump will rebuild your site when you're panicking at midnight. The only way to know is to do it, cold, and time it.

So: I took a read-only dump of the production MariaDB, stood up a completely fresh throwaway MariaDB container, restored the dump into it, and checked that the data actually came back. No touching the live database. Real commands, real clock.

What the numbers said

• Dump: the whole database came out to 23 MB, in about 1 second, with --single-transaction so it never locked the live site.
• Fresh DB container up and ready: ~12 seconds.
• Restore: importing all 23 MB took 3 seconds.
• Verification: 73 tables, and 47 published articles — which is exactly the count on the live site. The data really came back.
• Files: the uploads directory (cover images and the like) is a separate 24 MB.

So the database recovery time for this blog, measured rather than guessed, is well under a minute. That's a genuinely reassuring number — and I only have it because I ran the drill instead of trusting the checkmark.

The gotchas you only meet by doing it

The point of a drill is the things that go wrong, and a few did:

1. MariaDB 11 renamed the tools. My muscle-memory mysqldump is gone — it's mariadb-dump now. A restore script written a couple of years ago would fail at the first command, at the worst possible moment.
2. Auth wasn't what I assumed. Root in the container uses password auth in one place and socket auth in another; my first two restore attempts died on "access denied" until I got it right. Exactly the kind of thing you do not want to be debugging during an actual outage.
3. The init race. A fresh MariaDB container runs a temporary bootstrap server before the real one, and my "is it ready yet?" check got fooled by the temporary one and imported into a database that didn't exist yet. Standing up a clean DB is not instant, and "the container started" is not "the database is ready" (a lesson I'd just written about for healthchecks — and promptly relearned here).

A backup job that has never been restored is a receipt, not an insurance policy. It proves you paid; it doesn't prove anyone will pay out.

The uncomfortable bit: the dump isn't enough

Here's what the drill really taught me, and it's the part that would actually sink me in a real disaster. Restoring the database and the files gets me a working database — but not a working site. Because the things that make this specific blog run don't live in the dump at all:

• The database credentials, the SMTP relay keys, the analytics ID, the IndexNow key — all of it lives in Coolify's environment variables, not in the SQL dump. Restore the DB onto a fresh box and Drupal still can't connect to anything until I've reconstructed that environment.
• The right image / Drupal version — restore a dump into a mismatched version and you're in migration-hook territory before you've had coffee.
• The files directory, which is a separate 24 MB I have to remember to snapshot alongside the database, or every cover image 404s.

So my real recovery plan is three things, not one: the DB dump (fast, proven), the files directory (small, easy to forget), and a written record of the environment that lives outside the app. The database was the easy 20%. The config and secrets are the 80% that a "backup" quietly doesn't include.

Do the drill

The whole exercise took me about fifteen minutes and turned a vague hope into a real number and a real to-do list. That's the pitch: pick a quiet afternoon, restore your thing into a throwaway container, and time it. Best case, you get a reassuring RTO like my sub-minute database. Worst case — and this is the valuable case — you find out the tool got renamed, the secrets aren't in the dump, and the "backup" you've trusted for months would not, on its own, have brought your site back. Better to learn that on a Tuesday than during the fire.