Almost every organization has a recovery plan. Rather fewer can state, per system, how long recovery would take and how much data would be lost, and fewer still have measured either. Those two numbers are the whole design input, and when they are left implicit the architecture ends up being decided by whoever bought the backup product.
This page defines the terms precisely, explains who owns them, maps them onto the recovery patterns they imply, and sets out how to test that the numbers hold.
The definitions, from the source
NIST defines both terms in its contingency planning guidance. A recovery time objective defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported business processes, and the maximum tolerable downtime. A recovery point objective represents the point in time, prior to a disruption or system outage, to which data must be recovered after an outage. See NIST SP 800-34 Rev. 1.
Put plainly: RTO is how long you can be down. RPO is how much work you can afford to redo. They are independent. A system can tolerate a day of outage but no data loss at all, or tolerate losing an hour of transactions but must be back within minutes. Treating them as one number is the most common error in this area, and it reliably produces an architecture that is expensive in the wrong direction.
NIST places both inside a wider concept, maximum tolerable downtime, which is the total outage the business process can absorb. RTO is the share of that allocated to recovering the technology, which leaves room for detection, decision and the manual work of resuming a process. An RTO set equal to the maximum tolerable downtime has quietly assumed that failure is noticed instantly and that nobody needs to decide anything.
Who owns the numbers
Not the infrastructure team. RTO and RPO are statements about what the business can tolerate, and they are properly set by the people accountable for the process the system supports, informed by what each level of protection costs.
The conversation works best in that order. Asked in the abstract, every system owner requires zero downtime and zero data loss. Asked against a cost, the answers separate quickly, and the separation is the useful output: it is what lets a limited recovery budget be spent on the systems that actually justify it.
The resulting tiers should be written down and reviewed, because they drift. A system that was peripheral three years ago may now sit in the middle of an operational process, and nothing in the infrastructure will announce that.
What each number implies
RPO determines how data is protected, because it sets the maximum acceptable gap between the last recoverable copy and the moment of failure.
- RPO of 24 hours. A nightly backup is sufficient. Inexpensive, and it means a failure at 4pm loses the day.
- RPO of a few hours. More frequent backups, or log shipping for databases that support it.
- RPO of minutes. Asynchronous replication. The cost rises and so does the complexity of ensuring the replica is consistent rather than merely current.
- RPO of zero. Synchronous replication, which couples the systems: a write is not complete until both sides have it. This bounds the distance between sites and makes the replica a potential source of failure for the primary.
RTO determines what is standing ready, because it sets how much has to be built at the moment of failure rather than before it.
- RTO of days. Restore to rebuilt infrastructure. Requires that the rebuild is documented and has been done.
- RTO of hours. A prepared target environment, with capacity available and configuration ready to apply.
- RTO of minutes. A warm environment running and receiving data, requiring only a decision and a redirection of traffic.
- RTO near zero. Active in both locations. This is a high availability architecture rather than a recovery one, and it is covered in Designing Infrastructure for High Availability.
The two interact. A short RTO with a long RPO is achievable and cheap. A short RPO with a long RTO is common and usually unintentional, and it means the data survived but nobody planned how to serve it.
High availability is not disaster recovery
This confusion is expensive in both directions. High availability handles component failure inside one environment: a node, a disk, a power supply. It is automatic, it operates continuously, and it protects against nothing that affects the environment as a whole.
Disaster recovery handles the loss of the environment. It is generally a decision rather than an automatic action, it involves a second location, and it accepts an outage in exchange for surviving a class of failure that redundancy cannot.
An organization with excellent high availability and no disaster recovery is protected against the failures it has seen and not against the one that closes the building. An organization with disaster recovery and no high availability takes an outage every time a disk fails. Most need both, sized differently. High Availability and Load Balancing covers the first, and Disaster Recovery and Business Continuity the wider programme.
Cloud changes the economics, not the discipline
The traditional obstacle to disaster recovery was paying for a second site that did nothing. Consumption billing changes that: capacity can be reserved and paid for at a fraction of running cost, then brought up when needed. Providers build for this explicitly, with regional and zonal separation intended to bound the blast radius of a failure. Microsoft, for instance, describes an availability zone as a logical grouping of one or more physically separate datacenters within a region, built so that a failure in one does not take the others with it. See Microsoft's availability zones overview.
What does not change is the obligation to test. A recovery plan that depends on capacity being available in a region during a large regional event is making an assumption about somebody else's spare capacity at exactly the moment everybody else needs it too. That is a risk to state rather than discover.
Testing is the part that makes it real
An untested recovery plan is a document. Testing is what converts it into a capability, and it is the stage most often deferred because it is disruptive and produces no visible improvement when it succeeds.
Testing runs on a ladder. A walkthrough confirms the plan is coherent and that the people named in it still work here. A component restore proves that a specific system can be recovered and how long it takes. A full failover of a service proves the dependencies were mapped correctly, which is what usually fails first. A live exercise with the business proves the manual process around the system works too.
Each test should produce two things: a measured actual recovery time, and a list of what surprised you. The second is the more valuable. Recovery tests characteristically fail on dependencies, credentials, DNS, certificates and licensing rather than on the data itself, and none of those appears in a backup report.
Measured results should be compared against the objectives and the gap reported honestly. An RTO of four hours with a measured recovery of eleven is not a failure of the test; it is the test working. Recording it and either funding the gap or revising the objective are both legitimate responses. Leaving the number unchanged and untested is not.
Frequency matters more than thoroughness. An annual full exercise that slips is worth less than a quarterly component restore that happens, because the failures this catches are mostly recent changes: a new dependency, a rotated credential, a certificate nobody renewed on the standby. Small and regular beats large and aspirational, and a schedule that survives contact with an ordinary quarter is worth more than one that only survives a planning document.
How LABUSA operates this
LABUSA uses AWS as part of its disaster recovery architecture to support failover of designated websites and web applications from LABUSA-managed private infrastructure. That is a current practice rather than an illustration, and it is the same pattern described above: a private primary, a public-cloud recovery target, and a defined decision to move between them.
Recovery objectives are agreed with the business before the architecture is designed, the resulting plan is exercised rather than filed, and the measured results are reported against the objectives. How LABUSA runs recovery as a managed service sets out the wider capability, and Backup and Data Protection covers the data layer this rests on.