Search
Backup & Recovery Guide
What Are RTO and RPO? The Numbers That Could Make or Break Your Recovery Strategy
Picture a small accountancy practice in County Louth. A burst pipe floods the server cupboard on a Tuesday morning. The backups are fine. Every file is recoverable. But nobody had ever worked out how long “recoverable” actually takes or how much of Monday’s work would be missing when the systems came back. Three days later, the office is still catching up on invoices that should have gone out days ago.
That gap, between having a backup and actually knowing what recovery looks like, is exactly what RTO and RPO are meant to close. Most business owners have heard the terms. Fewer could tell you what their own numbers actually are.
RTO Meaning: What Recovery Time Objective Actually Measures
RTO stands for Recovery Time Objective. It’s the answer to one question: how long can this system be down before it starts costing you something you can’t get back?
Not “how long until it’s technically restored.” How long until the business can function again. There’s a difference. A system can be “restored” in the sense that data exists somewhere, while staff are still locked out for another six hours because nobody planned for the login, the software licences, or the network configuration that also needs putting back.
Think of RTO like a fire evacuation time. It’s not just how fast people can physically leave the building. It’s how fast everyone gets out, accounted for, and back to doing something useful. A four-hour RTO for your booking system means exactly that: four hours from the moment things go wrong to the moment staff can take a booking again, not four hours to copy some files across.
RPO Meaning: What Recovery Point Objective Actually Measures
RPO, or Recovery Point Objective, answers a different question entirely: how much data can you afford to lose?
Every backup has a gap between “when it last ran” and “right now.” If your backup runs once every 24 hours and something fails at 4pm, you’ve lost a full day’s work; that’s a 24-hour RPO, whether you meant to accept that risk or not. A business running backups every hour has a maximum RPO of an hour. One backing up overnight only has whatever happened since the previous evening.
Here’s the part most SMEs get backwards: RPO isn’t a technical setting someone chose for you. It’s a business decision dressed up as an IT one. A solicitor’s practice handling live case files might tolerate almost no data loss. A seasonal retailer whose stock list updates twice a day can probably live with more.
RTO and RPO in Disaster Recovery: Why These Two Numbers Work Together
RTO and RPO in disaster recovery planning don’t operate independently. Get one wrong and the other one stops mattering.
| Scenario | RTO | RPO | Real-world result |
|---|---|---|---|
| Fast recovery, poor backup frequency | 1 hour | 24 hours | Systems are back quickly, but a full day of orders, emails, and edits are gone |
| Slow recovery, frequent backups | 12 hours | 15 minutes | Almost nothing is lost, but the business sits idle for half a day getting it back |
| Both aligned to actual need | 2 hours | 1 hour | Downtime and data loss both sit inside what the business can genuinely absorb |
A fast RTO paired with a weak RPO gives you a business that’s back online quickly, running on stale data. A tight RPO paired with a slow RTO means barely anything was lost, but nobody could touch it for half a day anyway. Neither failure looks like a disaster on paper. Both feel like one when it’s your invoices, your patient records, or your client files sitting in that gap.
How to Do Your Own RTO Calculation
You don’t need a consultant in the room to get a first, honest RTO calculation. You need about twenty minutes and a willingness to be specific.
- List the systems that actually stop work if they go down. Not everything. Your email server, probably. The shared drive holding active client files, almost certainly. The printer, no.
- Put a real number on an hour of downtime for each one. Lost billable hours, missed calls, staff sitting idle, a delivery that doesn’t go out. Even a rough figure beats a guess dressed up as precision.
- Ask how long is genuinely tolerable before that cost becomes unacceptable. Not how long you’d prefer; how long before it actually hurts. That number is your working RTO.
- Check it against what your current backup and recovery setup can actually deliver. This is where most businesses find the gap. The RTO they need and the RTO their current system can provide are often two very different numbers.
What About RPO Calculation?
RPO calculation is a narrower question. Look at how often your critical systems currently back up, then ask honestly what would be lost if failure struck one minute before the next backup was due. If that answer makes you wince, your RPO needs tightening, not your recovery speed.
Common Mistakes Irish SMEs Make With RTO and RPO
- Copying a vendor’s default number: Backup software often ships with a generic RTO and RPO built in. That number reflects what the software can do under ideal conditions, not what your actual recovery looks like once staff logins, software licensing, and network setup are factored back in.
- Setting one RTO for the whole business: A payroll system and a marketing inbox don’t need the same recovery speed. Treating them the same either wastes money protecting things that don’t matter, or leaves critical systems underprotected.
- Never testing the number: An RTO that’s never been tested against a real restore is an estimate, not a fact. Plenty of businesses only discover their real recovery time during an actual outage, which is the worst possible moment to learn it.
- Confusing “backed up” with “recoverable within RTO:” Data existing somewhere and data being usable within the timeframe the business needs are not the same claim.
One detail worth knowing: vendor-quoted recovery times are almost always measured under lab conditions, a clean test environment with no competing load and no human error. Real recoveries happen at 2am, under pressure, often with someone working from a laptop on a kitchen table. Build a margin into your numbers, because the theoretical figure and the Tuesday-morning figure are rarely the same.
Turning RTO and RPO Into Business Operations, Not Just an IT Document
RTO and RPO only earn their keep once they stop living in a document nobody reads and start shaping actual business operations. That means the office manager knows which systems come back first. It means staff know what to do in the recovery window, not just what the IT provider does behind the scenes. It means the numbers get reviewed when the business changes, not left over from a plan written three years and two systems ago.
ImageIT has spent more than 38 years working with SMEs across Louth, Meath, Monaghan, Cavan, and North Dublin, most of whom never set out to become experts in disaster recovery. They didn’t need to. That’s the point of having an outsourced IT partner who treats RTO and RPO as business questions first and technical settings second.
Most businesses don’t need a perfect recovery plan. They need one that matches what they can actually afford to lose and how long they can actually afford to wait.
If you’ve never sat down and worked out your own numbers, that conversation is usually worth having before something forces it. Get in touch with ImageIT to talk through what realistic RTO and RPO figures look like for your business, not a vendor’s default settings.
Frequently Asked Questions
RTO stands for Recovery Time Objective: the maximum time a system can be down before it seriously affects business operations.
RPO stands for Recovery Point Objective: the maximum amount of data, measured in time, a business can afford to lose during an outage.
RTO measures downtime tolerance. RPO measures data loss tolerance. A business can have a fast RTO and a poor RPO, or the reverse.
List critical systems, estimate the cost of an hour’s downtime for each, then work out how long is tolerable before that cost becomes unacceptable.
Check how often each system backs up, then ask what would be lost if failure hit one minute before the next backup ran.
Not necessarily. A very short RTO can cost significantly more to deliver. It should match what the business genuinely needs, not the fastest technically possible figure.
They can align, but they measure different things: one is downtime, the other is data loss. Treating them as interchangeable is a common mistake.
No. Payroll, client files, and a marketing inbox rarely carry the same risk. Setting one blanket figure usually overprotects some systems and underprotects others.
Whenever the business changes meaningfully: new systems, more staff, new compliance requirements. A figure set three years ago rarely still fits.
They’re usually measured under ideal lab conditions. Real recoveries involve human error and pressure, so actual figures tend to run longer.
Do You Know Your Own Numbers?
Get in touch with ImageIT to talk through what realistic RTO and RPO figures look like for your business, not a vendor’s default settings.