The SMB Disaster
Recovery Checklist
Fourteen checks that take a small business from “we have a backup somewhere” to something you could actually recover from.
Most small businesses don’t have a disaster recovery plan. They have a backup — usually one — and a quiet hope that it works. This checklist is the shortest honest path from that to something you could genuinely recover from.
It’s written for the person at a 5–50 employee company who ends up owning IT, whether or not that’s in their job title. Nothing here needs a consultant, an appliance, or a budget approval. Most of it is an afternoon’s work; item 12 is a deliberate once-a-year exercise.
Work through it in order. Tick what’s already true, and be honest about what isn’t — an untested backup counts as unticked.
If you only do three things
Get one whole-machine image of the machine the business can’t lose
Onto storage that isn’t your sync folder and isn’t the same physical disk.
Restore something from it this week
A single file is enough. It proves the whole chain works end to end.
Write down who calls whom, and where the recovery media is
One page, printed. The copy on the encrypted file server helps nobody.
Everything else on this list makes those three better. Nothing else on this list substitutes for them.
Want this as a printable checklist?
Get the two-page PDF to work through offline, or hand to whoever owns backups.
Fourteen checks, four sections
Tick boxes as you go — progress is saved in this browser only, and never sent anywhere.
Know what you’re actually protecting
Ten minutes of writing here decides whether everything after it is aimed at the right machines.
List the systems that would stop the business — and which machine each one lives on
Not files: systems. Invoicing, scheduling, the client or patient database, the share everyone opens. Write each one down next to the machine it actually runs on. Most small offices find the business sitting on one unremarkable PC that nobody thinks of as a server.
Put a number on how much downtime, and how much lost work, you can absorb
Two plain questions. How long can this be down before it really hurts? That’s your RTO. How much recent work could we afford to redo? That’s your RPO. “Half a day” and “one day” are perfectly good answers — the point is that your answers set the backup schedule, instead of the schedule quietly setting them for you.
Build copies that survive the thing that actually happens
Disk failure, theft, a bad update, ransomware. Different failures, and a single copy loses to most of them.
Get to three copies, on two kinds of storage, with one out of reach
The 3-2-1 rule, stated usefully: the live machine is copy one; a backup on separate storage — external disk, second drive, NAS — is copy two; and copy three sits somewhere the first two can’t be destroyed alongside them. Fire, flood and theft take copies one and two together when they share a room.
Check that what you’re calling a backup isn’t actually sync
Dropbox, OneDrive and Google Drive replicate whatever happens to your files — including encryption — usually within seconds. Version history softens that, but it’s per-file, time-limited, and blind to everything outside the synced folder. Keep sync for collaboration. Just don’t count it as the recovery plan.
Backup vs sync, in detailBack up whole machines, not only the folders you remembered
File-level backup returns your documents. It doesn’t return the operating system, the applications, the settings, or the database engine your line-of-business app needs — that’s a rebuild, and rebuilds are measured in days. Image-level (block-level) backup captures the whole machine as a point in time, so recovery is a restore instead of a reconstruction. Run both if you like; don’t run only files.
Make sure at least one copy can’t be encrypted or deleted by whatever hit you
Modern ransomware looks for backups first, and anything reachable as ordinary storage is fair game: a permanently plugged-in USB drive, a mapped share, a synced folder. Any one of three fixes works — rotate an offline copy, use immutable (WORM) storage, or use a tool that pins its last clean recovery point the moment something starts changing files en masse.
Notice trouble before your staff do
The part that ruins small businesses isn’t the attack. It’s the hours of silence before anyone knows.
Have something watching for encryption in progress
Encryption typically starts overnight or over a weekend, and nobody finds out until someone opens a file the next morning. Decoy-file (“canary”) detection is the cheap, deterministic version of catching it: plant files nothing should ever legitimately touch, re-check them on every backup run, and alert the moment one changes. Nothing to train, nothing to guess.
How canary tripwires workConfirm your detection protects the backup, not just your inbox
An alert that arrives while your recovery points are being encrypted is a notification, not a defence. What matters is whether the tool freezes the last known-good copy when it fires, so there’s still something clean to restore from. Ask your vendor that exact question and get a straight answer.
Set retention against how late you would realistically notice
If the honest answer to “when would we spot this?” is “about a week”, then seven days of recovery points leaves you exactly zero margin — and attackers routinely sit quiet before they trigger. Pick a retention window comfortably longer than your discovery lag, then check what your current tool actually keeps today, not what it could be configured to keep.
Prove it works — then keep proving it
Everything above is a hypothesis until something comes back. This is the section people skip.
Restore one file today
The highest-value ten minutes on this list. Open your backup, pick a file from a few days ago, restore it, open it. This is what catches the silent failures that invalidate everything else: the wrong folder scoped, expired credentials, a full target, a job that hasn’t actually run since March.
Build the bare-metal recovery media now, while everything is fine
A bootable rescue USB you can start the replacement machine from. It takes minutes to create today and is impossible to create on the morning the laptop is a brick. Make one per site, label it with the date, and store it somewhere that isn’t the desk of the machine it exists to recover.
Do one full restore onto spare hardware — once, on purpose
The step everyone skips, and the only one that turns “we have backups” into “we can recover.” Take an old machine or a spare disk, restore a whole image onto it, boot it, log in. Time it: that number is your real RTO, and it is usually a surprise. Once a year is enough. Zero times is not.
Write the one-page runbook: who calls whom, in what order
Who notices. Who decides to pull machines off the network. Who runs the restore. Who tells customers, and who calls the insurer or the bank. Names and mobile numbers, not job titles. Restore order, so nobody has to choose under pressure. Where the media and credentials live. Then print it.
Put a review date in the calendar — and one after every change
Twice a year, plus any time you add a machine, move a database, switch provider, or somebody with the keys leaves. Re-read this list, confirm coverage still matches the inventory from item 01, and re-run the file restore. Plans don’t rot loudly; they just quietly stop matching the business.
Take the checklist with you
The printable two-page PDF — same 14 checks, ready for a clipboard or a team meeting.
We make disaster recovery software. Here’s where that’s relevant, and where it isn’t.
Genie9 has been building data protection since 2006, so treat this section as disclosure rather than advice. The checklist above is deliberately tool-agnostic — the principles hold whatever you run, including free utilities you may already have.
Two boxes are genuinely awkward to tick without a purpose-built tool: whole-machine imaging (item 05) and detection that protects the backup rather than just alerting you (items 07 and 08). BigMind DR covers both on its free tier: $0 for one user and one device, daily whole-machine imaging to your own external disk or NAS, seven recovery points, bootable USB recovery that works on different hardware, and the canary detection described in item 07 included. Windows and Linux. Your backup data stays on your own storage; you manage it from a cloud dashboard.
Other tools cover parts of this too, and that’s fine. The checklist matters more than the logo on it.
If you want the reasoning behind an item
Working through this with a team? This page prints cleanly on two sides of A4.