Backup & Continuity
RTO vs RPO explained: setting recovery targets for a small business
RTO is how long you can be down. RPO is how much data you can lose. What each means, how they drive backup spending, and a worked example for a 25-person firm.
By Dig IT SolutionsUpdated 8 September 20266 min read
Short answer
Recovery time objective (RTO) is the maximum time a system can be unavailable before the damage becomes unacceptable. Recovery point objective (RPO) is the maximum amount of data, measured in time, you can afford to lose. RTO drives how you recover and what standby capacity you need. RPO drives how often you back up. Set both per system.
Every backup and recovery decision comes down to two numbers, and most small businesses have never written them down. Recovery time objective and recovery point objective sound like jargon, but they are simply the answers to two questions the directors already have opinions about: how long can we be down, and how much work can we afford to lose? This article explains both, shows how they drive spending, and works through an example for a 25-person firm.
Recovery time objective (RTO)
RTO is the maximum time a system can be unavailable before the harm becomes unacceptable. It runs from the moment of failure to the moment staff can use the system again, not to the moment IT starts working on it.
An RTO is a business judgement. Four hours without email is annoying. Four hours without the phones during the sales day loses orders. Four days without the accounts system in the last week of the month is a payroll problem. Different systems get different RTOs, and the list, sorted shortest first, becomes the order of restoration in the recovery plan.
RTO is met by recovery arrangements: image-based backups that rebuild a whole server rather than file by file, a local copy that restores at network speed, somewhere to restore to (spare hardware, a virtualisation host, cloud capacity), documented procedures and a second person who can execute them. The relationship is set out in backup vs disaster recovery.
Recovery point objective (RPO)
RPO is the maximum amount of data, measured in time, you are prepared to lose. When the system comes back, everything since the last good backup is gone. A nightly backup gives a 24-hour RPO at worst: fail at 5pm and the day's work is lost. A backup every two hours gives a two-hour RPO.
RPO is met by backup frequency and retention. Frequent backups shorten it. Long retention protects against problems discovered late. The 3-2-1 rule governs where the copies live.
Why the two are independent
A business can have a superb RPO and a hopeless RTO. It backs up every 15 minutes, so it will lose almost no data, but the backups are in the cloud, the server is dead, replacement hardware is a week away and nobody has documented the rebuild. Data loss: 15 minutes. Downtime: eight days.
The reverse also happens. A business replicates its server to a standby so it can fail over in minutes, but the only backups are nightly and kept for seven days. Downtime: minutes. Data loss after a corruption discovered on day nine: everything.
What each target costs
Shorter targets cost more. As a rough guide for an SME:
| Target | What it typically needs |
|---|---|
| RPO 24 hours | Nightly backup |
| RPO 4 hours | Backup every few hours to a local NAS, replicated to cloud |
| RPO 15 minutes or less | Continuous replication or near-continuous snapshots |
| RTO 2 to 3 days | Cloud backup only, restore to replacement hardware when it arrives |
| RTO 4 to 8 hours | Local image backup on a NAS plus somewhere to restore to, tested runbook |
| RTO under 1 hour | Standby server or cloud failover kept in sync, automated |
Cloud services change the arithmetic for some systems. Microsoft 365 email carries on when the office server dies, so its RTO is about account recovery rather than hardware, but it still needs an RPO delivered by an independent backup. Hosted VoIP keeps working from mobiles when the office is closed, so its RTO is mostly about having configured the divert.
A worked example: a 25-person firm
Take a 25-person professional services firm in Hertfordshire: a managing director, two other directors, a finance manager, fourteen fee earners and seven support staff. Systems: Microsoft 365 for email and documents, a practice management application on a Windows server, an accounts package, hosted VoIP, and a file server holding scanned client records.
Step 1: the directors set the targets. In a two-hour meeting they agree:
| System | RTO | RPO | Reasoning |
|---|---|---|---|
| Phones | 1 hour | n/a | Clients ring. Missed calls are missed work. |
| Email and documents (Microsoft 365) | 4 hours | 24 hours | Service stays up. A deleted mailbox can wait until tomorrow's backup. |
| Practice management server | 4 hours | 2 hours | Fourteen fee earners record time and matters here. Re-keying a day is a nightmare. |
| Accounts | 8 hours | 4 hours | Critical at month end, tolerable otherwise. |
| File server (scanned records) | 24 hours | 24 hours | Reference material. Rarely changes. |
Step 2: cost the downtime. The firm estimates that fee earners bill around £110 an hour on average and that a full outage of the practice management server idles them entirely. Fourteen fee earners for an eight-hour day is roughly £12,000 of billable time, before support staff salaries, client goodwill and the cost of re-entering lost data. Illustrative figures, but the kind that make a four-hour RTO worth paying for.
Step 3: compare with today. The current arrangement is a nightly cloud backup of the server and nothing for Microsoft 365. A test restore shows the server would take about 30 hours to pull back from the cloud and rebuild, and that is if replacement hardware were available. Actual RTO: two to three days. Actual RPO: 24 hours. Neither target is met and the Microsoft 365 RPO is undefined.
Step 4: design to the targets. A Synology NAS on the local network takes image backups of the practice management and accounts servers every two hours and replicates to encrypted cloud storage overnight, with an immutable snapshot retained locally. A Microsoft 365 backup runs daily. The runbook for restoring the server image to the firm's virtualisation host is written and tested at two and a half hours. The phone divert to mobiles is configured and tested. Every target is now met, and the whole design costs less per year than a single day of the outage it prevents.
That pattern, frequent local backups plus a cloud copy, is what Dig IT runs for clients such as Mr Plant Hire, whose servers are backed up locally several times a day and to the cloud.
Common mistakes
- Targets set by IT alone. They end up either unaffordable or unrealistic. Directors have to own the trade-off.
- One target for everything. Wastes money on the archive and starves the systems that matter.
- Assumed rather than tested. The achievable RTO is what the stopwatch says during a real restore, not what the brochure says.
- Forgetting cloud data. Microsoft 365 has no RPO until something independent backs it up.
- Never revisited. A new line-of-business system or a doubling of headcount changes the numbers.
Putting the numbers to work
Once RTO and RPO are agreed per system, they belong in three places. The backup design, so frequency and location match the RPO. The recovery runbook, so systems are restored in RTO order. And the business continuity plan, so workarounds cover the gap between failure and restoration. Test against them at least annually and record the result. Dig IT's business continuity planning service runs that target-setting session with directors and turns the answers into a tested design.
What to do next
If your business has never written down an RTO and RPO for its main systems, a two-hour session with the directors will produce them, and a test restore will show how far the current setup is from meeting them. Book an IT health check and Dig IT will run both and report the gap.