Home  ›  Glossary  ›  Recovery Time Objective (RTO)

What is a recovery time objective (RTO)?

A recovery time objective (RTO) is the maximum time a service can stay unavailable after a disruption before the impact on the business becomes unacceptable. It is set per service from a business impact analysis and covers the whole recovery, from the disruption until people can work again, not only the data restore.

What does the RTO clock include?

The clock starts at the disruption, and copying data back is only one part of the time it covers. A recovery usually runs through five stages:

  1. Detecting the problem and deciding to recover, which can take longer than any technical step.
  2. Preparing somewhere to restore to: servers, network, storage and working credentials.
  3. Moving the data back from backup storage, at the rate that restore throughput allows.
  4. Starting the application and checking that its data is consistent.
  5. Handing the service back to users.

An RTO of four hours that assumes a two-hour data restore leaves two hours for everything else.

How is an RTO set?

The figure comes from the business, not from the infrastructure. A business impact analysis estimates what each hour of outage costs a service in revenue, contracts, regulatory exposure and safety, and the RTO sits where that cost stops being acceptable. Services are then grouped into tiers: a payment system may carry an RTO of minutes, an internal reporting tool several days.

The tier decides the protection method and the spend. Restoring within a day is possible from ordinary backup storage. Restoring within an hour usually depends on fast backup storage or instant recovery, and restoring within minutes on standby systems kept in step through replication.

Why does the achieved recovery time drift from the objective?

The RTO is a target. The time a recovery actually takes, sometimes called recovery time actual, is only known from a restore test or a real incident. The two move apart as data grows, as more workloads share the same restore path and as applications gain dependencies on other systems. A target agreed when a database held 2 TB says little about restoring it at 20 TB over the same network.

How does ransomware change recovery time?

A ransomware attack adds steps that a hardware failure never needs. Investigators have to establish when the intrusion began, a restore point that predates it has to be found and scanned, and systems are often rebuilt in a clean room before they reconnect to the network. If the attacker reached the backups, missing restore points turn the recovery into a rebuild. A cyber recovery scenario therefore tends to be planned against its own, longer objective than an ordinary outage, and the ransomware recovery plan states which services return first.

Frequently asked questions

What is the difference between RTO and RPO?

The RTO limits how long a service is down. The recovery point objective limits how much recent data, measured in time, can be lost. A service can have a short RTO and a long RPO, or the reverse.

Is an RTO the same as an SLA?

No. An RTO is an internal recovery target. A service level agreement is a commitment to a customer that may draw on the RTO but also covers availability, support and penalties.

Does a shorter RTO always cost more?

Generally, yes. Moving from days to hours mostly means faster backup storage and tested procedures. Moving from hours to minutes means standby infrastructure, which duplicates much of what it protects.