Backups aren't recovery: the restore gap that sinks response plans
Key takeaways
- The most common cause of extended downtime isn't missing backups — it's untested recoverability nobody discovered until the live incident.
- If you can't cite a full-restore time from a test in the last quarter, you have a guess, not a recovery time objective.
- Immutable copies protect against encryption; a rehearsed, documented restore sequence protects against surprise. You need both.
The gap nobody sees until it's too late
In post-incident reviews, the single most common cause of extended downtime isn't a failure to have backups at all — it's a gap between backup existence and tested recoverability. Organizations discover during a live incident that their backup jobs had been silently failing for a subset of systems, that restore times are far longer than assumed, or that the restore sequence itself was never documented.
A test that exposes the truth
A useful diagnostic: if your organization cannot state, with evidence from a test performed in the last quarter, how long a full restore of your core systems actually takes — you do not have a recovery time objective, you have a guess. And guesses tend to be optimistic by a factor of three when the servers are actually down and the phones are ringing.
Two different protections, both required
Immutable, offline backup copies close the exposure to encryption; a rehearsed, documented, and recently tested restore sequence closes the exposure to unpleasant surprises about how long recovery actually takes. Both are required — neither substitutes for the other. A perfect immutable backup you've never restored from is still an untested assumption, and a well-rehearsed process pointed at backups the attacker encrypted is worthless.
