RTO vs RPO: how to set recovery objectives that match your business

When your server fails, you have to restore from your last backup, and anything saved after that backup is lost. If the backup ran the night before, that can mean losing a full day of orders. Restoring from a backup also takes time, because someone has to set up a new server, connect it to the network, and restore the data before systems can run again.

How long your business can afford to be down is your recovery time objective (RTO). How much data you handle losing is your recovery point objective (RPO). Both metrics define what your business needs to survive an outage.

What is the difference between RTO and RPO?

The difference between RTO and RPO is what each one measures. RTO is about downtime. RPO is about data loss.

Your RTO covers the time from when something breaks to when you’re running again. If your RTO is four hours, you need to be back online within four hours.

Your RPO covers the time between your last backup and when something breaks. If you back up once an hour, you could lose up to an hour of data. If losing that much would really impact you, you need to back up more often. 

There’s no industry standard RTO or RPO. The right numbers depend on your business and on each system you run.

How to calculate RTO and RPO

You calculate RTO and RPO by starting with what your business can afford, not what your current tools can do. 

To calculate your RTO, start with what downtime costs you, listing what you lose for each hour you’re down: sales, missed service-level agreements (SLAs), staff who can’t work, and customers who go somewhere else. The longer the outage, the more those losses add up. Your RTO is the point where the losses become more than your business can absorb.

In Uptime Institute’s 2026 outage analysis, 57% of respondents said their most recent major outage cost more than $100,000. One in five said it cost more than $1 million.

To calculate your RPO, start with your data. Ask how much of it you could lose and still keep running. Some data you can rebuild, like a product catalog you can import again. Some you can’t, like orders and payments made since your last backup. The more data you can’t rebuild, the shorter your RPO needs to be.

You don’t set one RTO and RPO for the whole company. Each system gets its own. A payments system probably can’t be down for more than a few minutes, while an internal tool might be fine for a day. The harder a system is to live without, the shorter both numbers get.

How ransomware affects RTO and RPO

Ransomware affects RTO and RPO because it can damage your backups and your servers at the same time.

If your recent backups were made after attackers got into your systems, or were encrypted too, you can’t restore from them. You have to go back to your last clean copy, which could be days or weeks old.

You also can’t restore backups onto infected servers, so you have to build a clean environment first. That takes longer than restoring in place.

If you have only set numbers for a hardware failure, you haven’t planned for an attack. Set a separate RTO and RPO for ransomware. For more information on this, see our guide to disaster recovery for ransomware.

Check your backups against your RTO and RPO

Check your backups against your RTO and RPO to see whether they’re enough. Run a full restore, time it, and compare that to your RTO. If your backups meet both numbers, keep them. If they don’t, managed disaster recovery closes the gap. It keeps a standby copy of your systems ready, so you can switch over instead of rebuilding.

If you’d like a second opinion, talk to a Nexcess engineer. We’ll look at your numbers and your current setup and tell you whether your backups can meet them.