Let’s start with the line that saves businesses: a backup is not a disaster recovery plan. A backup is a copy of your data. Disaster recovery is the complete plan for getting your business running again, which systems come back first, how fast, who’s responsible, and where your team works in the meantime. Plenty of companies have backups and still get crippled for a week, because nobody planned the recovery. This guide is about building the plan, not just the copy.
Why “we have backups” isn’t enough
When something goes wrong, ransomware, a dead server, a flood, a backup answers exactly one question: is the data still there? That’s necessary, but it’s nowhere near sufficient. A real disaster raises a pile of other questions:
- How long until people can actually work again?
- Which systems matter most and should come back first?
- Where does the team operate if the office is unusable?
- Who is in charge, and who do we call?
- How much recent work did we lose?
A backup answers none of those. A disaster recovery plan answers all of them. The federal Ready.gov business continuity program offers free templates for building one. The difference between a business that’s down for two hours and one that’s down for two weeks usually isn’t whether they had backups. It’s whether they had a plan around those backups.
Two businesses, one disaster, very different mornings
To see why the plan matters as much as the copy, imagine the same ransomware attack hitting two similar companies on the same night. Both have backups. Company A has only backups: their data is technically safe, but when they arrive Monday to locked systems, nobody knows which systems to restore first, where the recovery procedures are written down, who’s in charge, or where people should work while the office systems are rebuilt. They improvise for days. The restore order is wrong, so the team sits idle waiting on a system that wasn’t actually urgent. A week later they’re limping back, having lost real revenue and a few customers along the way. Company B has a plan: within an hour they’ve declared the incident, the designated lead is running a documented playbook, the customer database and email come back first because they were ranked first months ago, staff are working from a predetermined backup arrangement, and clear updates are going out to customers. By the next morning they’re substantially operational. Same attack, same backups, same data — wildly different outcomes, decided entirely by whether a plan existed before the crisis. That gap is the whole reason this guide exists.

The 3-2-1 rule: the foundation of good backups
Before we get to recovery, your backups have to be sound, and there’s a simple, proven standard for that: the 3-2-1 rule.
- 3 copies of your data (the original plus two backups)
- 2 different types of storage (so one storage failure doesn’t take out everything)
- 1 copy offsite or otherwise isolated from your main network
Why isolation matters so much: modern ransomware specifically hunts for and encrypts connected backups. If every copy you have is reachable from your network, an attack can take them all at once. That one offsite, isolated copy is the lifeboat that survives when everything else goes down. This is the backbone of proper backup and disaster recovery, and it’s the same principle behind ransomware resilience.
RTO and RPO: the two numbers that define your plan
Every disaster recovery plan rests on two numbers. Set them honestly and everything else falls into place. Ignore them and you’ll either overspend or get caught short.
RTO, Recovery Time Objective: how quickly you need to be back up. Can your business tolerate being down for a day? An hour? Five minutes? The shorter your RTO, the more you’ll invest in fast-recovery infrastructure.
RPO, Recovery Point Objective: how much data you can afford to lose, measured in time. If your backups run nightly and disaster strikes at 4pm, you’ve lost a full day of work. If that’s unacceptable, you need more frequent backups, hourly or continuous.
| RTO (Recovery Time Objective) | RPO (Recovery Point Objective) | |
|---|---|---|
| Question it answers | How fast must we be back up? | How much data can we afford to lose? |
| Measured in | Time to restore operations | Time between backups |
| A tighter target means | Faster (and usually pricier) recovery infrastructure | More frequent backups |
| Example: online store | 15 minutes | Near-zero (continuous) |
| Example: shared file archive | 24 hours | Nightly |
Here’s the practical part: not everything needs the same numbers. Your customer database might need an RTO of minutes and near-zero data loss. The folder of old marketing files can probably tolerate a day. Setting these per system keeps you from overpaying to protect things that don’t need it.
A worked example of RTO and RPO
Let’s make these two abstractions concrete with a small e-commerce business. Their online store is the lifeblood — every minute it’s down is lost sales — so it gets an aggressive RTO of, say, fifteen minutes and an RPO measured in minutes, which means continuous replication and fast failover. Their order database is nearly as critical, so it gets a similar tier. Their internal email matters but the business survives an hour without it, so a one-hour RTO and hourly backups are fine. The shared drive of design files and old documents? A day of downtime would be annoying but not damaging, so a 24-hour RTO and nightly backups are perfectly adequate. Notice what this exercise does: it stops you from the two classic mistakes — spending a fortune giving everything minute-by-minute protection it doesn’t need, or worse, discovering during a disaster that the system you most depend on was only backed up once a night. The single most useful planning conversation a business can have is walking through each critical system and honestly asking, “How fast must this come back, and how much of it can we afford to lose?” Those answers, not the technology, drive the whole plan.
What a real disaster recovery plan includes
A complete plan goes well beyond “restore the files.” It spells out:
- Priorities. A ranked list of which systems come back first. When everything’s down, you can’t fix everything at once, so decide the order before the crisis, not during it.
- Roles. Who declares a disaster, who runs the recovery, who talks to staff and customers. Panic and confusion cost time; clear roles prevent both.
- Procedures. The actual steps to restore each critical system, documented so they don’t live only in one person’s head.
- Communication. How you’ll keep employees, customers, and partners informed while you recover.
- Alternate operations. Where and how the team works if the office or main systems are unavailable.
- Testing schedule. When and how you’ll prove the plan actually works.
That last point is where most plans quietly fail.

Test it, or you don’t really have it
I’ll say it plainly: an untested backup is just a hope, and an untested recovery plan is just a document.
The number of businesses that discover their backups were silently failing, or that recovery takes three times longer than assumed, during an actual disaster is heartbreaking. By then it’s too late.
Testing means actually performing a restore, on a schedule, and confirming three things: the data is really there, it’s complete, and you can bring it back within your target RTO. At minimum, test quarterly. For critical systems, test more often. A plan you’ve never rehearsed is a plan you don’t really have.
Common disaster recovery mistakes
The patterns that catch businesses off guard, over and over:
- Backups all in one place. If your only backup is on a drive in the same office as the original, one fire or flood takes both. Isolation is the whole point.
- Never testing. Covered above, but it’s the number one failure, so it’s worth repeating.
- No documented plan. Recovery knowledge living in one person’s memory is a disaster of its own when that person is unreachable.
- Forgetting cloud data. Assuming Microsoft 365 or Google Workspace backs itself up. As we covered in our Microsoft 365 guide, your cloud data is your responsibility, not the provider’s.
- Set-and-forget. Your business changes; your plan has to change with it. A plan written three years ago for systems you no longer run won’t save you.
The cloud-backup blind spot, explained
The “forgetting cloud data” mistake deserves a closer look because it catches so many smart businesses off guard. There’s a widespread and entirely understandable assumption that once your email and files live in Microsoft 365 or Google Workspace, they’re automatically backed up — the data’s “in the cloud,” after all. But that’s not what those providers actually promise. They guarantee the availability of their service; they don’t guarantee they’ll bring back data you lost. If an employee deletes a critical folder, a departing staffer wipes their mailbox, or ransomware encrypts files that then sync to the cloud, the provider’s stance is essentially: that was your data and your action, not our outage. Once their short retention window passes, it’s gone. This is known as the shared-responsibility model, and the part most businesses miss is that protecting the contents of their cloud accounts falls on them. The fix is straightforward — a dedicated third-party backup of your Microsoft 365 or Google Workspace data — but you have to know you need it. Assuming the cloud has you covered is one of the most common and most painful gaps we find, precisely because it feels so safe right up until the day it isn’t.
The bottom line
Backups answer “is the data safe?” Disaster recovery answers “how fast can we get back to business?” You need both, and the second is the one most businesses are missing. Build sound backups on the 3-2-1 rule, define your RTO and RPO honestly, document a real recovery plan with priorities and roles, and then, crucially, test it.
Do that, and a disaster that would close some competitors becomes, for you, a controlled, recoverable event. That resilience is the entire point.
If you’re not confident your backups would actually restore, or you’ve never put a real recovery plan to the test, that uncertainty is the risk. Get a free continuity assessment and we’ll review your backups, your recovery readiness, and your real-world RTO, then tell you exactly where the gaps are before a bad day finds them for you.
