A backup answers "do we have the data?" A disaster recovery plan answers "how do we keep the business running when everything goes sideways?" Those are very different questions.
Every business owner we talk to says some version of the same thing: "We have backups, so we're covered." And we get it — backups feel like the responsible thing to have. You set them up, you (hopefully) get the daily confirmation emails, and you sleep a little easier knowing your data is safe somewhere.
But here's the question we always ask next: if your server died right now, completely, how long would it take to get your business back to fully operational? Not "how long until you have the data back" — how long until your employees can actually work, your customers can reach you, and your revenue-generating processes are running again?
Most business owners don't know the answer. And that's exactly the problem. A backup is a piece of data. A disaster recovery plan is the documented, tested process for getting your whole business back on its feet after something goes badly wrong. After 30+ years of helping businesses through everything from ransomware attacks to flooded server rooms, I can tell you: the ones who came through the fastest all had a plan. The ones who suffered the most had only a backup.
Disaster recovery (DR) is the set of policies, tools, and procedures that enable your business to restore IT operations after a disruptive event. That event could be a ransomware attack, a hardware failure, a power surge, a fire, a flood, or simply an employee accidentally deleting a critical database. The category doesn't matter much — what matters is how prepared you are to respond.
Business continuity is the broader concept: not just recovering your IT systems, but keeping your business operational during and after a disruption. DR is a subset of business continuity, focused specifically on the technology side.
Before you can build a DR plan, you need to understand two terms. They sound technical, but the concepts are simple and extremely useful.
Recovery Time Objective (RTO) is the maximum amount of time your business can be down before the damage becomes unacceptable. How long can you go without your server, your email, your point-of-sale system, before customers leave and revenue stops? For some businesses, that's four hours. For others, it's four days. Your RTO defines how fast your recovery needs to be.
Recovery Point Objective (RPO) is the maximum amount of data loss your business can tolerate. If your backups run at midnight and your server crashes at 3pm the next day, you've lost 15 hours of work. Is that acceptable? If not, you need more frequent backups — maybe every hour, maybe continuous replication. Your RPO defines how often you need to back up.
Most small businesses have never thought about these numbers explicitly. But they're implicitly making a bet on them every day. Knowing your RTO and RPO lets you design a backup and recovery system that actually matches your business's real needs — not just whatever someone set up years ago.
A good DR plan accounts for multiple scenarios, because different disasters create different problems. Here are the ones we see most often with small businesses:
Servers fail. Hard drives fail. The older the hardware, the higher the probability. A good DR plan includes documented steps for what happens when the primary server dies: where do the backups live, how long does a full restore take, who performs it, and what do employees do in the meantime? See our post on hardware lifecycle planning for how to think about aging infrastructure before it becomes a crisis.
This is the one that keeps us up at night. Ransomware encrypts your files and demands payment. If your backup is connected to the same network as your infected systems, it can get encrypted too — which means your "backup" is also useless. A proper DR plan includes offline or immutable backups that ransomware can't reach, and a tested restore process you know works before you ever need it.
Someone deletes the wrong folder. Someone overwrites a critical file. Someone drops a database. These aren't dramatic events, but they're the most common data loss scenario we deal with. Your DR plan needs to address how quickly you can restore individual files or folders, not just the whole system.
Fire, flood, burst pipes, power failures. If your backup drive is sitting next to your server in the same room, a single facility event takes both out simultaneously. Offsite or cloud-based backups aren't optional — they're the minimum for true disaster recovery.
What happens if Microsoft 365 goes down for eight hours? If your internet provider goes dark? If a critical cloud service you depend on has an outage? A DR plan doesn't just cover your own systems — it identifies your key external dependencies and documents what you do when they're unavailable.
Here's what we include when we build a disaster recovery plan for a small business client. This isn't a 200-page enterprise document — a working DR plan for a 20-person company might be 8–12 pages. The point is that it's written down, it's specific, and it's been tested.
What systems, servers, applications, and data sources exist? You can't plan a recovery if you don't know what you're recovering. This includes on-premise hardware, cloud services, SaaS applications, and any critical data that lives on employee laptops.
Not everything is equally important. Group your systems by how quickly they need to be restored. Tier 1 might be your accounting system and your point-of-sale; without those, you can't do business. Tier 2 might be your file server. Tier 3 might be the HR portal you check twice a month. Recovery resources go to Tier 1 first.
Now assign specific numbers to each tier. Your Tier 1 systems might have a 4-hour RTO and a 1-hour RPO. Your Tier 3 systems might be fine with a 48-hour RTO and a 24-hour RPO. This shapes exactly which backup technology and infrastructure you need.
What's being backed up, where, how often, and using what tool? This shouldn't live only in your IT provider's head. Document it. This is where we also verify that your backups meet your RPO requirements — if your RPO is 4 hours but backups run once a day, there's a gap.
For each major failure scenario, write out exactly what happens. Who gets called first? What's the step-by-step process to restore systems? Where are the credentials stored? This document should be detailed enough that someone who's never done this before could follow it in a crisis — because that might be exactly what happens.
Who does what? Who calls the IT provider? Who communicates with customers? Who decides whether to pay a ransomware demand? Who has authority to approve emergency spending? If these questions don't have answers before the disaster, they'll create chaos during it.
If your email is down, how do you communicate internally? How do you notify customers? Do you have everyone's cell phone numbers written down somewhere offline? A communication plan sounds basic, but it's the piece that most small business DR plans skip — and the absence of it makes everything slower when it matters most.
Your IT provider's emergency number. Your internet provider. Your cloud vendor's support line. Your server hardware vendor's warranty/support contact. All of this should be in one place, in the DR plan, accessible even when your systems are down.
We've seen it too many times. A business builds a DR plan, files it away, and never thinks about it again. Then a real disaster hits, they pull out the plan, and discover that the backup software changed, the restore process doesn't work the way it's documented, and the contact list has three phone numbers for people who no longer work there.
A DR plan is only as good as the last time it was tested. Here's the minimum testing cadence we recommend for small businesses:
The quarterly restore test is the one most businesses skip. But it's the only way to know if your backups actually work. We've written more about why in our post on backup testing — if you're not testing restores, you may not have a real backup at all.
If this feels overwhelming, start with the most impactful pieces and build from there. Here's a practical sequence for a small business starting from scratch:
Week 1: Know your RTO and RPO. Have a 30-minute conversation with your team and your IT provider. How long can we be down? How much data can we afford to lose? Write the answers down. That alone will clarify a lot about what you need.
Week 2: Audit your backups. Find out exactly what's being backed up, how often, and where. Confirm that backups are going offsite or to the cloud — not just to a drive sitting next to the server. If there are gaps between your RPO and your actual backup frequency, that's your first fix.
Week 3: Write down the critical steps. For your single most important system, write down what you'd do if it failed tomorrow. Who calls who? What's the restore process? Where are the credentials? Get it on paper, even if it's rough. A rough plan is infinitely better than no plan.
Month 2: Expand and formalize. Apply the same thinking to your other critical systems. Add a communication plan. Add your vendor contacts. Get it into a document that more than one person has access to.
Ongoing: Test it. Schedule the quarterly restore. Put the annual tabletop on the calendar. Review the plan whenever something significant changes — new software, new staff, new hardware.
If you want outside help pulling this together, that's exactly the kind of work we do. We'll inventory your systems, identify your gaps, document the procedures, and help you test it. Check out our services page for more on what that engagement looks like, or just reach out and we'll talk through your situation.
Something will go wrong with your IT eventually. That's not pessimism — it's just reality. Hardware fails. Ransomware hits. People make mistakes. The question isn't whether you'll face a disruption; it's how long it will take to recover when you do.
The businesses that recover in hours instead of days aren't lucky. They did the work ahead of time. They know their RTO. Their backups are tested. Someone knows the procedure. There's a communication plan. When the disaster hits, they have something to execute against instead of starting from scratch under pressure.
Your backup is a good start. But if it's all you have, you have an ingredient — not a recipe. Build the recipe before you need it.