What is a recovery point objective (RPO)?
The recovery point objective is the maximum amount of data, measured in time, that an organisation accepts to lose after an incident. An RPO of 24 hours means a restore may bring back the data as it stood up to a day earlier.
Written by Paul Madelénat. Last updated
What the recovery point objective measures
The recovery point objective answers one question: if this system fails now, how far back in time can we afford to go? It is set by the business, not by the technology. A wiki that changes a few times a day can tolerate losing a day of edits. A finance database or a case management system usually cannot.
RPO is expressed as a duration. It is not a promise that nothing is lost. It is the ceiling on what may be lost, and it drives how often data has to be copied somewhere safe. If backups run once a day, the achievable RPO is about a day. A shorter RPO needs more frequent backups, continuous database archiving or replication to a second location.
RPO travels with its partner, the recovery time objective, which measures how long the system may stay down. Together they describe what a disaster recovery plan has to deliver.
How to set an RPO
Start from the data, not from the tools. For each app, ask what would have to be re-entered by hand if the last hours disappeared, who would notice, and what it would cost. Then check the answer against the backup schedule. A common gap is an RPO written in a policy that the backup job cannot meet.
Two details matter in practice. The backup must be consistent, so the database and the files it references come from the same moment. And the backup must restore: an RPO backed by copies nobody has tested is a guess.
RPO at Pilae
Every app Pilae operates is backed up daily, encrypted before it leaves the machine and stored offsite in the country you choose. The Pilae Agent also takes and verifies a fresh backup before every change, so an update never moves you further from your last good copy. Apps that need a shorter recovery point get more frequent backups.
Your contract states the RPO for each app, per plan, and every month an engineer restores your apps into an isolated environment and records the result in the console. Read how this works on the backups and recovery page, or talk to an engineer about the objectives your apps need.