What is a recovery time objective (RTO)?
The recovery time objective is the maximum time a system may stay unavailable after an incident before the disruption becomes unacceptable. It sets how quickly a service has to be restored and running again.
Written by Paul Madelénat. Last updated
What the recovery time objective measures
The recovery time objective is a deadline. The clock starts when a system stops serving its users and stops when they can work with it again. An RTO of four hours means the organisation has decided that four hours without the system is tolerable and five is not.
RTO covers the whole recovery, not only the restore itself. Noticing the failure, deciding what to do, getting a machine ready, restoring the data and checking that the app answers all count. That is why detection and a clear runbook matter as much as fast storage.
It is often confused with two neighbouring ideas. The recovery point objective measures how much data may be lost, not how long the outage lasts. An availability commitment, such as a monthly percentage, measures uptime over a period. A single long outage can respect the monthly figure and still break the RTO, so the two are set separately.
How to set an RTO
Ask what happens to the people who depend on the system, hour by hour, when it is gone. Email and file sharing usually need a short RTO. An internal reporting tool can often wait until the next day. The shorter the RTO, the more it costs: standby machines, replicated data and people ready to act at any hour.
Then test it. Time a real restore of each app into a clean environment and compare the result with the objective. If the restore takes longer than the RTO, either the objective or the setup has to change.
RTO at Pilae
Pilae probes every app every 60 seconds, and alerts reach engineers around the clock. Work starts within the response target of your plan, and around the clock for Severity 1 and 2 incidents on Enterprise. Each restore follows a recorded procedure: an engineer confirms the backup and the expected downtime, restores the app, checks it answers and writes the duration and result to the audit log.
Your contract states the RTO for each app, per plan, alongside a 99.9% monthly availability commitment with service credits. Monthly restore tests, recorded in the console, show whether the objective holds. See backups and recovery and monitoring, or agree your objectives with an engineer.