Backup and disaster recovery: the questions to ask before you need it
Almost every business believes it has backups. Far fewer have actually tested what those backups would mean in a real recovery — and that gap only surfaces at the worst possible moment.
Two numbers sit at the centre of any real disaster recovery plan, and most businesses have never explicitly set either one. Recovery Point Objective (RPO) defines how much data you can afford to lose, measured as the gap between your last clean backup and the moment things went wrong. Recovery Time Objective (RTO) defines how long you can afford to be down before the disruption becomes unacceptable to the business.
Why both numbers matter, separately
RTO measures forward from the incident: how long until systems are back. RPO measures backward: how much data between the last backup and the failure is gone for good. A business can hit its RTO — systems back up in the promised window — and still lose eight hours of transactions because the last backup ran the evening before. Meeting one target says nothing about the other.
The gaps that show up most often during onboarding
Backups that exist but have never been test-restored, so nobody actually knows if they'd work. A single backup copy stored in the same location or on the same network as the original — which ransomware that encrypts network shares will happily take out too. No immutable or air-gapped copy that an attacker can't reach even with full network access. And most commonly: no documented runbook for who does what in the first hours of an actual recovery, so the plan gets improvised exactly when improvisation is most costly.
Setting RPO and RTO honestly
Not every system needs the same target. A high-churn database that changes constantly justifies a backup interval measured in minutes; a slower-moving file archive can tolerate a daily cycle. The right approach ties backup frequency to how critical and how volatile each system actually is, rather than applying one blanket policy to everything.
The questions worth asking now
What's our actual RPO and RTO for the systems that matter most — and has anyone written that down? When was our backup last test-restored, not just confirmed to have "completed successfully"? Is there a copy that ransomware touching our live network couldn't also encrypt? And does everyone who'd need to act in a real recovery know what they're responsible for, before the day it actually happens?