Backup vs. disaster recovery: what's the difference?

Backups are copies. Disaster recovery is a plan.

A backup answers one question: does a second copy of the data exist? Disaster recovery answers the questions that actually determine whether your business survives a bad week: How fast can we run again? On what hardware? Restored by whom? In what order? A pile of backups without those answers is an ingredient, not a meal.

The gap shows up in practice like this: the server dies, the backups are intact, and it still takes four days to be operational — because nobody knew the restore would need replacement hardware with a lead time, or that the backup didn't include the application's license configuration, or that the one person who understood the system was on vacation. The data survived; the week didn't.

The two numbers that define your plan: RPO and RTO

Disaster recovery planning reduces to two numbers you choose in advance:

• RPO — recovery point objective. How much recent work you can afford to lose. Nightly backups mean an RPO of 24 hours: a failure at 4pm loses the day. If losing a day of invoices or case notes is unacceptable, your critical systems need more frequent protection.
• RTO — recovery time objective. How long you can afford to be down. If the honest answer is "a day, at most", your plan must be tested to hit that — restore speed, spare hardware or cloud failover, and someone available to execute it.

The two numbers trade against cost. An RPO of minutes and an RTO of an hour is achievable — for a price most 20-person companies shouldn't pay. The point isn't tight numbers; it's chosen numbers, agreed by the owners, written down, and tested against reality. Unstated targets always default to "we find out during the disaster".

The minimum setup worth having

For a typical small business, this is the floor we consider defensible:

• 3-2-1 backups: three copies, two different media, one offsite — with the offsite copy disconnected or immutable, so ransomware can't encrypt it along with everything else.
• Cloud data included: Microsoft 365 and Google Workspace don't back themselves up. Cloud-to-cloud backup covers mail, drives and shared sites for a few dollars per user.
• Quarterly restore tests, logged: one file, one mailbox, one full system — timed. An untested backup is a hypothesis, and the test log is what your insurer will ask for.
• A one-page written plan: who declares the disaster, who restores what and in what order, where credentials live, who calls clients and the insurer. Printed — the wiki may be down too.

This is exactly what our backup & disaster recovery service implements, and the discipline that made the difference in our construction ransomware case study: recovery went smoothly because it had been rehearsed, not because anyone got lucky.

What actually triggers a restore

It's worth knowing what you're really planning for. In our experience the disasters that hit small businesses are, in rough order of frequency: accidental deletion or overwrite (weekly, somewhere), hardware failure, ransomware, a departing employee taking or wiping data, and — far behind — the fire or flood everyone pictures first. Notice that most of these destroy data without touching the building, which is why "the server room is fireproof" isn't a plan, and why the offsite copy must be disconnected from the network rather than just distant from the office.

The takeaway

Ask two questions at your next management meeting: "How much work would we lose if a server died right now?" and "How long until we're running again — and who has tested that?" If the answers are guesses, you have backups but not disaster recovery. Setting real targets takes one conversation; our free assessment will tell you what your current setup can actually deliver, in writing, before you need it to.