Recovery point objective
RPO / RPO and RTO / acceptable data loss
A recovery point objective, or RPO, is the most data a business will accept losing after an outage, measured as time since the last point it can recover to. It sets how often backups must run, and how many hours of orders, bookings or form entries a failure could erase.
NIST defines the recovery point objective as the point in time to which data must be recovered after an outage. AWS states it as the maximum acceptable time after the last data recovery point. Microsoft notes that it is measured in units of time, such as 30 minutes of data.
Its partner is the recovery time objective, or RTO. AWS defines that as the maximum acceptable delay between the interruption of service and restoration of service. The RPO covers how much recent work can be lost. The RTO covers how long the business can wait to be running again.
The RPO turns directly into a backup schedule. Microsoft advises making sure the RPO is aligned with the backup interval. It also warns that backups are typically taken infrequently, so restoring from one usually involves data loss. Backups kept for disaster recovery should be stored separately from the main data.
Microsoft publishes these figures for its Azure SQL Database service. It lists an RPO of 0 when zone redundancy handles a failure. When a database is recovered with geo-restore, the RPO is typically minutes or hours. That service takes transaction log backups every 5 to 10 minutes and keeps backups for seven days by default.
A tighter target carries a cost. AWS lists zero data loss as an unrealistic objective that may be out of reach for a given setup. It also warns that targets stricter than the business needs force costlier and more complicated recovery.
In practice
A contractor runs a booking app whose database is backed up once a night at 2 in the morning. The database fails at 5 in the afternoon, so the newest backup is 15 hours old. Every booking and change made in those 15 hours is gone. If the business can accept losing 1 hour at most, backups or replication must run at least hourly. The figures are a worked example.
Why it matters to you
Leads, orders and appointment changes entered since the last backup may be impossible to rebuild. AWS suggests asking whether lost data can be recreated from other sources. The right target can also change with the calendar, and AWS names holiday shopping seasons and special sales as examples. A backup that has never been restored is untested. AWS advises validating the RPO by performing a recovery test. It lists assuming a backup exists as a common mistake, along with restoring one without checking that the data is usable.
What to ask or check
- 01How often is your website or app database backed up, and how many hours of data could be lost between backups?
- 02Where are your backups stored, and are they kept separate from the main site and database?
- 03When did the business last restore a backup and check the data, and how long did the restore take?
- 04Does your hosting or database provider publish an RPO for your plan, and how long are backups kept?
What people get wrong
That having backups means the target is met. AWS lists assuming a backup exists, and restoring one without checking the data is usable, as common mistakes. A test restore is how the RPO gets confirmed.
Red flags
- A hosting or software quote that mentions backups but gives no backup frequency, retention period or record of a tested restore.