It is a normal Tuesday until it is not. Someone tries to open the accounting system and gets an error. A few minutes later it is clear the main server is not coming back. Maybe a drive failed. Maybe a staff member deleted the wrong folder. Maybe a message on the screen is demanding payment in bitcoin to unlock your own files. Whatever it is, the business has stopped, and everyone is looking at you.
The work that decides how this day ends was done weeks or months earlier, quietly, when nothing was on fire. Disaster recovery is not what you do when the server dies. It is what you set up so that the day it dies is survivable.
Most businesses think they have this covered because they have a backup somewhere. Often they do not have what they think they have. So let us walk through what actually keeps you safe, in plain language, before you are the one staring at that error message.
A backup is not a recovery plan
These two get confused constantly, and the difference matters enormously on the bad day. A backup is a copy of your data. A disaster recovery plan is the full set of steps that gets your business running again: which systems come back first, who does what, where the spare hardware comes from, how long it all takes.
You can have perfect backups and still be down for a week because nobody knew how to restore them, or onto what. A backup is one ingredient. The plan is the recipe. You need both.
Hope is not a plan, and a backup nobody has ever restored is not a backup. It is a guess wearing a reassuring label.
The 3-2-1 rule
If you remember nothing else, remember this. It is the simplest sound rule for backups, and it has saved countless businesses:
- 3 copies of your important data, including the live one you work on every day.
- 2 different types of storage, so a single kind of failure cannot wipe out everything at once.
- 1 copy offsite, somewhere away from the office, so a fire, theft or flood at your premises does not take your only safety net with it.
A single external drive sitting next to the server fails all three. The same fire, the same thief, the same ransomware reaches both at once. The offsite copy is the part people skip, and it is the part that matters most when things go really wrong.
How long can you be down, and how much can you lose?
These two questions sound technical but they are pure business decisions, and they drive everything else. The jargon for them is RTO and RPO, and they are simpler than they sound.
- RTO, recovery time objective. How long can you be down before it really hurts? An hour? A day? Three days? Be honest about what each one costs you in lost trade and lost trust.
- RPO, recovery point objective. How much recent work can you afford to lose? If your last backup was last night, anything done today is gone. Is losing a day acceptable, or do you need backups every hour?
Tighter answers cost more to deliver, so this is a trade-off, not a wish list. But until you have answered both, nobody can design the right setup, and you will not know whether what you already have is good enough.
Test it, or it is not real
An untested backup is not a backup, it is a hope. The only way to know your backups work is to actually restore from them, on purpose, while everything is calm. We have seen backups that ran faithfully every night for two years and turned out to be empty. Test quarterly. Find the problem on a quiet afternoon, not on the worst day of your year.
Ransomware changes the rules
Ransomware is now one of the most common ways businesses lose data, and it is nasty precisely because it goes after your backups too. Modern attacks deliberately encrypt or delete every backup they can reach over the network before they reveal themselves. If your backup is always connected and always reachable, it can be encrypted right along with everything else.
The defence is an offsite copy that the attack cannot touch: one that is disconnected, or held somewhere separate with its own access. That untouchable copy is often the difference between restoring in a day and paying a criminal with no guarantee you get anything back.
The local hazards: power and connectivity
Here at home we add load-shedding to the list. A server losing power mid-write can corrupt data, so a UPS to ride out the gap, and a clean shutdown when the battery runs low, is basic protection rather than a luxury. If your backups or recovery depend on the internet, plan for the connection being down during the exact emergency you need it for.
A simple DR checklist
You do not need a thick binder. You need clear answers to a handful of questions, written down where you can find them when the screens are dark:
- What are our most critical systems, in order of which must come back first?
- Do we follow 3-2-1, with a genuine offsite and an untouchable copy?
- What is our agreed RTO and RPO, and does our setup actually meet them?
- When did we last successfully restore from backup, and who can do it?
- Who do we call, and in what order, on the day it happens?
Work through those once, fix the gaps, and revisit them every few months. It is not glamorous work and it never feels urgent. But the businesses that do it walk away from a dead server with a bad afternoon, while the ones that did not are fighting for their survival. The cheap insurance is the boring kind, bought before you need it.
