Disaster recovery planning fails when it starts with technology. It works when it starts with a question nobody enjoys answering: which systems, if unavailable, stop the business earning?
Step 1: Classify, and be ruthless
List every system. Put each in one of three tiers:
- Critical. The business stops. Usually a small list — the system that takes orders or runs operations, and the data behind it.
- Important. Painful but survivable for a day or so. Email, internal tools.
- Deferrable. Can wait a week.
The discipline is in keeping tier one short. Everything feels critical to the person who owns it; if half the list is tier one, the classification has not been done.
Step 2: Set RPO and RTO per tier
Recovery point objective: how much data you can afford to lose, measured in time. Recovery time objective: how long you can be down.
These are business decisions, not technical ones, and they need agreement from whoever carries the risk. Ask directly: "if we lost four hours of orders, what happens?" The answer sets the target.
Without written targets, no backup arrangement can be evaluated — there is nothing to evaluate it against.
Step 3: Match strategy to target
Cost rises steeply with ambition, which is why the tiering matters:
- Backup and restore. Cheapest. Recovery measured in hours to a day. Adequate for most small business tier-one systems, and genuinely fine.
- Pilot light. Core components kept running minimally elsewhere, ready to scale up. Recovery in hours, at moderate standing cost.
- Warm standby. A scaled-down copy running continuously. Recovery in minutes, at substantial cost.
- Active-active. Full capacity in two places. Near-zero recovery, highest cost by a wide margin.
Most small businesses need backup-and-restore done properly, not a standby environment done badly. Doing the cheap option well beats doing an expensive one half-configured.
Step 4: Make backups survive the incident
A backup reachable from the compromised system is a backup that gets encrypted with everything else. Three properties matter:
- Separate credentials. If one compromised login deletes both data and backups, you have no backups.
- Immutable and versioned. Copies that cannot be altered or deleted for a set period, even with valid credentials. This is the specific defence against ransomware.
- Geographically separate. Different region or different provider, so a regional failure does not take both.
Step 5: Write the runbook
A document someone who is not you can follow, containing: the order systems come back in and why, where credentials are kept, who to contact at each vendor, and how to verify each system is genuinely working rather than merely running.
Store it where it is reachable when your primary systems are down. A runbook on the file server that is offline is not a runbook.
Step 6: Test, and record what the test revealed
Restore a tier-one system to an isolated environment. Time it. Note everything missing, wrong, or needing a person who was not available.
Compare against your RTO. If the test took twice as long as the target, either the target or the arrangement needs to change — and finding that out now is the entire point.
Annually at minimum. After any significant infrastructure change as well, because plans go stale quietly.
The part people leave out
Communication. In a real incident, staff, customers and suppliers all need to know something. Decide in advance who says what, through which channel, and who approves it.
Note that your usual channel may be affected — if email is down, an email-based plan does not work. Have a second route agreed.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
