Reference · Hosting and Recovery
RTO vs RPO: Recovery Time and Recoverable Data
Distinguish recovery time from recoverable data using a clear outage timeline, service boundaries and evidence from a measured restoration exercise.
Published Updated
Published by FxTrusts, a supplier of brokerage and prop firm technology. Prepared with AI-assisted research and drafting; reviewed against the cited public sources. Examples are illustrative. Product links describe our services.
What is RTO and RPO?
Recovery time objective, or RTO, is the targeted time to restore a defined service after disruption. Recovery point objective, or RPO, describes the acceptable age of recoverable data relative to the disruption. One concerns service duration; the other concerns data exposure. Neither target proves what a particular incident or drill will achieve.
Define the service and the clock
Write the recovery boundary in business terms. Restoring database access is different from reopening account creation, order entry or withdrawals. State which features may remain unavailable, who can approve restricted operation and which external dependencies must be healthy before the service is considered restored.
Set the timing convention before the exercise. Record disruption, detection, declaration, infrastructure readiness, reconciliation and reopening as separate events. Otherwise one team may report recovery from declaration while another measures the whole period of customer impact. AWS guidance treats recovery objectives as workload-specific choices informed by business requirements.
Sources for this section
- Disaster Recovery objectivesdocs.aws.amazon.com
Measure recoverable data separately
For each data store, record the latest usable recovery point and compare it with the disruption time. An hourly backup schedule does not guarantee an hourly RPO: a missed job or unusable backup can widen the gap. Continuous archiving can reduce the interval, but a working restore still depends on a valid base backup and the necessary log sequence.
External events complicate the picture. A payment provider may have accepted a payment after the internal recovery point; an execution venue may have filled an order during the outage. That activity needs reconciliation before reopening. Recovering a database to a timestamp is not evidence that every business obligation now agrees.
Sources for this section
- PostgreSQL continuous archiving and point-in-time recoverywww.postgresql.org
Separate targets, results and commitments
Maintain three fields: approved objective, observed exercise or incident result, and any supplier commitment with its contractual scope. A successful drill supports confidence in that tested scenario; it does not guarantee every regional failure, data corruption event or dependency outage.
Record the recovery method, data size, staffing assumptions and unavailable dependencies alongside the result. When a target is missed, identify the limiting step and repeat the affected exercise after remediation. Do not improve the reported result by moving the start time or excluding reconciliation that the reopening policy requires.
Worked example: two independent measurements
In a fictional exercise, service disruption begins at 10:00. The latest usable restored data is from 09:57. Infrastructure is ready at 10:28, but reconciled service reopens at 10:42. Against an agreed 30-minute RTO and five-minute RPO, the 42-minute restoration misses the time target while the three-minute recovery-point gap meets the data target. These are exercise results, not a hosting offer.
| Measure | Recorded result |
|---|---|
| Disruption to service reopening | 42 minutes |
| Disruption minus latest recovery point | 3 minutes |
| Infrastructure ready but not reopened | 10:28 |
| Remaining decision | Reduce reconciliation delay and retest |
Implementation checklist
- Name the exact service and agreed restoration condition.
- Record the latest usable recovery point for every critical store.
- Reconcile external transactions after the restored point.
- Compare observed results with approved objectives and contractual scope.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- Disaster Recovery objectivesdocs.aws.amazon.com
- PostgreSQL continuous archiving and point-in-time recoverywww.postgresql.org
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.