Backup Restore Drill Checklist for Small Teams: Test the Restore, Not the Backup

A backup you have never restored is not a backup — it's a wish with a cron job. Backup software reports the only metric it can see: "job completed." It cannot see whether the catalog matches the objects, whether the credentials still decrypt the vault, or whether restoring a Friday's worth of work takes forty minutes or four days. The fix is small and boring: once a quarter, actually restore something, time it, and write down what was missing. This checklist is that drill on one page.

TL;DR: The Quarterly Restore Drill

• The gap it closes: green backup jobs say nothing about restorability. The only proof is a restore you performed, timed, and logged.
• The cadence: once a quarter, restore one file set from a random date at least 30 days back — and once a year, restore a whole system.
• The rule: if the drill took longer than you'd accept during an outage, that number is your real RTO — not the one on the slide.
• The payoff: dead credentials, stale catalogs, and never-opened SaaS exports get found in July, not on the bad day.

Why Green Backups Still Fail

Most small teams check backups the way they check a smoke detector's LED: it's blinking, therefore we're safe. But a restore is a chain, and the nightly job only tests the first link:

• The job runs, the vault doesn't open. The backup account password or encryption key was rotated and nobody updated the restore tooling. Jobs keep "succeeding"; the data is unreadable.
• The catalog is stale. The listing says the file exists; the object behind it was pruned by a retention policy running on different terms. Old-date restores fail selectively — on exactly the dates you'll ask for.
• Nobody knows where it lives. The backup works, but the one person who knows the passphrase, the portal, and the procedure left in March.
• SaaS data was never really covered. "We have backups" meant a CRM export someone downloaded in 2023 and never opened.
• The restore target doesn't exist. The plan says "restore to clean hardware," but no machine, VM, or spare account was ever named — so the real incident starts with three hours of improvising.

Every one of these is invisible until you rehearse. The drill is how a wish becomes a capability.

Before the Drill: Ten Minutes of Prep

• Pick the target: one file set, VM, or mailbox — and one date at least 30 days back. Random beats convenient, because convenient dates are always the ones that happen to work.
• Pick the environment: an isolated folder, sandbox VM, or spare account — never over the live copy. The drill must not be able to make anything worse.
• Name the crew and the clock: one person restores, one person times. Sixty-minute timebox — if you're not done in an hour, that is the finding.
• Use the documentation, not memory: restore procedure, passphrase location, portal login — opened from the binder. If memory is the only source, log it as a finding.

The Drill: Six Steps

1. Start the clock and open the runbook — no archaeology in chat history for "the link Dave sent." Steps that exist only in someone's head are finding #1. If you need a skeleton, start from the runbook template.
2. List the catalog for the chosen date — confirm the file set you expect actually exists for that day. Catalog-vs-reality gaps are finding #2.
3. Restore real content — not a test file you planted last quarter: a document tree, a database dump, a mailbox folder. Open it. Verify the data is current to that date. Existence isn't restoration.
4. Prove the credentials work — decrypt or sign in from the documented location. This is where rotated keys and departed admins bite.
5. Stop the clock and score it — minutes from "go" to "verified content." Compare with the RTO you'd tell a customer; the drill number wins.
6. Write the log line — one dated row with a fix owner. Ten seconds of writing, and it's the evidence your insurer and auditors actually want.

The Drill Scorecard: Five Columns

One sheet, five columns, one row per drill:

• What was restored — file server, mailbox, database dump, SaaS export.
• Date restored to — the random past date.
• Minutes taken — start to verified content: your measured RTO.
• What was missing — credentials, docs, tooling, files. Blank is a win.
• Fix + owner — one line with a name and a date; the row is done when the gap closes.

Four rows a year is a restorability record you can hand to anyone who asks "can you actually recover?" — and the only honest answer to that question is a sheet with dates on it.

The Six Ways Small-Team Backups Fail a Restore

1. Credentials rot. The vault key and portal login live in one person's head. Fix: password manager plus a documented location, tested every drill.
2. Retention theater. The policy says 90 days; the storage tier silently drops objects at 35. Only a deep-past drill date catches it.
3. SaaS exports never opened. An export is only a backup once a restore has been rehearsed from it. Include one SaaS export row per year.
4. The restore target doesn't exist. "Clean hardware" requires hardware. Name it: the spare VM, the hot-spare laptop, the cloud instance.
5. Nobody can find the backup. Three tools, two dead subscriptions, an external drive in a drawer. List every backup location in the key inventory register like any other key.
6. Untested network dependency. A cloud restore needs the network; during an internet outage that's a problem. Know which restores work offline.

Worked Example: The Tuesday Scare

09:40: the shared projects folder is missing half its client work — deleted since Friday, cause unknown. Because this team drilled in July, the response is boring: restore the folder tree from Friday's backup into an isolated directory — 22 minutes; discover two project folders were created after the last successful job, so the gap is four hours, not four days; write the Q3 scorecard row while it's fresh; assign the fix (put the folder inside the job's scope) and close it the same day. The un-drilled version of the same Tuesday ends with "our backup vendor says the job has been failing since June." If the deletion turns out to be malicious, the drill is also the rehearsal for the ransomware recovery checklist — attackers delete or encrypt backups first.

Paste-In Drill Log (CSV)

date,restored_what,restore_date,minutes,missing,fix_owner,fix_date
2026-03-12,fileserver/projects,2026-02-02,38,none,n/a,n/a
2026-06-11,mailbox@owner,2026-04-15,52,vendor-portal MFA reset,alex,2026-06-14
2026-09-10,crm pg-dump,2026-07-01,71,restore VM image stale,sam,2026-09-12

How This Fits the Rest of the Plan

The drill is the proof step of your disaster recovery plan: the plan says what gets restored and in what order, the drill proves you can. The measured RTO/RPO numbers belong in your downtime budget, and the cron monitoring checklist keeps the job that feeds this drill watched — a backup job nobody monitors is a backup that fails silently for months.

Instant-Download Ops Kits

This checklist is part of the Hive80 Lab ops kit line — field-tested, instantly downloadable:

• The First 30 Minutes — free incident quick-start
• Ops Field Cards — 12 printable incident checklists — $4
• Ops Starter Kit — full incident-response kit for small teams — $14
• Ops Mega Bundle — all 5 kits in one download — $29

⚡ Launch pricing is live at the store — check the banner for today's code.

Related Ops-Notes Pages

• Disaster Recovery Plan Template for Small Teams
• Ransomware Recovery Checklist
• Uptime & Downtime Budget
• Cron Job Monitoring Checklist
• Runbook Template