Backups
Backup RPO and RTO: turn recovery objectives into a backup design
RPO and RTO describe different recovery promises. Recovery Point Objective is how much data loss the business can tolerate; Recovery Time Objective is how long service recovery can take. Neither should be copied from a vendor brochure without matching application change rate and rebuild complexity.
Translate RPO into backup frequency
If losing four hours of orders is unacceptable, a nightly database dump cannot meet that objective. Identify which data changes, how often, and whether replication/log shipping, frequent dumps, or another application-aware method is needed.
Static assets may have a very different RPO from transactional data on the same service.
Translate RTO into recovery preparation
Recovery time includes detecting the incident, accessing backups, provisioning replacement infrastructure, restoring data, configuring DNS/TLS/secrets, verifying the application, and communicating. A fast backup download does not guarantee a short RTO.
Keep automation and runbooks for the slowest steps.
Account for dependency failures
A service may depend on DNS, domain registration, mail, databases, APIs, credentials, and third-party platforms. Decide which dependencies are inside the recovery objective and which external outages can exceed it.
Avoid claiming an RTO you cannot test across the real stack.
Measure during drills
Record actual recovered timestamp and elapsed time. Revisit objectives when application size, traffic, staffing, or architecture changes.
- RPO = tolerated data loss.
- RTO = tolerated recovery time.
- Include full dependency/rebuild path.
- Measure objectives through drills.