Disaster Recovery Plan Template for Small Teams
The one-page DR plan: five fill-in blanks, three numbers, one drill per quarter. Written for teams of 2–30 who cannot afford an enterprise BCP engagement and don't need one.
Most small teams' "disaster recovery plan" is a folder of PDFs from an insurance-driven compliance push, last opened the week it was written. When the region actually goes down, nobody opens the folder — they open a chat window and start improvising. Improvising during a disaster is expensive: the same question ("where are the backups?") gets answered three times, by three people, three different ways, and the two answers that are wrong cost you hours.
The fix isn't a 40-page plan. It's one page that answers, before the outage, the questions everyone will ask during it. Here is the whole template — fill in the blanks, print it, stick it in two places (your password manager and your phone), and rehearse it once a quarter.
The five fill-in blanks
- The trigger. What counts as a disaster? Write the test, not the vibes: "primary region unreachable for 15+ minutes from two networks" or "database server dead and restore ETA exceeds 2 hours." If the trigger requires a human to decide whether it's bad enough, you wrote a debate, not a trigger.
- The three numbers. RTO — how long until you're back (target: a number you've actually achieved once). RPO — how much data you can afford to lose (this is a statement about backup frequency, nothing else). Who's called — in order, with phone numbers, not Slack handles. Slack is down in the disasters Slack handles were meant for.
- The failover path. The exact sequence: restore from where, to where, verified how. This is the same rule as rollbacks: as exact commands, not as descriptions. "Restore from backups" is not a path. "aws s3 cp s3://dr-bucket/latest.sql.gz . → psql < it → run smoke test script" is a path.
- The degraded mode. What does the business do while you're restoring? Write-only mode? Static status page + "orders paused"? A DR plan without a degraded mode forces full recovery to be the only acceptable outcome — and full recovery is the slowest one.
- The drill. When it's tested (quarterly), who runs it, and where the drill result is written. An unrehearsed DR plan is a rumor.
The one-page plan, filled in
| Field | Example |
|---|---|
| Trigger | api region unreachable 15+ min from 2 networks, OR db restore ETA > 2h |
| RTO | 4 hours (achieved in March drill: 3h 41m) |
| RPO | 15 minutes (nightly full + 15-min WAL shipping) |
| Call order | 1. Sam (mobile) 2. Priya (mobile) 3. Dan (contractor, +44…) |
| Failover | DR runbook step 1–7 at /ops/dr-runbook.md — ends with smoke-tests.sh green |
| Degraded mode | Status page live, orders paused, support replies with template #3 |
| Drill | Quarterly, first Friday; result logged in ops journal; failures become tickets |
The drill is the plan
Untested numbers are wishes. The 20-minute quarterly drill: pick a Tuesday, restore the database to a scratch instance from last night's backup, run the smoke tests, time it, log one line. If the restore takes 3 hours, your RTO of 4 hours just became 3 hours of staring + 1 hour of work — and you learned it on a quiet Tuesday instead of during the real thing. This is the same discipline as the backup restore test, with the added step of timing it against your written RTO.
The rules that keep the plan alive
- One page, or it's dead. A DR plan nobody can read in five minutes during an outage is shelf-ware. Everything operational fits on one page; the appendices can be long, the plan cannot.
- It lives where the outage can't reach it. Inside your own infrastructure is wrong. Print it, put it in the password manager, put it on two phones. Assume every tool you normally use is part of the disaster.
- Phone numbers, not usernames. Your chat platform and your email are both down-or-trusted-nothing scenarios in a real region outage. The call list has mobile numbers because that's what survives.
- Degraded mode is a business decision, written in advance. "Should we pause orders?" is an awful question to answer live at 2am by whoever is most awake. Decide it now, write it down, make it boring.
- Every drill failure becomes a ticket with a date. A failed drill with no follow-up ticket is a rehearsal of failure, not prevention. The ticket is what turns the drill into a program.
- Changes to the failover path go through the same change record as everything else. If the runbook is stale, it's because DR was exempted from change control. It isn't.
The numbers that tell the truth
Track three lines per drill and per incident: time-to-detect, time-to-restore, data lost (in minutes). If those three aren't trending down (or already flat-good), the plan is decorative. Everything else — the documents, the tooling, the vendor SLAs — exists only to move those three numbers.
---
The Ops Starter Kit Vol. 2 ($27) includes the full continuity pack — the one-page DR plan, the restore drill card, and the on-call call list template — plus the advanced incident response and comms templates. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout.