Two acronyms decide what your entire backup and recovery setup should look like and cost, and most businesses have never consciously chosen either. They inherit both from software defaults, then discover their real values during an actual disaster, which is the most expensive possible way to learn a definition.
Here are the definitions, the difference, and (more usefully) how to actually pick your numbers.
RTO — Recovery Time Objective: how long your business can afford a system to be *down* before recovery. It is measured forward from the failure: the outage clock.
RPO — Recovery Point Objective: how much recent *data* your business can afford to lose. It is measured backward from the failure to your last usable backup: the data-loss window.
The two are independent, and the distinction matters because they are bought with different tools. You can restore quickly but lose a day’s work (good RTO, poor RPO), or lose almost nothing but take days to restore it (good RPO, poor RTO). A recovery setup is only as good as the weaker of the two numbers against your actual needs.
The same disaster, four different outcomes
Picture a server dying at 2pm on a Wednesday. Four businesses with four setups:
- Nightly backup, restore to spare hardware in two days. RPO: up to 24 hours (everything since last night’s backup is gone). RTO: two days. Total experience: Wednesday afternoon’s work lost, trading resumes Friday.
- Nightly backup, rapid cloud restore. RPO: still up to 24 hours. RTO: four hours. Wednesday’s work is lost, but Thursday is normal.
- Hourly backup, two-day restore. RPO: one hour (almost nothing lost). RTO: two days. The data survives; the business still stands still until Friday.
- Continuous replication with failover. RPO: minutes. RTO: minutes to an hour. The expensive option, and for some businesses the only sane one.
Same failure, wildly different Wednesdays. The numbers, not the backup brand, made the difference.
How to actually set your numbers
The honest method is to price the pain, system by system, because a business does not have one RTO; it has one per system, and pretending otherwise either overspends on the trivial or underprotects the vital.
For RTO, ask: what does an hour of this system being down cost? Count stopped salaried time, missed orders, contractual penalties and customer damage. A 25-person business fully stopped burns four figures a day in wages alone before a single lost sale. Where the answer is “we would switch to paper and cope”, the honest RTO is days and cheap arrangements are fine; where the answer involves a production line or an order book, the RTO is hours and the arrangements must be priced to match. This is the same exercise that anchors business continuity planning, applied to each system.
For RPO, ask: if we lost everything since the last backup, what would re-creating it involve? A day of lost email is mostly re-askable. A day of lost orders, bookings or ledger entries may be partially unrecoverable and reputationally expensive. Systems where humans could re-key from paper tolerate longer RPOs than systems that are the only record.
Then write the numbers down per system, tiered the way our disaster recovery plan template structures them, and let the tiers drive the spend: aggressive objectives for the systems that earn them, relaxed and cheap for the rest.
What each number costs to improve
The pricing logic is usefully simple:
- RPO is bought with backup frequency. Nightly is the baseline; hourly snapshots and continuous replication shrink the loss window at rising cost. Modern arrangements make hourly RPOs affordable for most SMEs; near-zero RPOs remain a deliberate investment.
- RTO is bought with restore speed and standby capacity. From “order hardware, then restore” (days) through rapid restore to cloud or spare capacity (hours) up to replicated failover environments (minutes). Each step up costs more in standing infrastructure.
Two traps catch businesses here. First, unverified objectives: an RTO is a measurement, not an aspiration, and until you have timed a real test restore you do not have an RTO, you have a guess. (The tested-restore discipline from the 3-2-1 rule is what converts guesses into numbers.) Second, the mismatch nobody checked: management assumes hours, the actual arrangement delivers days, and the gap surfaces mid-crisis. Asking your IT provider “what is our tested RTO and RPO per system?” is a one-line email that has saved businesses we know a very bad week.
Frequently asked questions
What is the difference between RTO and RPO?
RTO is maximum tolerable downtime (how long until the system is back); RPO is maximum tolerable data loss (how far back your last usable copy may be). Downtime forward, data backward: independent numbers bought with different tools.
What are typical RTO and RPO values for a small business?
Common sensible tiers: critical systems at RTO 2 to 8 hours and RPO 1 to 24 hours; important systems at RTO 1 to 2 days; archives at whatever is cheap. The right values come from pricing your own downtime, not from typical anything.
Can RTO be shorter than RPO, or vice versa?
Yes, freely: they are independent. A business might restore in two hours (short RTO) from last night’s backup (24-hour RPO), or the reverse. Design each against its own cost of failure.
How do we find out our current real RTO?
Time a test restore of a meaningful system, end to end, including the discovery-and-decision time at the start. The measured number is routinely a multiple of what anyone assumed, which is exactly why the test matters.
What is RTO and RPO in cyber insurance and questionnaires?
Insurers and client questionnaires increasingly ask for stated recovery objectives as evidence of continuity planning. Documented, tested numbers per system (the tiering above) answer them credibly; invented ones invite awkward claim conversations.
Who should decide our recovery objectives: IT or management?
Management owns the tolerances (what downtime and loss cost the business); IT owns delivering arrangements that meet them and proving it with tests. Objectives set by IT alone default to what the tools do; set by management alone, to wishful thinking.
Get your two numbers measured, not assumed
The whole subject compresses to one uncomfortable question: do you actually know, from a test, how long recovery takes and how much you would lose? Our free IT health check answers it: current backup frequency, a realistic restore-time assessment, and the gap (if any) between your arrangements and what your business genuinely requires, priced per tier. Get in touch; it is a better Wednesday afternoon than the other way of finding out.
