Two numbers decide almost everything about a backup plan. One says how much work you can afford to lose. The other says how long you can afford to wait.
Engineers call them RPO and RTO. Most owners already know their answers by instinct; they have just never written them down, system by system. This article explains both, shows how they drive the plan, and walks through setting them for a real-looking office.
Recovery point: how much you lose
The recovery point objective (RPO) is the most work, measured in time, you are willing to lose when something fails.
If the RPO for your accounting system is 1 hour, then on the worst day you re-enter up to an hour of transactions. If it is 24 hours, you re-enter up to a day.
RPO is set by how often you copy. Back up hourly and your worst-case loss is about an hour. Back up nightly and it is about a day. A backup that has been failing quietly for a week makes your real RPO a week, whatever the plan says.
Recovery time: how long you wait
The recovery time objective (RTO) is the longest a system can be down before the cost becomes unacceptable.
RTO is set by how you restore, not how often you copy. It depends on:
- how much data has to move, and how fast the connection is
- whether replacement hardware is on hand or has to be ordered
- whether someone knows the steps, or has to work them out under pressure
- what has to come back first, because other systems depend on it
A typical 500 GB server can be restored to new hardware overnight. If the business cannot wait overnight, it needs a different method, such as starting the server from its backup as a cloud virtual machine while the hardware is replaced.
The clock starts earlier
Both numbers sound as if they start at the moment of failure. In practice, two gaps come first.
Detection. If a file is damaged on Monday and noticed on Thursday, the recovery point you need is from before Monday, and you have already lost three days of clean copies to choose from.
Decision. Hours can pass while people try to fix the live system before anyone decides to restore. That time counts against your RTO just as much as the restore does.
Set your targets with both gaps in mind, and write down who is allowed to make the call to restore.
Example: a 28-person freight brokerage
Take a 28-person freight brokerage. Dispatchers book loads all day in a dispatch system on one server. Accounting runs on the same server. Email and documents live in Microsoft 365, and laptops hold rate sheets and drafts.
The owner sits down with two questions for each system: how much could we lose, and how long could we wait?
| System | Recovery point | Recovery time | Why |
|---|---|---|---|
| Dispatch | 1 hour | 4 hours | Loads not booked today go to a competitor |
| Accounting | 1 hour | 1 business day | Invoicing can wait a day; re-keying payments is slow |
| Microsoft 365 mail | A few hours | 1 business hour per item | Most lost mail can be resent or found |
| Laptops | 1 hour | 1 business day | One person down is a nuisance, not a stoppage |
| Closed-load archive | 1 day | 1 week | Needed for disputes, rarely in a hurry |
The plan follows from the table:
- The server gets a nightly image and hourly file versions, which meets the 1-hour recovery point for both dispatch and accounting.
- The 4-hour recovery time for dispatch rules out ordering a new server and restoring overnight. Dispatch needs a standby option.
- Laptops back up hourly while online and restore to a new machine within a business day.
- Microsoft 365 is copied three times a day, with Microsoft’s own recycle bin covering same-day deletions.
Notice what the table did. It showed that one system out of five needs the expensive treatment. Without it, the brokerage would either overspend on everything or underspend on the one system that stops the business.
Four common mistakes
- One number for everything. A single target for the whole business either overspends on the archive or underspends on the system that earns money today.
- Mixing the two up. Hourly backups give you a short recovery point. They do nothing for recovery time if the restore still takes two days.
- Forgetting dependencies. An app server is no use until the database and sign-in systems it relies on are back. Its recovery time includes theirs.
- Forgetting people. A 4-hour target overnight assumes someone is awake to start the restore, with the logins to do it.
Shorter numbers cost more
Every step down in RPO or RTO costs something:
- From nightly to hourly copies: more bandwidth and more stored versions. Usually modest.
- From restoring overnight to running again in 4 hours: a standby environment, paid for whether you use it or not.
- From hours to minutes: duplicate hardware or systems running all the time. For a business of 5 to 200 people this is rarely worth it.
So the honest approach is to set each number as long as the business can really bear, and no shorter. A plan where everything has a 15-minute target is a plan nobody will pay for, or one that quietly does not meet its own targets.
Our targets, for reference
These are the targets we work to. They are targets, measured in our quarterly drills, not guarantees:
- a single file or mailbox item within 1 business hour of the request
- a full workstation within 1 business day
- a server started as a cloud virtual machine within 4 hours, on the Standby Recovery plan
Standby Recovery requires the Server Backup plan. A failed server boots from its backup as a cloud virtual machine, staff connect over a secure tunnel, and it can run that way for up to 30 days per incident while the hardware is fixed. A plan for moving back is included. It starts from $149 per server per month (indicative).
Write the numbers down
Targets that live in one person’s head do not help on the day. They belong in a recovery runbook: a written document listing each system, its recovery point and recovery time, the order in which to restore things, and who to contact.
The Recovery Runbook plan produces exactly that in 3 to 4 weeks: interviews, a system map, a recovery point and time for each system, a step-by-step restore order, a contact tree and one tabletop exercise, delivered as a PDF and a printed binder. To write your own, see how to write a recovery runbook.
Test the numbers too
A recovery time is a guess until someone has timed a restore. Time one, compare it with the target, and then change either the method or the target. How to test a restore without breaking anything covers the method.
For context, Sophos’s State of Ransomware 2025 found that 53% of organizations fully recovered from a ransomware attack within a week, up from 35% the year before. For a 25-person firm, a week is a long time to run on workarounds. Knowing your numbers in advance, and having tested them, is how you aim for the shorter end.
Five questions to set your own
- Which systems would stop work if they failed this afternoon?
- For each one, how many hours of lost work could you re-create, and from what?
- For each one, how many hours or days could people work around it?
- Which systems must come back before others can work at all?
- Do your current backup schedule and restore method meet those numbers, and how do you know?
The backup and recovery glossary defines RPO, RTO, failover, failback and the other terms you will meet when comparing plans.
Put numbers to your own systems
If you would like help putting numbers to your own systems, the free backup check is a calm place to start. Over 45 minutes, remotely, we look at what you have, run one test restore and send a written page of findings. Book a free backup check when it suits you.
