Backups are a hypothesis until you restore one
We run unattended-ops for small teams. First thing we do with any new client: the 20-minute restore drill. Four times out of ten, it fails — and every one of those failures would have been a company-killing data loss event discovered during a real emergency.
The drill (20 minutes, once a month)
- Take last week's backup. Restore it to a scratch directory — never over live data.
- Open the thing the business actually cares about: the database, the invoices folder, the mailbox.
- Verify three things: it's there, it's complete, it's recent enough that you'd accept the data loss.
- Write down how long the restore took. That number — not your SLA slide — is your real downtime during a disaster.
If step 2 fails: you just saved the company for the cost of 20 minutes.
The two failure modes we keep finding
- The backup job "succeeds" on an empty target. New database deployed, old script still pointed at the old name. Green checkmarks for months, zero data. The drill catches it instantly.
- Backups live on the same machine (or same cloud account) as production. Ransomware encrypts both in one sweep. One copy must live somewhere production credentials cannot reach.
The kit we use for this
We packaged the exact runbook set we run on client servers:
- Backup & Recovery Kit — restore drill + audit checklist + rotation sheet: https://hive80lab.gumroad.com/l/backup-recovery-kit
- Ops Starter Kit — heartbeat monitors + automated morning report: https://hive80lab.gumroad.com/l/ops-starter-kit
- Agent-Ops 24/7 — the full unattended-ops runbook: https://hive80lab.gumroad.com/l/agent-ops-24-7
Even if you buy nothing: go restore one file from last week's backup right now. If you can't, you don't have backups — you have a feeling.
Top comments (0)