Backup Restore Test Template for Small Teams
One page. The drill that turns your backup from a hope into a plan — 30 minutes a month, one system at a time, with the log that proves it works.
Every small team has backups. Very few have restores. The difference shows up on the worst day of your year: the backup console is green, the retention policy is impeccable, and the first actual restore attempt fails on an expired token, a full destination disk, or a password that lived in one person’s head. Backups fail silently by default — a green dashboard means a job ran, not a file came back. The only signal that means anything is a restore you performed, timed, and logged. This page is the template for doing exactly that, in 30 minutes a month.
The restore-test card, one page
One row per system worth restoring. If a system is not on this card, you have implicitly decided you can live without it — make that decision on a quiet Tuesday, not during the outage:
| System | Backup tool & where | RPO target | Last verified restore | Next test date | Owner |
|---|---|---|---|---|---|
| File server / shared drive | Cloud backup, nightly | 24h | 2026-09-09 (single folder, 12 min) | 2026-10-06 | Ops lead |
| Production database | Nightly dump + weekly full | 24h | 2026-08-12 (to staging, 41 min) | 2026-09-16 | Backend lead |
| Laptops (endpoint backup) | Per-user agent | 4h | 2026-07-30 (one user, 9 min) | 2026-09-16 | Ops lead |
| SaaS data (CRM, email) | Vendor export + monthly copy | 30 days | 2026-08-01 (CSV export check) | 2026-10-01 | Founder |
Two columns do the real work. “Last verified restore” is a date and a duration — a row that says “yes” or is blank means never tested. “Next test date” means each system gets drilled on a rotating schedule, so the whole estate is proven every quarter without anyone losing a full day to it. Owner is one named human per row — the same rule as every other page in this series.
The 3-2-1 rule and the fourth rule nobody counts
The classic rule: three copies of the data, on two different media, with one copy off-site. It is necessary and insufficient, because it counts copies, not recoveries. The fourth rule: one test per quarter, per system — an actual restore, to an actual destination, timed and logged. A backup that has never been restored is a rumor. The fourth rule is the one this template exists to enforce.
The 30-minute monthly drill
Same shape every month, rotating across the card so each system is hit at least quarterly:
- Pick the target (2 min): one system from the card whose “last verified restore” is oldest. Randomize the artifact — a folder nobody thinks about, not the demo one.
- Restore it (15–20 min): to a scratch destination, never over the live copy. One file? One table? A full VM if the rotation says so — scale the drill to what the month allows, but do a real restore, not a status-page check.
- Verify the content (5 min): open the file, query the row, checksum a sample. A restore that returns zeros is a failed restore with extra steps.
- Log the row (3 min): date, system, time-to-restore, what broke, what the docs didn’t say. The log is the product — the drill is just how you produce it.
Two disciplines make the drill honest. First, rotate the destination: alternate cloud-restore, local copy, and (quarterly) a full rebuild onto spare hardware — the drill that only ever restores inside the backup tool’s own UI never learns whether the tool itself is the single point of failure. Second, never test on the live system unless the drill is specifically a live-failover rehearsal; overwriting production to test a backup is trading a real outage for a hypothetical one.
What to write down during the drill
The log entry is five fields. It takes three minutes and it is what you will hand the auditor, the insurer, and the new hire:
- Date, system, artifact restored — specific enough to repeat (“/finance/2026/Q3/ folder, 214 files”, not “file server”).
- Time to restore — the number that turns “we have backups” into “we are back in 40 minutes.” This is your real RTO, measured, not hoped.
- What broke — expired token, full disk, missing agent, password in a dead colleague’s head. Every break found in a drill is a break you don’t meet during the real thing.
- What the docs didn’t say — the step you had to improvise. Fix the doc the same day, while the improvisation is fresh.
- Verdict — passed / passed-with-notes / failed. A failed drill is a win: it found the break for free.
Monthly spot-check vs quarterly full-fire drill
Two cadences, two different jobs. The monthly 30-minute drill proves the plumbing: tokens valid, disks not full, files coherent. The quarterly full-fire drill (half a day, on a Friday afternoon) proves the whole muscle: rebuild one critical system from nothing onto spare hardware, from the documentation alone, with the owner watching but not touching. The full-fire drill is where you discover that the database dump needs a tool version that isn’t installed anymore, or that the only person who knows the restore passphrase is on leave. It pairs naturally with the incident-response drill schedule — run restore drill and response drill in the same quarter and each covers the other’s gaps.
Three metrics that keep the card honest
- Restore success rate — passed drills / attempted drills, rolling 12 months. Below 100% is fine (that’s what drills are for); zero attempts is the failure mode.
- Mean time to restore per system — your measured RTO. If it exceeds the promise you’d make a customer, the backup plan is fiction.
- % of card systems tested this quarter — the rotation coverage number. Target 100% within every rolling 90 days; the oldest “last verified” date on the card is your true risk position.
Worked example: the token that died quietly
A nine-person design agency backed up its file server to a cloud provider every night. The dashboard had been green for months — because the scheduler ran, and silently failed at the auth step for six weeks after a token expired. A monthly 30-minute drill — restore one forgotten project folder to a scratch drive — returned nothing. Token re-authed, backlog rebuilt, drill logged: failed, then passed, 14 minutes. Three months later a crypto-locker encrypted the file server overnight. Because the drills had run quarterly since, the team restored 1.2 TB from the cloud backup onto a replacement NAS in one afternoon and lost less than a day of billable work. The ransomware event didn’t find a backup. It found a practiced restore — and the practice is what cost $0 and 30 minutes a month.
The drill log, the card and the full-fire checklist are in the Ops Starter Kit. Want the whole estate — backups, restores, and the runbooks around them — audited and documented for you? See the small-team ops audit & runbook service.