Uptime
RPO
Also called recovery point objective.
RPO is the maximum age of data you can lose in a failure, expressed in time. An RPO of 15 minutes means you accept losing up to the last 15 minutes of writes.
How it is measured
Measure the real gap: time between the last successful backup or replicated transaction and the failure. Track backup frequency and replica lag. The larger of the two in the worst case is your actual RPO.
Set it by asking what is cheap to re-enter and what is not. Blog comments tolerate hours. Payments tolerate seconds.
Worked example
A booking site for yoga studios takes 60 reservations an hour. It dumps its database nightly at 03:00, so its actual RPO is up to 24 hours. After a disk failure at 14:30, the restore returns data as of 03:00, losing 11.5 hours, about 690 bookings.
The owner sets an RPO of 5 minutes for the bookings table by enabling point-in-time recovery, and leaves the CMS pages at 24 hours.
How it differs
RPO is how much data you can lose. RTO is how long you can be down. RPO excludes restore speed. RTO excludes how stale the restored data is.
Common errors
Equating RPO with backup interval and ignoring restore verification. Setting zero without synchronous replication. Using one RPO for all data. Counting replica lag as safe even though deletes replicate. Not telling the business.
In practice
List your three most valuable tables or collections and pick an RPO for each. Compare it to the real backup and replication cadence. If they differ, change the cadence, not the goal.