RTO vs RPO

RTO, the recovery time objective, is the longest the business can accept being down. RPO, the recovery point objective, is the most recent work the business can accept losing. RTO is measured in downtime and RPO in lost data. Both are business decisions, set before choosing a backup product, and neither is real until a timed restore proves the system can meet it.

What each one measures

Recovery time objective is the longest acceptable gap between the system going down and the system being usable again. Recovery point objective is the longest acceptable gap between the last good copy and the moment of failure. RTO is measured in downtime. RPO is measured in lost work.

A concrete way to hold them apart: if the server fails at noon, RTO asks when people can work again, and RPO asks how much of the morning has to be typed in again. A nightly backup gives you an RPO of up to a day, however fast the restore runs. A standby system ready to take over gives you a short RTO, but if it copies data only once a day, the RPO is still a day.

They are business decisions, not technical ones

NIST publishes contingency planning as a process that starts by evaluating systems and operations to determine planning requirements and priorities. The order matters. The tolerable loss is decided by the people who absorb it, and the architecture is then built to meet it. Reversing that order produces a backup schedule nobody has agreed to.

In practice that means asking the owner of each system, not the person who runs it. How long can orders stop before customers leave? How much lost data can staff re-create from email and paper, and how much is gone for good? The answers are usually different for different systems. The accounting database and the marketing site rarely deserve the same targets, and pretending they do wastes money on one and underprotects the other.

Why the two numbers cost differently

Shortening RPO usually means copying more often, which costs storage and write throughput, and sometimes a different database setup that ships changes continuously instead of in nightly batches. Shortening RTO usually means having somewhere ready to run, which costs standby capacity, rehearsed procedures, and the time to keep both copies in step.

An operation can want a tight RPO and tolerate a loose RTO, or the reverse. A law office may accept a slow recovery but not the loss of a single document. A storefront may accept losing an hour of browsing data but not an hour of being offline. Quoting one number for both is how budgets get set wrong, because it pays for speed where the business needed completeness, or the other way round.

Neither number is real until a restore proves it

An RTO is a claim about how fast a recovery runs. CISA recommends regularly testing the availability and integrity of backups in a disaster recovery scenario, and its small business guidance says to test that data can be restored both fully and partially. Until a restore has been timed, the RTO is an estimate.

The same goes for RPO. A backup job that reports success can still be copying the wrong folder, or a database file that was mid-write and will not open. Restore to a separate machine on a schedule, open the data, and time the whole thing from the decision to recover to the moment someone can work. Write the result down next to the target. When they disagree, the result is the number to plan around.

Questions

What is the difference between RTO and RPO?

RTO is the longest acceptable time to get the system running again. RPO is the longest acceptable amount of data to lose. One is measured in downtime, the other in lost work.

Which one should we set first?

Both, before choosing a backup product. They are business tolerances, decided by the people who absorb the loss, and the architecture is designed to meet them rather than the other way round.

How do we know our RTO is achievable?

Time an actual restore, start to finish. CISA recommends regularly testing that backups can be restored fully and partially. A recovery time nobody has measured is an estimate, not an objective.

Should every system have the same RTO and RPO?

Usually not. Ask the owner of each system what downtime and data loss it can absorb. Accounting records and a marketing site rarely need the same targets, and matching them wastes money.

Sources

NIST SP 800-34 Rev. 1. Contingency Planning Guide for Federal Information Systems, May 2010, updated 11 November 2010. Covers evaluating systems and operations to determine contingency planning requirements and priorities.
CISA #StopRansomware Guide. Recommends regularly testing the availability and integrity of backups in a disaster recovery scenario, and keeping backups offline and encrypted.
CISA: Back up business data. Recommends testing the backup procedure so data can be restored both fully and partially, and describes the 3-2-1 rule.

Also read

Keep reading