Most companies have some kind of backup. Far fewer can say how much work they would lose after a failure, how long they would be without their systems, or whether anyone has ever restored from those copies. RPO and RTO turn those questions into decisions a manager can make.
This guide explains RPO and RTO in plain language, shows how to set them for each part of your business, and walks through the 3-2-1 backup rule and its newer 3-2-1-1-0 variant. It also covers cloud services, ransomware and restore testing, and it is written for managers as much as for IT staff.
What RPO and RTO mean, and how they differ
RPO (recovery point objective) is how much data you can afford to lose, measured in time. If your RPO for the accounting system is four hours, your copies must never be more than four hours old. RTO (recovery time objective) is how long the business can be without a system before the damage becomes unacceptable. If the RTO for email is two hours, email must be working again within two hours of the failure.
A simple way to keep them apart: RPO looks backwards, at the last good copy; RTO looks forwards, at the moment work resumes.
A worked example (illustrative numbers only)
These figures are invented to show the arithmetic, not to recommend targets.
- An order system is backed up nightly at 22:00.
- The server fails at 16:00 the next day. The latest copy is 18 hours old, so everything entered since 22:00 is gone. The effective RPO is up to 24 hours, because a failure just before the next backup would lose a full day.
- Restoring the server, reinstalling the application and checking the data takes six hours. The achieved RTO is six hours, from 16:00 to 22:00.
- If the business decided it could lose at most one hour of orders and wait at most two hours, the nightly backup and the six-hour restore both miss the target. The gap shows what has to change: more frequent copies, faster recovery, or both.
Tighter objectives cost more, so set them per system, not once for the whole company.
Example 2: different targets for different systems
Picture a fictional professional-services firm that follows the sequence in the next section and ends up with four tiers. The figures are invented to illustrate the idea; they are not recommended targets.
| System | Example RPO | Example RTO | What it implies |
|---|---|---|---|
| Invoicing database | 1 hour | 4 hours | Frequent copies of the data, and a restore procedure that someone has practised |
| Email and calendars | 4 hours | 4 hours | A copy held apart from the mail service itself, as described below |
| Shared project files | 1 day | 1 working day | A nightly copy is enough, provided the restore fits inside the working day |
| Archive of closed projects | 1 week | 1 week | A weekly copy on slower storage, restored only when someone asks for an old file |
The targets differ widely, so one policy for everything would either over-protect the archive or under-protect invoicing. And each row only becomes reliable once it is compared with a measured restore time.
Example 3: the dependency chain
In another fictional case, the accounting application can be restored in one hour once its server is available. It also needs the sign-in service, which takes three hours to rebuild, and the office network settings, which take two hours and were never written down.
- If one person does everything in sequence, the achieved RTO is about six hours: two for the network, three for sign-in and one for the application.
- If the sign-in service and the network settings do not depend on each other and two people can work in parallel, the application restore can start when the slower prerequisite is ready, so the RTO is about four hours.
- If nobody can reconstruct the network settings, the time is not four or six hours but unknown, which is the worst thing to learn during a real failure.
An application "RTO of one hour" describes one link, not the chain. Writing down the restore order and who does each step is a small change that can have a large effect.
How to set RPO and RTO for each business process
Start from the business, not from the technology. A practical sequence:
- List the processes that matter: taking orders, invoicing, payroll, customer support, email, shared files, production planning.
- Map each process to its systems and data: the application, its database, its file shares, the accounts it needs.
- Ask the owner two questions: how much recent work could we redo by hand, and how long could we operate without this before customers, staff or contracts are affected?
- Write the answers as an RPO and an RTO, grouping systems into a few tiers.
- Compare them with what you have today: backup frequency, retention and the time a restore actually takes.
As an illustration only, invoicing might need a short RPO and RTO while an archive of old project files tolerates a day or more. What matters is that the people who run the process make the decision and write it down, so IT does not have to guess.
Do not forget dependencies. A system restorable in an hour is useless if the identity service or network it relies on takes a day. Your realistic RTO is that of the whole chain.
The 3-2-1 backup rule explained
The 3-2-1 rule is a long-standing guideline for resilient backups:
- 3 copies of your data: the live data plus at least two backups.
- 2 different media or storage types, so one fault does not affect both. For example, a local appliance and cloud storage.
- 1 copy off-site, away from the building and from the main network, so fire, theft, flooding or a compromised office network cannot reach it.
The logic is to remove single points of failure. A second copy on the same server, or in the same account, protects against a deleted file but not against a failed disk or an attacker with administrator access.
The rule is a minimum structure. It says nothing about frequency, retention or whether copies restore correctly, so pair it with RPO and RTO targets and regular testing.
3-2-1-1-0: the modern variant
Ransomware changed what backups need to withstand. Attackers now try to delete or encrypt backups first. The 3-2-1-1-0 variant adds two points to the classic rule:
- 1 immutable or offline copy: a copy that cannot be modified or deleted for a set period, even by an administrator, or one that is disconnected from the network.
- 0 errors: backups are verified, and restore tests finish without errors. A job that reports success is not proof that the data is usable.
Immutability can come from storage features that lock data for a retention period, or from removable media kept offline.
Backup is not the same as cloud availability
Microsoft 365 and similar services are built to stay available, which is not the same as keeping a separate, recoverable copy of your information. Under the shared responsibility model, the provider runs the platform, while the customer remains responsible for its own data: who can delete it, how long it is kept and how it is recovered after a mistake or an attack.
Built-in features such as recycle bins and version history help with accidental deletion, but their retention windows are limited and differ by service and licence. Check the provider’s current documentation. They rarely cover a departing employee deleting files, malicious changes synchronised to every device, or a compromised administrator account.
This is why backup of cloud data belongs in the conversation when you set up sharing, storage and governance. If you use Microsoft 365, our Cloud and Microsoft 365 page explains how we approach setup, and our cloud services guide covers the wider question of who is responsible for what. For the sign-in and administrator settings that can make a restore less likely to be needed, see our Microsoft 365 security baseline checklist.
Ransomware resilience: immutability and separate credentials
A backup that the attacker can reach is not a safety net. Three habits make the difference:
- Separate credentials. Backup administration should not use the same accounts as day-to-day administration or the main directory. If a domain administrator account is stolen, it should not be able to delete the copies.
- Immutability or offline storage. At least one copy should resist deletion and encryption, as described above.
- Limited, protected access. Few people should change backup settings, with multi-factor authentication and alerts when retention is shortened or jobs are disabled.
Backups are one part of wider protection. Account security, patching and incident preparation reduce the chance that you need to restore at all. Our cybersecurity services look at those areas together. If you are comparing providers, our guide to choosing cybersecurity services lists questions to ask.
A backup you have not restored is an assumption
Restore failures have mundane causes: a database copied while in use, a folder missing from the job, an expired credential, a restore that works but takes three days. Only a test reveals them.
- Test regularly, at a frequency that matches how often your systems change. At least once a year, test a full recovery of your most important system.
- Restore into a separate environment, so a test cannot overwrite live data.
- Time it. Compare the real duration with your RTO, and the age of the restored data with your RPO.
- Record the result: what was restored, how long it took and what went wrong.
- Test the people too: who decides, who is informed, where the instructions are kept.
A restore-test checklist
Use this as a working list for each test. It assumes you already have an RPO and an RTO for the system.
Before the test
- Pick one system and one scenario: a deleted folder, a failed server, a lost mailbox or an account locked by an attacker.
- Write down the targets for that system, so the result has something to be compared with.
- Name three roles: who runs the restore, who checks the data and who decides whether the test passed.
- Check access to the instructions and credentials: where they are kept, and whether they depend on the system being restored, such as a password vault hosted on the failed server.
During the test
- Start the clock when the failure is declared, not when the restore begins, and note every wait: finding credentials, downloading data, asking for approval.
- Restore into a separate environment, so the test cannot overwrite live data.
- Check the result by using it: open sample files, run a report and confirm that a user can sign in and see current data. A clean log is not enough.
- Try a small restore as well as a large one. A single file or mailbox item is often the request you will meet most.
After the test
- Compare the gap between the last good copy and the failure with your RPO, and the elapsed time with your RTO.
- Record each gap with an owner and a date, then fix it and repeat the same scenario if a target was missed.
- Schedule the next test, and repeat it after major changes such as a migration or a new backup product.
If you are working through NIS2 readiness, the checklist in our NIS2 guide for SMEs has a backup and recovery row, and a short record of each test, with the figures measured, is the kind of evidence it suggests keeping. This is general information, not legal advice, and a restore test does not by itself show that any regulation is met.
A short checklist
- We have written RPO and RTO targets for our main processes.
- We know what is backed up, and what is not.
- We keep at least three copies, on two types of storage, with one off-site.
- At least one copy is immutable or offline.
- Backup accounts are separate from everyday administrator accounts and use multi-factor authentication.
- Microsoft 365 and other cloud data have a backup that we control.
- We have restored a real system within the last twelve months and recorded the result.
- The recovery plan is available offline, with contact details. Our disaster recovery plan guide for small businesses shows what a one-page plan can contain.
What BlueNova IT can review with you
BlueNova IT is based in Tallinn, with support in English and Spanish, Monday to Friday, 09:00-18:00 CET. As part of a cybersecurity or managed IT engagement, we can go through the following with you:
- What is backed up, and whether any important system, mailbox or file location is missing.
- Where the copies live, and whether they meet the 3-2-1 structure.
- Who can delete or change them, and with which accounts.
- Whether restores have been tested, and how the result compares with your RPO and RTO.
The outcome is a written, prioritised list of gaps for you to decide on. Scope is agreed with each organisation, and we do not promise recovery times or outcomes. Backup checks can also be part of our managed IT services. To start, contact us.
Related: Cloud and Microsoft 365, cybersecurity services, managed IT services, Choosing cloud services: SaaS, PaaS and IaaS compared, IT infrastructure management services.
Sources
- NCSC (UK): Offline backups in an online world: how to keep a backup copy offline or disconnected from live systems, including backups stored in the public cloud
- CISA: #StopRansomware Guide: prevention practices and a response checklist, including keeping offline, encrypted backups and testing that they can be restored
- Microsoft Learn: Data resiliency in Microsoft 365: how the Microsoft 365 platform is designed for availability and recoverability
- Microsoft Learn: Shared responsibility in the cloud: which tasks the cloud provider handles and which stay with the customer
