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 that if an incident occurs at 4 pm, you accept going back to the state at 12 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 length of time. 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, the US standards body, defines the RPO in its contingency planning guide (SP 800-34) as the point in time, prior to the disruption, to which data can be restored from the most recent copy. In French, ANSSI uses the term 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 therefore works 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 it takes to detect a failure.
- A backup every night at 10 pm gives an RPO of around 24 hours at the end of the day, less if the incident occurs 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 an outright failure. It does not give a short RPO in the event of corruption: the clean point is the last copy taken before the corruption, which may be several hours old.
ANSSI is clear on this point: when the PDMA requirement is under 24 hours, other solutions such as synchronous or asynchronous replication often need to be favoured, in addition to backup. For databases, Microsoft notes that frequent transaction log backups make it possible to return to a specific point in time, which shortens the RPO without multiplying full backups.
Announcing an RPO of fifteen minutes 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 clean copy |
| Hourly backup | About 1 h | Date of the last clean copy |
| Frequent database logs | A few minutes | Chosen point in time before the incident, if the history exists |
| Replication alone | A few seconds | No clean point if the copy followed the attack |
RPO and business needs
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 ample and sufficient.
- Mailbox: a day of lost 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 sensitive the volume of changes to transfer is to 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 means 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. It is better to say: “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: an older, clean 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 make explicit. 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 built in: it relies on 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 the question ‘how much work can we lose?’, the RTO ‘how long can we remain at a standstill?’. The two are independent: you can have very frequent copies (short RPO) and a slow restore (long RTO), or the opposite. A recovery plan states both figures, service by service.
Is an RPO of zero possible?
For an outright hardware failure, synchronous replication can come close. But it also immediately copies a deletion, a corruption or ransomware encryption. In those cases, the clean point is the last historical copy taken before the incident, which may be several hours old. An RPO of zero ‘for every scenario’ practically does not exist.
What 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 throughout the day, and a few minutes to an hour for a point-of-sale system. The method is detailed in ‘How do you determine your RPO?’.
Further reading
Sources
Documents consulted in October 2026.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Backing up information systems – The fundamentals (ANSSI-BP-100, v1.1, 27 November 2025) — ANSSI (French agency)
- Back up and Restore of SQL Server Databases — Microsoft Learn
- Offsite backup offers and prices — WeDoBack
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.