Two acronyms decide how much data you lose and how long you're down after a disaster. Here's what RTO and RPO actually mean, how they're different, and how to set numbers your business can actually afford.
When something takes your systems down — a server failure, ransomware, a bad update, a flooded server closet — two numbers decide how bad the day gets: how long you're offline, and how much data you lose. Most businesses have never actually written those numbers down. They find out what they are, by accident, during the outage.
RTO (Recovery Time Objective) is the maximum acceptable length of time your systems can be down before the business suffers serious harm. RPO (Recovery Point Objective) is the maximum acceptable amount of data loss, measured in time, between your last backup and the moment something went wrong. They sound similar. They are not the same number, they are not solved by the same technology, and mixing them up is one of the most common — and expensive — mistakes in disaster recovery planning.
RTO answers a single question: from the moment of failure, how many hours (or minutes) do you have before this becomes a real crisis?
A 4-hour RTO means your team has committed to having critical systems back online within 4 hours of an outage. That commitment shapes everything downstream — what kind of backup infrastructure you need, whether you need a failover site on standby, and how much you're willing to spend to hit that number.
Different systems can have different RTOs. Your email server might need a 1-hour RTO. An internal reporting tool that nobody touches until Friday might tolerate 24 hours. Treating every system as equally urgent is how IT budgets get wasted protecting things that don't need it.
RPO works backward from the failure instead of forward. It asks: when this happens, how much recent work are we willing to lose?
If you back up nightly at midnight and a server fails at 4 p.m. the next day, your actual data loss is everything created since midnight — up to 16 hours of work. If that's unacceptable, your RPO needs to be tighter, which usually means backing up more frequently (hourly, or continuously) rather than once a day.
A 15-minute RPO and a 24-hour RPO are not a rounding difference — they represent entirely different backup architectures, and entirely different costs.
RTO is about speed of recovery. RPO is about freshness of data. You can have a fast recovery with stale data (quick to restore, but you lose a full day of work), or fresh data with a slow recovery (nothing is lost, but it takes 12 hours to bring it back online). Getting both numbers tight at the same time is the most expensive combination — which is exactly why these targets need to be a business decision, not a default setting your IT provider picked for you.
Instead of guessing, work backward from actual business impact:
Ask what breaks first. For each core system, what happens after 1 hour down? After 8 hours? After 24? The point where things get genuinely bad is close to your real RTO.
Ask what a day of lost work actually costs. Lost sales, re-entered orders, missed compliance logs — put a rough number on it. That number tells you how much you should be willing to spend to shrink your RPO.
Set different targets for different systems. A single company-wide RTO/RPO is usually wrong for every system except your most critical one.
Test it — actually test it. A recovery plan that has never been tested against its stated RTO/RPO is a guess dressed up as a plan. Verizon's long-running Data Breach Investigations Report and CISA's guidance both point to the same pattern: businesses discover their real recovery numbers during an incident, not before one — and the numbers are almost always worse than assumed.
If you're not sure where to start, this is exactly the kind of assessment worth getting a second set of eyes on — see how JJC Systems approaches data backup and recovery infrastructure, or explore the cybersecurity and compliance side of business continuity planning if regulatory requirements are part of what's driving your targets.
What is the difference between RTO and RPO? RTO (Recovery Time Objective) measures how long you can be down before it's a serious problem. RPO (Recovery Point Objective) measures how much data, measured in time, you can afford to lose. One is about downtime, the other is about data loss — and they require different solutions to fix.
What's a good RTO and RPO for a small business? There's no universal number — it depends on what the system does and what downtime or data loss actually costs your business. Many SMBs target something like a 4–8 hour RTO and a 1–4 hour RPO for critical systems, then relax those targets significantly for lower-priority systems.
Can you have a zero RPO? Close to zero is possible with continuous data replication, but it's expensive and usually reserved for the most mission-critical systems (financial transactions, patient records) rather than applied company-wide.
How do I know if my current backups actually meet my RTO/RPO? The only real way to know is to test a full restore and time it — not just confirm backups are running. Many businesses that assume they have solid RTO/RPO coverage discover otherwise the first time they're forced to actually use it.
"The businesses that get burned aren't the ones with bad backups — they're the ones who never tested whether their backups actually hit the recovery numbers they assumed. RTO and RPO are only real once you've proven them under an actual restore, not just written them down." — JJC Systems IT Advisory Team
If you can't confidently state your current RTO and RPO — or you've never tested them — that's worth fixing before something forces the question. Talk to a JJC Systems specialist about a backup and recovery assessment, or explore our approach to cloud infrastructure and business continuity.
If this describes your situation, tell us where it hurts most. We will tell you what it would realistically take to fix in your environment, what we would measure, and whether we think it is worth doing at all.
How much should a small business budget for IT? Published benchmarks range from 2% to 12% of revenue — here's why, which figure actually applies to your business, and how to allocate it once you have a number.
What does a virtual CIO do? Executive-level IT strategy — roadmapping, budget planning, vendor negotiation, security governance — at 20-40% of what a full-time CIO costs. Here's what a vCIO actually does day to day, and how to tell if your business has outgrown "no one's really in charge of IT strategy."
How do I create a digital transformation strategy? Start with a readiness assessment, not a software purchase — 62% of small business transformations fail specifically because technology gets bought before anyone maps the actual process gaps it's meant to fix.
Describe the situation in your own words.
