RTO (recovery time objective) is the longest outage you accept before a service is back. RPO (recovery point objective) is the most data, measured in time, you accept losing. A nightly backup gives a worst case RPO of about 24 hours, however fast you restore.
Definitions in plain words
RTO answers "how long can this be down?" It starts when service stops and ends when users can work again. It includes finding the problem, deciding to restore, restoring, and checking the result.
RPO answers "how far back can we go?" If the last good copy is from 02:00 and the failure hits at 13:00, you lose eleven hours of writes. If that is unacceptable, your RPO target is shorter than your backup interval.
Both are targets you choose per system. They are not properties a tool gives you.
How backup choices set your numbers
AWS's disaster recovery guidance puts the link directly: how often you run a backup determines your achievable recovery point, and that should align with your RPO. It also says recovery time and recovery point are always greater than zero for a data disaster such as corruption or deletion, because you restore to a point before the damage was found.
| Decision | Mostly moves | Example |
|---|---|---|
| Backup frequency | RPO | Hourly snapshots vs nightly dumps |
| Continuous log archiving | RPO | Point in time recovery to a chosen minute |
| Restore automation | RTO | Scripted rebuild vs manual runbook |
| Standby environment | RTO | Warm copy vs rebuild from scratch |
| Restore testing | Both | Replaces guesses with measured times |
Steps to set targets
- List the systems that matter: production database, source repositories, CI, artifact storage, secrets store, identity provider.
- For each, ask the owner two questions: how long can this be down, and how much recent data can be lost? Write the answers down.
- Compare to what you do today. If the owner says one hour of data loss and you back up nightly, you have a gap.
- Close gaps by changing frequency or adding log shipping, not by writing a smaller number in a document.
- Measure RTO with a real restore into a clean environment. Time every step, including waiting for access.
- Review the targets when the system changes size or a new customer commitment appears.
Common mistakes
- Using one number for everything. A marketing site and a payments database do not need the same RTO.
- Counting only restore time. Detection and decision time often take longer.
- Forgetting dependencies. A restored database is not useful if the identity provider or the build system that deploys the app is also down.
- Treating replication as a backup. AWS notes continuous replication may not protect against corruption or malicious deletion as well as point in time backups do.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a check that runs on a schedule only sees problems as often as it runs. Backups behave the same way: the interval is your exposure window.
Safeguard can run asset discovery and continuous dependency scanning so the list of systems you need to protect stays current. You can try a free scan on a repository.
Quick check
Can RPO be zero?
Only with synchronous copies of every write, and even then it does not cover corruption that is copied along with good data. Treat zero as a design goal for specific stores, with point in time backups behind it.
Which is harder to meet, RTO or RPO?
Usually RTO, because it depends on people, access and untested steps. RPO is mostly a scheduling decision. Measure RTO with a drill.
Sources
Last reviewed: 19 October 2026.
