Leadership says 'we have backups, so we're covered for disaster recovery.' What do you clarify?
Short answer
Backups are necessary but not sufficient: disaster recovery and business continuity are the tested capability to restore operations within agreed recovery time and recovery point objectives (RTO/RPO), which requires a documented plan, mapped dependencies, runbooks, and validated restores — not just the existence of backup files. Agreeing they're the same conflates a data copy with an operational capability. DR isn't merely buying insurance, which transfers financial loss but doesn't restore systems. And backups don't make a DR plan unnecessary — untested backups routinely fail when they're finally needed. The clarification: DR must be exercised, not assumed.
"We have backups, so we're covered" is one of the most common and dangerous assumptions in resilience. Backups are a component of disaster recovery, not the whole of it — and treating the copy as the capability is exactly how organisations discover, mid-crisis, that they can't actually recover.
Backups vs. DR vs. BCP
A backup is a copy of data. Disaster recovery (DR) is the tested capability to restore operations — applications, infrastructure, and data — within defined RTO (how fast you must be back) and RPO (how much data you can afford to lose). Business continuity (BCP) is broader still: keeping the business running through disruption, including people, processes, and facilities. Real DR requires a documented plan, mapped dependencies (an app is useless without its database, DNS, and identity provider), runbooks, and — above all — validated restores that prove you can hit your RTO/RPO.
Why the wrong answers fail
"Backups and DR are the same" is the core conflation: it mistakes having data for being able to resume operations. "DR just means buying insurance" confuses financial risk transfer with operational recovery — insurance may pay for losses, but it doesn't bring your systems back online. "Backups make a DR plan unnecessary" ignores the well-documented reality that untested backups frequently fail when finally needed: corrupted media, incomplete scope, unworkable restore order, or credentials that no longer exist. Existence is not the same as recoverability.
The judgment being probed
The interviewer wants to see you push back on a comforting but false belief and reframe it constructively: the question isn't "do we have backups?" but "have we proven we can restore the business within our objectives?" Strong answers mention regular restore tests and DR exercises, the distinction between RTO and RPO, dependency mapping, and modern threats — for example, immutable or offline backups so ransomware can't encrypt your recovery copies too. The headline clarification is simple: DR is a capability you exercise, not a state you assume because backup jobs are green.
Likely follow-ups
- What's the difference between RTO and RPO, and how do they drive backup design?
- How would you design a DR test that's realistic without disrupting production?
- Why do immutable or offline backups matter specifically against ransomware?