{"head":{"title":"What Is RPO (Recovery Point Objective)? | OceanLab","description":"RPO is the point in time you must be able to restore data to after an outage, in other words how much data you can afford to lose. Example and mistakes.","canonical":"https://oceanlab.in/glossary/rpo"},"crumbs":[{"name":"Home","path":"/"},{"name":"Glossary","path":"/glossary"},{"name":"RPO","path":"/glossary/rpo"}],"slug":"rpo","term":"RPO (recovery point objective)","aka":["recovery point objective"],"category":"Reliability","short":"The point in time to which data must be recoverable after an outage: in practice, how much recent data you can afford to lose.","body":[["NIST defines RPO as the point in time to which data must be recovered after an outage. If your RPO is one hour, then after a failure you must be able to restore data from no more than an hour before it happened."],["RPO is set by the business and met by the backup design. An RPO of 24 hours can be met with nightly backups. An RPO of minutes needs continuous replication or point-in-time recovery. It is paired with ",{"href":"/glossary/rto","text":"RTO"},", which is about time to recover, not data lost."]],"why":["Backups that are too far apart mean lost orders, payments or records after a failure. Backups that are more frequent than needed cost money. Setting an RPO per system makes that trade-off a decision instead of an accident."],"example":["A payments platform sets an RPO of five minutes for its transaction database and 24 hours for its analytics store. The transaction database uses point-in-time recovery; the analytics store is rebuilt from nightly backups."],"inBuild":["RPO is decided when the database and hosting are chosen. Writing it down during the build also tells the team which backups to test before launch."],"mistakes":[["Never testing a restore, so the RPO is a hope rather than a fact."],["One RPO for every system, when some data matters far more than other data."],["Forgetting files, queues and third-party data that are not in the main database."]],"related":[{"href":"/glossary/rto","label":"RTO (recovery time objective)","detail":"How long a system can stay down after a failure before the outage seriously harms the business."},{"href":"/glossary/uptime","label":"Uptime","detail":"The share of time a service is working and reachable, usually written as a percentage such as 99.9%."},{"href":"/glossary/sla","label":"SLA (service level agreement)","detail":"A contract that promises a level of service, such as uptime or support response time, and says what happens if it is missed."},{"href":"/glossary/slo","label":"SLO (service level objective)","detail":"An internal reliability target for a service, such as 99.9% of requests succeeding, measured by a service level indicator (SLI)."}],"tools":[],"links":[{"href":"/software","label":"Software by industry","detail":"Systems we build per industry, with guides and tools."},{"href":"/compliance/soc-2","label":"SOC 2 guide","detail":"The controls behind a SOC 2 report."}],"sources":[{"title":"NIST CSRC glossary: recovery point objective","url":"https://csrc.nist.gov/glossary/term/recovery_point_objective","checkedAt":"2026-10-25"}],"legal":false,"updatedAt":"2026-10-25"}