Your expert in backup and data protection!The solution tailored to your needs
DRP and BCP
What is an RPO?
The RPO (Recovery Point Objective) is the maximum acceptable age of the last restorable copy. An RPO of four hours means: if an incident occurs at 4 pm, you accept going back to the state at noon and redoing at most four hours of work. It does not say how long the repair will take: that is the RTO.
Key points
- The RPO measures acceptable data loss, as a duration. The RTO measures acceptable downtime.
- The actual RPO cannot be shorter than the interval between two successful backups, plus the time it takes to notice a failure.
- It is chosen per activity (point of sale, ERP, email, files), not for the whole company.
- ANSSI, France’s national cybersecurity agency, calls it PDMA (maximum tolerable data loss) and states that below 24 hours, replication should often be considered in addition to backup.
- Replication gives a short RPO in the event of a failure, not in the event of ransomware or corruption.
Official definition
NIST, in its contingency planning guide (SP 800-34), defines the RPO as the point in time, prior to the disruption, to which data can be recovered from the most recent copy. In French, ANSSI refers to the maximum tolerable data loss (PDMA). It points out that a backup strategy must take into account the PDMA defined for each business asset of the information system.
The RPO is therefore read like a stopwatch running backwards: it looks back from the incident to the last usable copy.
How it translates into backups
The RPO cannot be shorter than the interval between two successful backups, plus the time needed to detect a failure.
- A nightly backup at 10 pm gives an RPO of about 24 hours at the end of the day, less if the incident happens in the morning.
- An hourly backup gives an RPO of one hour, if that hour’s backup succeeded and contains consistent data.
- Continuous replication can approach an RPO of a few seconds for a clear-cut failure. It does not give a short RPO in the event of corruption: the healthy point is the last copy prior to the corruption, which may be several hours old.
ANSSI says it plainly: when the PDMA requirement is below 24 hours, other solutions such as synchronous or asynchronous replication should often be favoured, in addition to backup. For databases, Microsoft for its part points out that frequent transaction log backups make it possible to return to a precise point in time, which shortens the RPO without multiplying full backups.
Announcing a fifteen-minute RPO with a single nightly job is a contradiction. The actual RPO is that of the job.
| Mechanism | Typical RPO for a hardware failure | Typical RPO for ransomware or corruption |
|---|---|---|
| Daily backup | Up to 24 h | Date of the last healthy copy |
| Hourly backup | About 1 h | Date of the last healthy copy |
| Frequent database logs | A few minutes | A point in time chosen before the incident, if the history exists |
| Replication only | A few seconds | No healthy point if the copy followed the attack |
RPO and the business
The RPO is chosen per activity, not for “the company” as a whole.
- Accounting entered continuously: losing a day of reconciliation costs hours of re-entry. Short RPO.
- Price catalogue updated once a month: an RPO of 24 hours is generous and sufficient.
- Mailbox: a lost day of messages is hard to recover, because senders will not resend everything. RPO of one to a few hours if email is critical, 24 hours otherwise.
- Instant messaging: often excluded from the RPO, by explicit choice.
What the RPO costs
The shorter the RPO, the more frequent the copies, the more the volume of changes to transfer depends on bandwidth, and the more responsive monitoring has to be. Going from 24 hours to 1 hour multiplies the jobs. Going from 1 hour to 1 minute generally requires replication, with a different budget and a different risk (copying the attack).
A misleading phrase
“We lose no data” is an RPO of zero. It is rarely true, and never true for ransomware if the only copy is synchronous. Say instead: “we lose at most N minutes of this system, and we can go back N days if the recent data is bad”.
At WeDoBack
WeDoBack does not publish a single guaranteed RPO for all customers. The RPO depends on the frequency the customer chooses in the console, within the limits of what their volume and bandwidth allow them to send. For the DRP, the version brought back online is the one the customer chooses from this history: a slightly older, healthy copy may be preferable to the very latest one. For the BCP, the takeover is immediate in terms of traffic, but the data on the instance is the data already transmitted: the RPO depends on this lag, which the contract must state explicitly. It is not zero simply because the instance is running. Replication or synchronisation of data between the BCP instance and the original server is not native: it requires a specific process, tailored to the need, which WeDoBack can set up on the basis of a quote.
Frequently asked questions
What is the difference between RPO and RTO?
The RPO answers “how much work can we lose?”, the RTO “how long can we stay down?”. The two are independent: you can have very frequent copies (short RPO) and a slow restore (long RTO), or the reverse. A recovery plan writes down both figures, service by service.
Is an RPO of zero possible?
For a clear-cut hardware failure, synchronous replication can come close. But it also immediately copies a deletion, a corruption or ransomware encryption. In those cases, the healthy point is the last historical copy prior to the incident, which may be several hours old. An RPO of zero “for every scenario” practically does not exist.
Which RPO should an SME choose?
There is no standard value. A common starting point is 24 hours for office files, one to four hours for an ERP or quoting software used all day, and a few minutes to one hour for a point-of-sale system. The method is detailed in “How do you set your RPO?”.
Further reading
Sources
Documents consulted in October 2026.
Planning a backup, DRP or BCP project?
More than 20 years of experience protecting business data.
Request a quote+33 9 72 50 78 28Protect your data with WeDoBack
Encrypted offsite backup, immutable storage, DRP and BCP: tell us about your servers and we will recommend the right combination.