“We have backups” is one of the most common things a business owner tells me, and it is usually true. What is far less common, and far more important, is having actual disaster recovery. The two words get used interchangeably, and that confusion is how businesses end up technically backed up and practically stranded.
Here is the difference, in plain terms, and why it decides how a bad day actually goes.
Backup is a copy. Disaster recovery is a plan.
Backup answers one question: do I still have my data? It is a copy of your files, your databases, your systems, stored somewhere other than the original. If a hard drive dies or a file gets deleted, you pull the copy. Good backup is necessary. It is the floor.
Disaster recovery answers a much harder question: how fast can I be running again, and how much will I lose getting there? It is the whole plan for getting the business operational after something goes wrong: which systems come back first, how, in what order, who does what, and how long it takes. Backup is the parts in the box. Disaster recovery is the instructions for putting the machine back together while the clock is running and customers are calling.
You can have excellent backups and terrible disaster recovery. That is, in fact, the most common situation we find.
The two numbers that define disaster recovery
Disaster recovery gets concrete through two measurements. Once you understand them, you can size up any plan in a minute.
RPO, Recovery Point Objective: how much data can you afford to lose? If your last backup ran at midnight and disaster strikes at 4 p.m., you have lost sixteen hours of work. Your RPO is how big that gap is allowed to be. A law firm that bills by the tenth of an hour and a coffee shop have very different acceptable answers. RPO is set by backup frequency: backups every night give you a day-sized RPO; continuous replication gives you a minutes-sized one.
RTO, Recovery Time Objective: how long can you be down? From the moment disaster hits to the moment you are functioning again. If restoring your server from backup takes eighteen hours because the data has to download over a slow connection, your RTO is at least eighteen hours, no matter how good the backup is. RTO is set by how your recovery actually works, not by how your backup works.
Two businesses can have identical backups and wildly different RTOs. The one with a tested recovery plan and a local copy ready to spin up is back in two hours. The one re-downloading everything over the internet and figuring it out as they go is down for two days. Same backup, very different week.
”Backed up” can still mean “out of business for a week”
Picture a real scenario. A small Anchorage firm backs up faithfully to a cloud service every night. They feel covered, and on the data question, they are. Then their server dies on a Monday morning.
Now the gaps show. The backup has to be downloaded, hundreds of gigabytes over a business internet connection that was not built for it. Nobody has ever tested a full restore, so the first attempt fails on a setting nobody documented. There is no spare server to restore to, so one has to be sourced. The owner is improvising the recovery sequence in real time while the whole team sits idle and clients go unanswered.
Every file was backed up. The business still lost most of a week. That gap, between having the data and being able to use it, is exactly the space disaster recovery is supposed to fill.
How to tell which one you actually have
Ask yourself, honestly:
- Has anyone ever performed a full test restore? Not “the backup says it succeeded,” but actually restored everything and confirmed it works. An untested backup is a hope, not a plan.
- Do you know your RTO and RPO? If you cannot say roughly how long recovery takes and how much data you would lose, you have backup, not disaster recovery.
- Is there a documented recovery order? Which system first, who does what, what depends on what.
- Is there somewhere to recover to? A local appliance or cloud failover that can run your systems, not just hold the files.
- Is at least one copy isolated from ransomware? A backup reachable from an infected network gets encrypted right along with everything else.
If you answered “no” to most of these, you are in the very common position of being backed up but not recoverable. That is a fixable gap, and a cheap one to fix relative to the cost of finding out the hard way.
What good looks like
Proper disaster recovery for a small business is not enterprise-grade complexity. It is: backups frequent enough to hit your RPO; at least one copy isolated where ransomware cannot reach it; a recovery target that can actually run your systems; a written, ordered recovery plan; and, the part everyone skips, regular tested restores so you know it all works before you need it.
That last point is the whole game. A backup you have never restored is a guess. We test restores for managed clients on a schedule, so the answer to “would it work” is “yes, we checked last quarter,” not “we think so.”
If you are not sure which side of this line you are on, the free IT Health Check includes verifying whether your backups would actually restore and roughly what your real RTO and RPO are today. It is a thirty-minute conversation that has saved more than one Anchorage business from a very expensive week.