In this guide · 8 sections
- 01RTO and RPO meaning in plain English
- 02A worked example: the morning the server fails
- 03Setting RTO and RPO for each system
- 04What backup schedule each target needs
- 05Why tighter RTO and RPO cost more
- 06How to test whether you meet your RTO and RPO
- 07Do it yourself or get help?
- 08Frequently asked questions
Short answer
RTO (recovery time objective) is the longest a system can stay down before it seriously hurts the business. RPO (recovery point objective) is how far back in time you can afford to lose data. An RPO of 24 hours means daily backups are enough; an RPO of 1 hour means hourly or continuous backups.
RTO and RPO meaning in plain English
Both terms come from IT continuity planning. NIST, the US standards body, defines recovery time objective as the overall length of time a system can be in the recovery phase before it negatively affects the organisation, and recovery point objective as the point in time to which data must be recovered after an outage. Both definitions come from NIST SP 800-34, its contingency planning guide.
| RTO | RPO | |
|---|---|---|
| Question it answers | How long can we be without this system? | How much recent work can we afford to redo or lose? |
| Measured | Forward from the failure, until it works again | Backward from the failure, to the last good copy |
| Driven by | How fast you can restore or switch over | How often you back up or replicate |
| Example | Accounting system back within 1 business day | Lose no more than 1 day of invoices |
A simple way to remember it: RPO looks back to your last backup, RTO looks forward to when you are working again.
A worked example: the morning the server fails
The example shows why the two numbers are set separately. More frequent backups shrink data loss but do nothing for restore speed. A faster restore needs a different method, such as a local copy, a standby device or a cloud system that does not need restoring at all.
Setting RTO and RPO for each system
Do not set one RTO and RPO for the whole business. List your systems and ask two questions for each: what happens if it is down for a day, and what happens if we lose a day of data? The answers usually split systems into a few tiers. The starting points below are illustrations to discuss with your team, not rules.
| System | Starting RTO | Starting RPO | Why |
|---|---|---|---|
| Email (Microsoft 365, Google Workspace) | Hours (provider-run) | Up to 24 hours for deletions | The provider keeps the service running; your risk is deleted or encrypted mail |
| Accounting (Xero, QuickBooks) | 1 business day | 24 hours | Cloud-hosted; risk is bad imports or deleted records |
| POS and payments | Minutes to 1 hour | Near zero for sales | Every minute down loses sales; sales data must not vanish |
| Website (brochure) | 1 to 2 days | Since the last content change | Changes rarely; a weekly or daily copy is enough |
| Online store or bookings | A few hours | 1 hour or less | Orders and bookings arrive all day |
| Shared files (NAS, OneDrive, Drive) | 1 business day | 4 to 24 hours | Depends how much editing happens each day |
Write the agreed targets into your IT business continuity plan so that, during an outage, nobody is debating what good enough looks like.
What backup schedule each target needs
Your RPO sets the minimum backup frequency. Your RTO sets how the backup is stored and restored.
- RPO of 24 hours: a daily backup is enough, as long as it runs every day and you get an alert when it fails.
- RPO of 1 to 4 hours: hourly snapshots, or a sync plus versioning that keeps every change. Common on NAS devices and backup services.
- RPO near zero: continuous replication or a system that writes each transaction to two places, as most cloud POS and payment platforms do.
- RTO of 1 business day: cloud backup is usually fine, if you have tested how long a full restore takes over your internet line.
- RTO of minutes to hours: you need a local copy, a spare device ready to go, or a cloud service with built-in failover.
Our guide to choosing a backup service compares cloud, NAS and hybrid set-ups for these targets.
Why tighter RTO and RPO cost more
Every step towards zero downtime and zero data loss costs more: more frequent backups mean more storage, faster recovery means standby hardware or premium services, and both need more testing. For most small businesses the sensible approach is tight targets for the one or two systems that earn money every hour, and relaxed targets for everything else.
Tighter targets make sense for
- POS, payments and online orders
- Booking systems with same-day appointments
- Files your team edits all day
Looser targets are fine for
- A brochure website that changes monthly
- Archive folders and old projects
- Systems with a manual fallback, like paper sign-in sheets
How to test whether you meet your RTO and RPO
Targets mean nothing until you have timed a restore. NIST's Cybersecurity Framework lists Recover as one of its core functions alongside Protect and Respond. A recovery plan you have never run is a guess.
Pick one system and a realistic failure
For example, a deleted project folder, a lost laptop or a website that will not load after an update.
Note the newest backup available
The gap between that backup and now is your actual RPO. Compare it with your target.
Restore to a test location and time it
Start a timer when you begin and stop it when the system or files are usable. That is your actual RTO.
Check the result works
Open the files, log in to the restored site, check permissions and recent records.
Fix the gap and write it down
If you missed a target, change the backup frequency or method. Record the date, times and result for your continuity plan.
For websites, our guide to restoring a website backup walks through the restore itself.
Do it yourself or get help?
Setting RTO and RPO is a one-hour conversation you can have yourself: list systems, agree targets, then check whether your backups match. The harder part is configuring backups that actually meet the targets and proving it with a test.
Our Backup & Ransomware Recovery (S$290) sets up daily off-site website backup and Microsoft 365 or Google Workspace backup, a retention plan, a test restore with proof and a one-page recovery guide. Backup subscription fees are billed to you, on accounts you own.
Frequently asked questions
RTO, recovery time objective, is how long a system can be down before it seriously hurts the business. RPO, recovery point objective, is how much data you can afford to lose, measured back from the failure to your last good copy. RTO drives how fast you restore; RPO drives how often you back up.
For most office files and cloud accounting, 24 hours is a common starting point, which daily backups can meet. Systems that take orders, bookings or payments all day usually need one hour or less. Set it per system based on how much work you could realistically redo.
Both keep the service running and offer limited recovery of deleted items. Microsoft keeps permanently deleted mail for 14 days by default, up to 30, and Google admins can restore Drive files for 25 days after the trash is emptied. Neither replaces a separate backup for ransomware, long-delayed discoveries or account deletion.
Run a test restore. Choose a realistic failure, start a timer, restore the system or files to a test location and stop the timer when they are usable. Repeat at least once a year for key systems and after any change to your backup set-up.
Close to zero is possible with replication and automatic failover, as large cloud platforms provide for their own services. For a small business running its own systems, zero usually costs far more than the risk it removes. Aim for near zero only on systems where every minute of downtime or lost data costs real money.