Backup vs. Disaster Recovery: RTO & RPO with Real Scenarios
If you remember one thing from this article, make it this: backup is a copy of your data; disaster recovery is a plan to get your business working again. They are not the same thing, and the gap between them is measured in days of downtime. Backup answers "did we lose the data?" Disaster recovery answers "how long until my team can send invoices, take calls, and serve customers again?" Most Sacramento small businesses have some version of the first and almost none of the second.
I've been in IT since 1996, and the pattern hasn't changed: nobody budgets for recovery until the week after they needed it. Let's fix that with plain definitions, a side-by-side comparison, and some honest math.
What do RTO and RPO actually mean?
RTO (Recovery Time Objective) is the maximum time your business can be down before the damage becomes unacceptable — "we need to be working again within 4 hours." RPO (Recovery Point Objective) is how much recent data you can afford to lose — "we can re-do the last hour of work, but not the last day." RTO is about time offline; RPO is about work lost. Every backup and recovery decision flows from these two numbers.
Here's the practical way to find yours:
- RTO question: "If every computer and server went dark right now, how many hours until we're losing serious money or clients?" For a CPA firm facing a filing deadline, that might be two hours. For a construction office, maybe a full day. (We see both — more on that at /industries/cpa-financial/ and /industries/construction/.)
- RPO question: "If we had to restore from last night's backup, could the team accurately reconstruct today's work?" If your books, timekeeping, or client records change constantly, a 24-hour RPO means real losses.
Tighter RTO and RPO cost more to achieve. That's not a sales line — it's physics. Restoring faster requires standby infrastructure; losing less data requires more frequent backups. The goal isn't "zero and zero," it's matching the spend to what downtime actually costs your business.
Backup vs. disaster recovery: what's the real difference?
Backup protects data; disaster recovery restores operations. A backup gives you files sitting safely somewhere. Disaster recovery adds everything needed to turn those files back into a working business: replacement or virtual servers, reinstalled applications, network and email access, a documented order of restoration, and tested procedures. Backup is a component of disaster recovery — necessary, but nowhere near sufficient.
| Backup | Disaster Recovery | |
|---|---|---|
| What it is | Point-in-time copies of data | Full plan + infrastructure to resume operations |
| Answers | "Is our data safe?" | "How fast are we working again?" |
| Typical scope | Files, databases, mailboxes | Servers, apps, network, phones, people, process |
| Key metric | RPO (data loss window) | RTO (downtime window) |
| Failure it handles | Deleted files, corruption, ransomware-encrypted data | Server death, fire, flood, ransomware taking the whole network |
| Without it, you get | Permanent data loss | Days of downtime even with good backups |
| Tested by | Restoring sample files | Full recovery drills, timed |
The classic trap: an owner hears "yes, we have backups" and assumes recovery is handled. Then the server dies, and everyone discovers that ordering hardware, rebuilding the operating system, reinstalling applications, and then restoring data takes three to five business days.
What does downtime actually cost? Three hypothetical scenarios
Downtime cost is idle payroll plus lost revenue plus recovery labor plus reputation damage. Industry surveys routinely place small-business downtime at hundreds to thousands of dollars per hour — but generic figures matter less than your own math. The scenarios below are hypothetical illustrations built from industry-typical numbers, not client stories, and they show how quickly the total climbs.
Scenario 1: The dead server with backup-only protection. A hypothetical 15-person accounting office has nightly cloud backups but no recovery plan. The aging server's RAID controller fails on a Tuesday in March — peak season. Replacement hardware takes two days to arrive; rebuild and restore take another day. Math: 15 staff × $45/hour loaded cost × 24 working hours ≈ $16,200 in idle payroll, plus roughly $10,000–$20,000 in delayed billable work, plus emergency IT labor commonly billed at $150–$250/hour. Total: $30,000+ — and the data was never lost. That's the backup-vs-DR gap in one invoice.
Scenario 2: Ransomware with sync-only "backups." A hypothetical 30-person construction firm relies on OneDrive sync. Ransomware encrypts the files, and the sync dutifully replicates encrypted versions everywhere. Industry reporting has put typical small-business ransomware recovery costs — downtime, rebuild labor, and lost work combined — well into five and sometimes six figures, with average downtime frequently reported at two to three weeks. Even at the modest end: 30 staff × $40/hour × 80 hours = $96,000 in payroll alone over two weeks, before any ransom question comes up. Proper immutable, versioned backups plus a recovery runbook turns this into a one-to-two-day event.
Scenario 3: Same failure, with real disaster recovery. Take the same 15-person office from Scenario 1, but with image-based backups replicating to a cloud recovery environment, a 4-hour RTO, 1-hour RPO, and an annually tested runbook. The server dies at 9 a.m.; the virtualized replica is running by lunch. Cost: about $2,700 in partial-day disruption. The difference between Scenario 1 and Scenario 3 — roughly $27,000 on a single incident — typically dwarfs years of the cost difference between backup-only and full DR protection.
Not sure which scenario your current setup would produce? Book a free IT assessment and we'll map your real RTO and RPO — no obligation, no jargon.
How do you right-size backup and DR for a small business?
Start from your downtime cost, not from a product brochure. Calculate your hourly cost of downtime (idle payroll + lost revenue estimate), decide your honest RTO and RPO, and then build to those numbers — no tighter, no looser. Most 5–100 employee businesses land on tiered protection: fast recovery for the two or three systems that run the company, standard nightly protection for everything else.
A sensible baseline for most Sacramento small businesses looks like:
- 3-2-1 rule: three copies of data, two different media/platforms, one off-site (and today, one immutable copy ransomware can't encrypt).
- Image-based backups of servers and critical workstations, not just files — so you restore a working machine, not a folder.
- Microsoft 365 backup — your email and SharePoint data isn't automatically backed up the way most owners assume (see /services/cloud-microsoft-365/).
- A written, one-page recovery runbook: what gets restored first, by whom, and how staff work in the meantime.
- Scheduled restore tests with the results actually reviewed. Untested backups fail at a rate that should scare you.
This is exactly the kind of design work covered in our backup and disaster recovery service, and for clients on managed IT services the testing and monitoring happen automatically rather than "when someone remembers."
When should you review your recovery plan?
At least once a year, and any time the business changes shape — new line-of-business software, a move to the cloud, an acquisition, doubling headcount. RTO and RPO are business numbers, not IT settings, so revisit them when the business's tolerance for downtime changes. A plan written three years ago for a 10-person office does not fit the 40-person company you've become.
The good news: getting this right is not exotic. It's a few honest conversations, some math on a napkin, and a setup that gets tested instead of trusted. If you'd like a second set of eyes on yours, we're a Sacramento-based team and happy to take a look — read more about how we approach backup and disaster recovery.