How do I set RPO and RTO for a server?
Recovery point objective, or RPO, describes how much recent data loss is tolerable. Recovery time objective, or RTO, describes the target time for restoring the required service. Define them for the business operation, then check whether the technical recovery design can achieve them.
Before you start
- The application owner’s assessment of acceptable interruption and lost work.
Instructions
1. Define the required outcome
Identify critical operations and the data they create. An order-processing system may need a different recovery point from a static content site. State what counts as restored service: a server booting, a read-only service or fully reconciled customer transactions are different outcomes.
2. Map the target to the process
For RPO, consider the last usable recovery point and any transaction logs or replication needed after it. For RTO, include incident detection, authorisation, infrastructure preparation, transfer, restoration, application checks and traffic changes. A fast file copy is only one portion of the elapsed recovery time.
3. Measure a rehearsal
Use an isolated restore test to record data currency and time to the defined service outcome. If the result misses the target, identify whether the limit is storage, access, dependencies or the procedure. Agree the improvement or revise the accepted requirement with the business owner.
Check the result
- RPO and RTO are documented per critical service with a clear start and completion definition.
- A recent rehearsal provides evidence for the achievable values.
Troubleshooting
- The backup interval appears to meet RPO but recovery loses more data
- Check failed runs, upload completion, log gaps and unusable points. Scheduled frequency does not establish the age of the latest restorable data.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.