Mario Leiva, specialist in architecting high-availability data protection frameworks across North America, Australia and Europe
TL:DR This glossary defines the core disaster recovery terms — Recovery Time Objective (RTO), Recovery Point Objective (RPO), restorable vs. recoverable, and more — plus what proves them in practice: DR plan testing, clean restores, and failover testing. For the data on why most DR plans fail under real conditions and how to close that gap, see ThinkOn’s deep dive,
The Restore that Reinfects: What Your Disaster Recovery Plan Is Missing.
Every disaster recovery plan uses the same handful of terms — RTO and RPO in disaster recovery, restorable, recoverable — but knowing what they mean isn’t the same as knowing whether they’re true for your environment.
That gap exists because the terms get treated as documentation, not commitments. A plan can define a four-hour RTO and a 15-minute RPO without either number ever being tested against a real failover. By the time it matters, those numbers are assumptions.
The definitions below are the foundation. Start here for what each term means; use the guide linked throughout for the methodology behind proving them.
Glossary
- Recovery Time Objective (RTO): the maximum period of time an affected user can function without having access to the business function or application.
- Recovery Point Objective (RPO): the maximum amount of data an application owner is prepared to lose.
- Restorable: applications that can only be re-built to the last available backup’s completion.
- Recoverable: applications that can be re-built to the point where the original disaster occurred.
- Always-on architecture: an application and its supporting infrastructure designed to tolerate failure.
- Transactional data integrity: the ability to duplicate transaction data to remote sites without third-party tools.
- Reference data integrity: all non-transactional data and information that is part of an application’s data set.
- Accessibility: an application’s intended user can reach the application without interruption exceeding the particular application’s RTO.
- Clean restore: a recovery that returns systems to production without reintroducing the malware, corrupted files, or root cause of the original incident.
- Failover test: a scheduled exercise that fails a system over to its recovery environment to confirm RTO/RPO targets and data integrity, rather than assuming them.
- DR plan testing: the practice of exercising a disaster recovery plan against real conditions to verify it works, rather than trusting it on paper.
- Disaster Recovery as a Service (DRaaS): a cloud-based service that replicates and hosts an organization’s servers so it can fail over to them in a disaster, without maintaining its own secondary recovery site.
- Backup as a Service (BaaS): a cloud-based service that manages an organization’s data backups, so recovery starts from a stored copy of the data rather than the production environment itself.
- Failback: the process of returning operations from the recovery environment back to the original, or a new, production environment once it’s safe to do so.
What is DR plan testing, and why does it matter?
DR plan testing validates that recovery actually works, verifying clean, uninfected restores within target timeframes. Untested plans routinely fail in a real incident.
Knowing the terminology above is table stakes; proving recovery is the real work. DR testing confirms that backups are restorable, that recovery times meet targets, and that restores don’t reintroduce malware — the gaps that only surface when a plan is exercised under realistic conditions.
For the statistics behind why most DR plans fail this test, the re-infection loop that untested restores can trigger, and how to test a plan properly, see ThinkOn’s guide: The Restore that Reinfects: What Your Disaster Recovery Plan Is Missing.
Ransomware doesn’t just test your data. It tests your restores.
A clean, uninfected restore inside your RTO/RPO window isn’t automatic — it’s the difference ransomware resilience actually comes down to. ThinkOn’s guide breaks down what real resilience looks like beyond the backup itself.