RTO vs RPO: The Two Numbers That Decide Your Backup Strategy

Most conversations about backup start in the wrong place. Someone asks which product we recommend, or whether the backup should go to the cloud, or how much storage they need. Those are all downstream questions. The upstream question — the one that determines every other answer — is two numbers that most small businesses have never been asked to name.

They have unfortunate acronyms. Stay with me anyway, because once you have picked these two numbers, the argument about products largely resolves itself.

The Two Definitions, Precisely

RPO, the recovery point objective, looks backward. It is the maximum amount of data, measured in time, that you can afford to lose. If your RPO is one hour, you have accepted that when something breaks you may have to redo up to an hour of work. Everything before your most recent good backup survives; everything after it does not.

RPO answers one operational question: how often do backups run? An RPO of 24 hours means a nightly backup. An RPO of 15 minutes means snapshots every 15 minutes. That is the whole relationship.

RTO, the recovery time objective, looks forward. It is the target time between the disruption and the point where the system is usable again. If your RTO is four hours, then four hours after the server dies, people need to be working.

RTO answers a different question: what does the recovery system have to be built out of? A four-hour RTO and a four-day RTO are not the same product with different settings. They are different architectures with different price tags.

Here is the sentence worth remembering: RPO is about data you lose, RTO is about time you lose. They are independent. You can have a fifteen-minute RPO and a three-day RTO — excellent backups you cannot restore quickly. That combination is common, and it is usually a surprise to the business owner.

The Confusion Worth Clearing Up

Business owners routinely give me an RTO when what they are actually describing is maximum tolerable downtime — the point past which the damage becomes existential rather than annoying. These are different things and mixing them up produces plans that fail at the worst moment.

Maximum tolerable downtime is a fact about your business. It is where you start losing customers permanently, miss payroll, breach a contract, or trip a regulatory obligation. Nobody chooses it; you discover it.

RTO is a target you choose, design toward, and pay for. It has to sit meaningfully below maximum tolerable downtime, because the margin between them has to absorb two things people forget:

• Detection time. The clock does not start when you notice. If ransomware ran at 11 PM Friday and someone noticed at 8 AM Monday, you have already spent most of your margin.
• Work recovery time. The hours after systems are back, when staff re-enter what was done on paper and reconcile the gaps. For a busy practice this can exceed the technical recovery itself.

So the honest arithmetic is: detection + technical recovery (your RTO) + work recovery must fit inside maximum tolerable downtime. If you set RTO equal to maximum tolerable downtime, you have built a plan with no margin, which is not a plan.

Worked Example: A 20-Person Professional Services Office

Twenty people, a file server, an accounting package, and Microsoft 365 for email. Billable work happens in documents and the accounting system.

Maximum tolerable downtime: about one business day. A day of chaos is survivable. A week is not.

RPO: one hour. Losing a day of document edits means twenty people redoing a day of work, and much of it is not reconstructable from memory. An hour is annoying but recoverable.

RTO: four hours. Half a day down is absorbable. A full day is not, and the margin has to cover a Monday morning discovery.

What that requires. Image-based backups of the servers on an hourly schedule, landing on a local backup appliance so restores are not bandwidth-bound, with the ability to boot the failed server as a virtual machine on that appliance while the real repair happens. A copy replicated offsite, at least one copy immutable or otherwise beyond the reach of an administrator account, because ransomware crews delete backups first. Separate backup coverage for Microsoft 365 — vendor retention is not backup, and the recycle bin will not save you from a mailbox deleted maliciously or a synchronization mistake that propagates.

Notice what did the work: not a product name, but a four-hour RTO. That number is what forced the local appliance and the ability to run the server temporarily. Cloud-only backup at a comparable price would meet the RPO comfortably and miss the RTO badly.

Worked Example: A Medical Practice

Six providers, an on-premises electronic health record system, imaging, and a full schedule.

Maximum tolerable downtime: hours, not days. Patients are physically present.

RPO: fifteen minutes. An hour of lost clinical documentation is not an hour of retyping. It is orders, medication entries, and visit notes that may be unreconstructable, with patient-safety and record-integrity consequences. This is the case where a short RPO is genuinely justified.

RTO: one hour for clinical access, with documented downtime procedures covering the gap. The paper process is part of the plan, not an admission of failure. Print the day schedule each morning. Keep downtime forms stocked. Know who calls the pharmacy.

What that requires. Frequent snapshots or continuous replication of the EHR database, standby capacity that can run it, and a rehearsed switchover. Expect a large work recovery time: a half-day of paper charting takes considerably longer than a half-day to enter.

If the EHR is cloud-hosted, the RTO and RPO for that system belong to the vendor. Ask for their numbers in writing, ask what their agreement actually commits to versus what the marketing page says, and note the trade you just made: your internet connection becomes the single point of failure. That usually means a second circuit or cellular failover, and it means your RTO for connectivity now matters as much as the EHR vendor. Business associates carry the same HIPAA Security Rule obligations as covered entities, so this is a diligence question, not just an operational one.

Why RPO Is Cheap and RTO Is Expensive

This is the part that reframes the budget conversation.

Improving RPO is mostly a scheduling change. Modern backup software uses change-block tracking, so an hourly backup does not copy everything — it copies what changed since the last one. Going from nightly to hourly typically costs some storage, a modest amount of network traffic, and a few minutes of configuration. The cost curve is gentle, and the software you already own can usually do it.

Improving RTO means buying somewhere for the work to happen. To restore fast, you need capacity sitting ready: a local appliance able to run virtual machines, standby hardware, or reserved cloud resources. Plus licensing. Plus a documented, rehearsed procedure, because an untested process adds hours. You are buying idle capacity and practice, and neither is cheap.

There is also physics. If your only copy lives offsite, restoring is bandwidth-bound. A terabyte over a 100 Mbps connection is roughly 22 hours at perfect throughput, and nobody gets perfect throughput. No amount of backup software fixes that; only a local copy or standby capacity does. This single fact is why so many businesses with genuinely good backups discover a multi-day RTO.

Practical consequence: if the budget is tight, buy the aggressive RPO first. It is inexpensive and it protects the thing you cannot recreate. Then be honest about the RTO you have actually bought rather than the one you assumed.

Setting Your Own Numbers

Do this per system, not company-wide. A single company-wide RTO either overspends on things that do not matter or underprotects the one that does. List what you run — email, file storage, the line-of-business or clinical application, accounting, phones, the website, any system a regulator cares about — and for each one, answer three questions with the people who use it, not with IT:

• How long can we operate without this before it becomes serious? That bounds the RTO.
• If we lost the last hour of work in it, what exactly would we have to redo, and could we? That sets the RPO.
• What is the manual workaround while it is down, and who knows it?

Expect two or three systems to be genuinely urgent and the rest to be less critical than everyone assumed. That spread is where the money gets saved. To turn these numbers into a real plan, our post on what most disaster recovery plans are missing covers the parts that live outside the backup software, and the real cost of IT downtime helps you put a dollar figure against the hours you are trying to avoid. Add up what an hour costs you: staff who cannot work, revenue you cannot take, and the overtime to catch up afterwards. For most small offices that lands somewhere between several hundred and a few thousand dollars an hour, and that number is what justifies — or does not justify — a shorter RTO.

The Number Is a Hypothesis Until You Test It

Every RTO I have seen written down for the first time was optimistic. The gap between the plan and reality shows up in unglamorous places: the documentation was on the file server that is down, the licensing portal needs a password only one person has, the standby hardware has a firmware mismatch, the person who knows the procedure is on vacation.

So test a restore quarterly, and do one full restore test a year. Time it from the decision to restore until someone can work normally, and compare that to the number on the plan. If the two do not match, you either change the architecture or change the number, and either is fine — what is not fine is a document that says four hours over a system that takes three days.

Ransomware makes this sharper, because it attacks both numbers at once: it encrypts production and hunts backups, and the recovery point you end up with is the last one it could not reach. If you have not looked at that side of it, our ransomware protection guide covers the controls that keep a recovery point available at all.

Related Questions