After reading, you can set an RTO from the business impact, price the means to reach it, and check it with a timed test.
Definition
ISO 22301 defines it as the period following an incident within which an activity must be resumed or a resource recovered. It is set within the time after which the impact of not resuming becomes unacceptable, often called the maximum tolerable period of disruption.
The business sets the RTO as a target. What IT achieves in a test is the recovery time actual, and the two often differ.
Why it matters
The RTO sizes the investment. A target of 15 minutes means failover standing ready, whereas 3 days may need nothing more than good backups, and the bills are not remotely comparable.
How it works
Derive the RTO from the business impact analysis, activity by activity. Translate it into targets for the supporting systems, and include their dependencies.
Choose recovery means to match, and weigh their cost against the impact they avoid.
Test, and write down the time achieved. If it misses the target, either change the means or have management accept the gap.
A worked case
An online shop loses €2,000 an hour when its site is down, so it sets an RTO of 2 hours. A test takes 5 hours, 4 of them on the database restore.
A warm replica brings that down to 1 hour 30 minutes for €1,200 a month. Management approves: the 3 hours 30 minutes saved in one outage are worth €7,000, nearly six months of that cost.
Good practices
- Have the business owner set the RTO, with IT advising on cost.
- Measure from the moment of disruption, and count the time it takes to decide.
- Align the RTOs of a system's dependencies.
- Keep each test result next to its target.
Common mistakes
- Giving every system the same RTO, which overspends on some and leaves others short.
- Setting a target no test has ever reached, so that the figure only exists on paper.
- Forgetting the time needed to detect and declare the event, often an hour or more.
- Ignoring a dependency with a longer RTO, which then sets the real recovery time.
Questions
- What is the difference between RTO and RPO?
- RTO is how fast you must be back. RPO is how much recent data you can afford to lose. One counts forward from the incident, the other backward.
- What is a good RTO?
- One justified by the impact and funded. There is no universal figure.
- What is the difference between RTO and MTPD?
- The maximum tolerable period of disruption is the point at which the impact becomes unacceptable. The RTO is set shorter, to leave a margin.
- Is an RTO the same as an SLA?
- No. An SLA is a commitment to a customer, often on availability. The RTO is an internal recovery target, which should support the SLA.
- How can an RTO be verified?
- With a timed recovery exercise under realistic conditions. Adding up estimates proves nothing.