RPO and RTO: how much data and how much time you can afford
Every backup and disaster recovery (DR) plan starts with two numbers. RPO (Recovery Point Objective) is the maximum amount of data you can afford to lose, measured in time. If the RPO is 4 hours and the system fails at 3 p.m., you must have a restore point from 11 a.m. at the latest. RTO (Recovery Time Objective) is the time within which a system must be running again after an incident.
RPO therefore sets how often you back up or replicate, and RTO how you recover: with a classic restore from a copy, by starting a virtual machine straight from the backup (Instant Recovery), or by failing over to a replica in a second data centre. Both numbers must be set by the business, because the answer to the question "what does an hour of downtime cost us?" is a business answer, not a technical one.
| System group | Example | Typical RPO | Typical RTO | Usual approach |
|---|---|---|---|---|
| Critical | ERP, online shop, production systems, identities | 15 min to 1 h | 1–4 h | Replication or CDP plus backups |
| Important | Email, file servers, CRM | 4–12 h | 8–24 h | Several backups a day, instant recovery |
| Other | Archives, development and test environments | 24 h | 72 h or more | Daily backups |
The values in the table are only a starting point. Shorter RPO and RTO mean higher cost, so sort systems into groups and do not set the same targets for all. To check how quickly you could restore each group and whether your backup frequency is enough, use the calculator on this page.
The 3-2-1-1-0 rule
The classic 3-2-1 rule calls for three copies of your data on two different media, one of them at another location. Because ransomware now attacks backups first, the rule has been extended to 3-2-1-1-0.
| Number | Requirement | What it protects against |
|---|---|---|
| 3 | At least three copies of data (production and two backups) | Failure of a single copy |
| 2 | Two different types of media or storage | A fault or failure of one type of storage |
| 1 | One copy at another location (offsite) | Fire, flood, loss of a site |
| 1 | One copy immutable or physically separated | Ransomware, a malicious administrator, deletion errors |
| 0 | Zero errors in automated verification and restore tests | Copies from which restore does not work |
Every additional copy needs space. How much you need depends on the amount of data, the daily change rate, retention and the compression ratio. The calculator estimates the space for one copy and for all copies together.
Immutable and separated copies against ransomware
An attacker who gains administrator access to the domain usually looks for the backup server first and deletes or encrypts the copies. Only then do they start encrypting production. If you have no copy they cannot destroy, you are left with paying a ransom or rebuilding your systems from scratch.
- Immutable copies. For a set period they cannot be changed or deleted, even with administrator rights. They can be implemented with a hardened Linux repository, object storage with object locking (S3 Object Lock) or with a service provider.
- Physically separated copies (air gap). Copies on tape or disconnected media that cannot be reached over the network.
- Separate credentials. The backup system should not sit in the production domain, and access to it should be protected with multi-factor authentication (MFA).
- A long enough immutability period. Attackers are often in the network for days or weeks before they reveal themselves. The immutability period should therefore cover at least the daily retention.
For more on preparing for an attack and the first hours after it, read the guide cyber attack: readiness assessment.
Backup, replication and disaster recovery
The terms are often mixed up, but they cover different needs. Backup keeps a history of restore points and lets you return to the state before an error, deletion or attack. Replication maintains a near-live copy of the system at another location, so it allows a short RPO and RTO, but it also quickly carries errors and encryption over to the copy. Continuous data protection (CDP) reduces the RPO to a few seconds.
Disaster recovery (DR) is not a technology but a plan: which systems are restored first, where they will run, who decides on the failover, how the network is redirected and how users connect. A good DR plan for critical systems combines replication for a fast failover with immutable backups for the case where the replica is infected too.
Whether a higher DR level pays off is a business decision. The calculator works out the cost of an hour of downtime and the expected annual loss and compares them with the annual cost of a better DR level. If you are also thinking about replacing servers or moving to the cloud, see the calculator buy, lease or cloud.
Testing restores
A backup you have not tested a restore from is only an assumption. In incidents it often turns out that the copies did not contain all the data, that the restore takes several times longer than expected, or that passwords, licences and documentation are missing.
- Automated verification. Software such as Veeam can check the integrity of copies with every job and start a virtual machine in an isolated environment to check that services respond.
- Regular restore tests. Restore whole critical systems at least quarterly and measure the actual time. Compare the result with the target RTO.
- An annual DR exercise. At least once a year, test the whole plan, including the restore order, network, identities and communication.
- Documentation. Restore instructions, contacts and credentials must be reachable even when production systems are down.
When estimating RTO, remember that recovery does not start at the moment of the outage. Before that, the incident has to be detected, a decision made and the environment prepared. With ransomware you first need to find a clean restore point, which can take longer than the data transfer itself.
Cloud and offsite copy: Veeam Cloud Connect
For many companies the second location is the biggest obstacle to the 3-2-1 rule. A second data centre of your own means hardware, space, links and maintenance. The alternative is an offsite copy with a service provider.
Veeam Cloud Connect lets an existing Veeam Backup & Replication installation send backups or replicas to a provider's data centre over an encrypted connection. The copies can be immutable, and the provider keeps them separate from your domain, so they meet both the requirement for a second location and for an immutable copy. With cloud replicas, in a disaster you can start critical systems right in the provider's data centre.
When choosing a provider, check the location of the data centre and GDPR compliance, the data centre tier (for example TIER III), the link speed for the initial transfer and restore, the immutability period and restore support. With large volumes of data, restoring from the cloud can be slower than a local restore, so include the restore speed from the offsite copy in your RTO estimate.
Humanfrog is a Veeam Silver Cloud Service Provider with TIER III data centres in Slovenia. We provide backup as a service, offsite and immutable copies, replication and disaster recovery planning.
Backup and DR checklist
- Inventory your systems and sort them into groups by importance to the business.
- For each group, agree RPO and RTO and the cost of an hour of downtime with management.
- Check that backup frequency meets the RPO; for an RPO under one hour, use replication or CDP.
- Ensure three copies on two media, one at another location and one immutable.
- Separate the backup system from the production domain and protect it with MFA.
- Estimate the space for all copies and retention and allow a reserve for growth.
- Define the restore order: identities, network, critical applications, communication.
- Verify copies automatically and test the restore of critical systems at least quarterly.
- Run a DR exercise at least once a year and update the documentation.
If you want to check the results of the calculator with an expert, or need an offsite and immutable copy in a data centre in Slovenia, get in touch.
