How Long Can Your Business Afford to Be Offline? RTO and RPO Explained

Most businesses can tell you they have backups. Far fewer can answer two simple questions: how long can we be without our systems, and how much recent work can we afford to lose? Those questions have names, RTO and RPO, and they are the difference between a backup that exists and a recovery plan that works.

What RTO and RPO actually mean

Recovery Time Objective (RTO) is the maximum time a system can be unavailable before the business suffers unacceptable harm. If your RTO for the accounting system is four hours, the plan must get it running again within four hours of an outage.

Recovery Point Objective (RPO) is the maximum amount of data, measured in time, you can afford to lose. If your RPO is one hour, you need a recovery point no more than an hour old. A nightly backup gives you an RPO of up to 24 hours, whether or not anyone ever decided that was acceptable.

Put simply, RTO is about downtime and RPO is about data loss. They are set independently, and they are business decisions first and technical ones second.

Why guessing is expensive

When nobody sets these targets, they get set by accident. The backup schedule becomes the RPO. Whatever the restore happens to take becomes the RTO. The first time anyone finds out is during an incident, usually while the phones are ringing.

Common surprises include:

• A restore that works, but takes two days because the data has to come down a slow line.
• A backup that is current to last night, when the finance team needed it current to the last hour.
• A critical system that depends on three others, none of which were in the plan.

None of these are exotic. They are what happens when recovery is assumed instead of designed.

How to set targets that make sense

You do not need a consultant for the first pass. You need the people who run the business in a room for an hour.

1. List your systems by business function

Start with what the business does, not the servers. Taking orders, paying staff, invoicing, answering email, running the warehouse. Then map each function to the system behind it.

2. Ask what an outage costs

For each function, ask what happens after one hour, four hours, a day and a week. Lost sales, idle staff, missed deadlines, contractual penalties, reputational damage. Use your own judgement and your own numbers. If you cannot put a figure on it, a simple rating of tolerable, painful or critical is enough to rank systems.

3. Tier the systems

Group systems into a few tiers. For example, a small number of critical systems that must return within hours, a middle tier that can wait a day, and a long tail that can wait longer. Not everything deserves the most expensive protection, and trying to protect everything equally usually means protecting nothing well.

4. Set RTO and RPO per tier

Write the targets down in plain language and have an owner sign off each tier. This turns a technical setting into a business commitment.

Matching the design to the targets

Once the targets exist, the technology choices become much easier to justify.

A tight RPO means more frequent backups or replication, rather than one nightly job. A tight RTO means the environment you recover into must already exist or be quick to build, which is where cloud-based recovery and tested runbooks earn their keep. A relaxed target for a low-priority system lets you spend less there and put the money where it matters.

Cyber incidents add a further question. If ransomware has encrypted your data, your most recent recovery point may be compromised too. Offline or immutable copies, and a clear idea of how far back you would need to go, belong in the plan. We cover the wider defensive picture in our piece on ransomware defence as a stack.

Test it, or it is only a theory

An RTO you have never tested is a hope. Schedule a restore of a real system, time it, and compare the result to the target. Note what slowed you down: missing credentials, an undocumented dependency, a licence key nobody could find. Fix those, then test again.

Our article on why backup plans fail when you need them goes deeper on the common failure points. If you want a second pair of eyes on your design, our backup and disaster recovery service is built around exactly these targets, and our managed IT team can keep the testing on a regular schedule.

Revisit the numbers each year

Targets drift as the business changes. A new online store, a new branch, a move to cloud applications or a new compliance obligation can all tighten your tolerance for downtime. Review the tiers at least annually, and after any significant change to your systems.

A practical takeaway

If you take one step this week, ask your team two questions about your most important system: how long can we be without it, and how much recent data could we lose? If the answers are vague, or different depending on who you ask, that gap is worth closing before an incident closes it for you.