Glossary · Recovery Time Objective
RTO
The maximum acceptable downtime for a given workload after an incident, measured from the moment of failure to the moment service is restored.
RTO (Recovery Time Objective) is the answer to “how long can we be down?” — measured forward from the incident to the moment the workload is usable again. Together with RPO, it defines what recovery looks like for each system.
How RTO is set
Like RPO, RTO is a business decision. It depends on what the workload supports and what the organisation can do without it.
Typical ranges:
- Public-facing website, e-commerce, customer portals — RTO often under four hours. Revenue and reputation impact compounds quickly.
- Email, collaboration platforms — RTO of a few hours; staff can absorb a short outage with workarounds.
- Line-of-business applications, ERP, CRM — varies widely. Often four to twenty-four hours.
- Payroll, finance batch systems — often 24 to 48 hours, sensitive to pay-cycle timing.
The catch: a documented RTO is not a tested RTO
The most common failure pattern is a written RTO that’s never been validated against a real restore. Documents are reassuring; rehearsed recovery is the only evidence that the number holds.
How Symsafe handles RTO
RTOs are documented per workload during backup and DR engagements, and validated through rehearsed recovery drills. Symsafe doesn’t publish blanket RTO promises across all client workloads — recovery objectives are scoped per engagement against the actual systems involved, then tested.