"We have backups" is one of the most common — and most misleading — answers a business gives when asked how it's protected against data loss. Backups and disaster recovery solve different problems, operate on different timelines, and protect against different kinds of failure. A business that has one but not the other has a real gap, and usually doesn't find out until it needs the piece it doesn't have.
What backup actually protects against
Backup is a copy of your data, taken on a schedule, stored somewhere separate from the original. It protects against data loss: a deleted file, a corrupted database, ransomware that encrypts your working files, an employee who overwrites something important. If something goes wrong with the data itself, you restore from a clean copy.
What backup does not do is keep your business running while that restore happens. If your primary server fails entirely, having a backup of its data tells you your files are safe — it doesn't tell you how long it will take to get a system back online to actually use them, or what your team does in the meantime.
What disaster recovery actually protects against
Disaster recovery (DR) is a plan — and the infrastructure to execute it — for keeping the business operating, or getting it back online within a defined time, when a larger failure takes out systems entirely: a server room fire, a regional outage, a ransomware attack that disables infrastructure rather than just encrypting files, or a natural event that takes out a physical office. DR is measured in two numbers that backup alone doesn't address:
- Recovery Time Objective (RTO) — how long it takes to get systems back online
- Recovery Point Objective (RPO) — how much data (measured in time) you can afford to lose
A backup taken once a night has an RPO of up to 24 hours — if failure happens at 4pm, you lose the day's work. A business running a live order system might find that unacceptable, while a small internal tool might find it perfectly fine. The right answer depends on the system, not a blanket policy applied everywhere.
Where the confusion causes real damage
The costliest version of this mistake shows up during ransomware incidents. A business restores from backup, confirms files are intact, and assumes the crisis is over — without a DR plan for how compromised systems get rebuilt safely, so the same vulnerability that let the ransomware in the first time gets reintroduced. Backup restored the data. It didn't recover the business. Reducing that entry-point risk in the first place is covered in reducing phishing risk, since phishing remains the most common way ransomware gets a foothold.
Building both, properly sized
Neither backup nor DR needs to be enterprise-grade to be effective — it needs to match what the business can actually tolerate losing, in time and in data. A practical approach:
- Classify systems by how quickly the business needs them back — customer-facing and revenue systems first
- Set a different RTO/RPO target for each tier, rather than one target for everything
- Test restores on a schedule, not just backup completion — a backup that has never been restored is unverified
- Store backups somewhere genuinely separate from production, so one incident can't take out both
- Document who does what during a recovery event, in writing, before it's needed
A backup you have never restored is a hope, not a plan.
This is where cloud solutions genuinely change the economics — cloud-based backup and DR give smaller businesses access to geographically separated storage and fast failover that used to require a second physical data center. Getting the infrastructure right also depends on not overbuilding it, which is exactly the balance we walk through in right-sizing cloud infrastructure.
If you're not sure whether your current setup is backup, DR, or somewhere in between, that's worth finding out before an incident forces the answer. Contact us for a plain-language review of what you actually have in place.