"We have backups" is one of the most common sentences in IT, and one of the least useful on its own. A backup is a copy of your data sitting somewhere. Disaster recovery is the actual, tested ability to get your business back to running from that copy, within a timeframe you can survive. Businesses discover the gap between those two things at the worst possible moment: mid-incident.
Three ways "we have a backup" quietly fails
- The backup itself was never tested. Backup jobs can report “success” for months while silently failing to capture usable, restorable data: corrupted files, missed folders, a broken connector nobody noticed. The only way to know a backup actually works is to restore from it and check.
- The backup wasn’t protected from what it was meant to protect against. Ransomware that reaches a network-attached backup drive, or a cloud backup with the same credentials as the systems it’s backing up, can be encrypted or deleted right alongside the data it was supposed to save. Immutable, air-gapped backups exist specifically to close this gap.
- Nobody documented how to actually use it. Restoring one accidentally deleted file is simple. Rebuilding a server, a domain, or an entire office’s worth of systems from scratch, in the right order, with the right dependencies, under pressure, is a completely different exercise, and one that goes far more smoothly with a written runbook than without.
RTO and RPO, in plain English
Two numbers matter more than any other backup detail: Recovery Time Objective (how long can you survive being down?) and Recovery Point Objective (how much recent data can you afford to lose, an hour's worth, a day's?). Most businesses have never actually set these numbers; they've just assumed "as fast as possible" and "none," which isn't a plan, it's a hope. Defining them properly is what turns a backup into a recovery strategy, because the answer directly shapes what kind of backup and infrastructure you actually need.
Four questions worth asking about your current setup
- When did we last actually restore something from backup, not just check that the job ran?
- If ransomware hit our main systems tonight, could our backups also be reached and encrypted?
- Do we know our real recovery time, in hours, or are we assuming?
- Is there a written plan our team has actually seen, or does recovery live in one person’s head?
The reframe that actually matters
Backup is a technical control. Disaster recovery is a business decision about how much downtime and data loss you can actually absorb, backed by a tested, documented plan to hit that target. If you've only ever addressed the first one, you don't have a disaster recovery plan yet. You have a hope, and a bill for cloud storage.