What Are RTO and RPO? A Plain Guide for SMEs | 4iT

RTO and RPO are the two numbers that decide how a business plans its backups and recovery. RTO (Recovery Time Objective) is how quickly a system must be back after an outage. RPO (Recovery Point Objective) is how much data you can afford to lose, measured as how far back your last usable backup is. Set these two numbers for each critical system and the rest of your backup and disaster recovery design mostly follows from them.

Key facts

• RTO (Recovery Time Objective) is how fast a system must be restored after an outage, measured in time.
• RPO (Recovery Point Objective) is how much data you can afford to lose, measured as the age of your most recent usable backup.
• Lower numbers cost more: near-instant recovery and near-zero data loss need more infrastructure than a nightly backup with a day of recovery.
• You set RTO and RPO per system, not once for the whole business, since a file server and a rarely used archive have very different needs.
• These two numbers are the practical bridge between what the business wants and what the backup design has to deliver.

What do RTO and RPO mean?

Picture a timeline with the moment of failure in the middle. RPO looks backwards from that moment: it is how far back your last good backup sits, and therefore how much work is lost. If you back up every night and the server dies at 4pm, you have lost a day's work, so your RPO is 24 hours. RTO looks forwards from the failure: it is how long until the system is usable again. If it takes six hours to restore and get running, your RTO is six hours.

The reason these are framed as objectives rather than facts is that you decide them deliberately, based on what the business can tolerate, and then build backups to meet them. They are targets you design towards. Almost every other backup and disaster recovery decision, how often you back up, where copies live, whether you need standby systems, flows from the RTO and RPO you set.

How do you decide the right numbers?

You decide by asking, for each important system, two blunt questions. How long can we be without this before it really hurts? That is your RTO. And if we had to roll back to the last backup, how much lost work could we stomach? That is your RPO. The answers come from the business, not from IT: the people who rely on a system know what an outage costs them far better than the person restoring it.

The key insight is that different systems deserve different answers. Your live accounting or line-of-business system might justify an RTO of an hour or two and an RPO measured in minutes, because every hour down is lost revenue. A rarely touched document archive might be fine with an RTO of a day and an RPO of 24 hours. Setting one blanket target for everything either overspends protecting things that do not need it or underprotects the things that do. In our experience the exercise of ranking systems this way is itself valuable, because it forces a business to be honest about what matters.

Why do lower RTO and RPO cost more?

Because speed and freshness both take infrastructure. A tight RPO, losing only minutes of data, means backing up continuously or very frequently rather than once a night, which needs more capable backup systems and more storage. A tight RTO, being back in minutes rather than hours, often means keeping a standby copy of the system ready to take over, rather than restoring from scratch when something breaks. Both cost real money.

So the practical work is matching the spend to the need. There is no value in paying for near-instant recovery on a system the business could happily live without for a day, and there is real danger in a cheap nightly backup on a system that cannot survive losing a day's data. Getting RTO and RPO right per system is how you spend the backup budget where it counts instead of spreading it evenly and protecting the wrong things. This is exactly the conversation worth having before choosing a backup solution, not after.

Frequently asked questions

What is the difference between RTO and RPO?

RTO (Recovery Time Objective) is how quickly a system must be back after an outage. RPO (Recovery Point Objective) is how much data you can afford to lose, measured as the age of your most recent usable backup. RTO is about time to recover; RPO is about how much work is lost.

How do I calculate RTO and RPO?

For each important system, ask how long the business can be without it before it really hurts (RTO) and how much lost work you could tolerate if you rolled back to the last backup (RPO). The answers come from the people who rely on the system, and they differ per system rather than being a single figure for the whole business.

What is a good RPO?

It depends entirely on the system. A live revenue-generating system might justify an RPO of minutes, achieved with frequent or continuous backups. A rarely changed archive might be fine with 24 hours. A good RPO is the one that matches what that specific system can tolerate, not a single number applied everywhere.

Why does faster recovery cost more?

A tight RPO needs frequent or continuous backups, which take more capable systems and more storage. A tight RTO often means keeping a standby copy ready to take over rather than restoring from scratch. Both require more infrastructure, so the sensible approach is to spend on speed only where the business needs it.

If you are not sure what your recovery targets should be, or whether your current backups meet them, we can work through it system by system and tell you where the gaps are. This is also a core part of building a business continuity plan. Call 4iT on 1800 367 448 or see our backup and disaster recovery services.