What is Recovery Time Objective (RTO)

The recovery time objective (RTO) is the maximum tolerable time that a computer, system, network, or application will be out of service after a failure or disaster. The recovery time objective is a function that assesses the extent to which a disaster will disrupt normal operations and the loss of revenue caused by the disaster per unit of time. These factors depend on the equipment and applications affected. The recovery time objective (RTO) is measured in seconds, minutes, hours, or days and is an important consideration in disaster recovery planning (DRP).

Numerous studies have been conducted to determine the cost of downtime for various applications in the course of business operations. These studies have shown that the costs depend on long-term and intangible effects as well as immediate, short-term or tangible factors. Once an application has a defined recovery time objective (RTO), administrators can decide which disaster recovery technologies are most suitable. For example, if the recovery time objective for a particular application is one hour, redundant data backups on an external hard drive may be the best solution. If the recovery time objective is five days, then tapes, recordable compact discs (CD-Rs), or offsite storage on a remote Web server may be more practical.

What to Consider in Data Recovery Time Objective (RTO)

When discussing data recovery with senior IT executives, one thing that comes up over and over again is that people have a hard time accurately describing their organization's ability to recover critical applications and transactions in the event of a major outage. They believe that critical data can be recovered, and they are looking for patterns to prove that recoverability.

The fact is that IT infrastructure has become complex enough. It is challenging to remove this complexity through abstraction layers and aggregate the various components to comprehensively determine the recoverability of an application. Instead, we tend to try to determine the health of individual components, hoping that the overall recoverability is equal to the sum of the recoverability of the parts.

However, this is not necessarily the case. First, recoverability of a complex application involves many moving parts, and taking all of them into account is difficult to do. More importantly, synchronization between these components becomes a significant barrier to successful recovery.

This coordination problem is usually well understood at the system level, but it is often overlooked when dealing with cross-platform business functions involving multiple application components. In fact, copying or backing up the underlying databases at different times can add different recovery days and recovery windows, which can reconcile the conflicts between them.

Compounding this problem is that in some cases, interdependent systems may be prioritized differently, resulting in completely different protection mechanisms being employed. For example, the database may be considered high priority and therefore fully replicated to support a 4-hour recovery objective (RTO), but the associated front-end web-based application components may be assigned a tape-based recovery level. This may be perfectly acceptable for operational recovery in a disaster recovery situation (such as restoring a single volume or server), but it may result in users being unable to connect to a running database. (The 4-hour RTO only goes so far.)

Although some emerging technologies can help us to some extent, today's explanation of this problem still mostly stays in the policy and process. One of the key challenges is organizational. The identification of interdependencies requires cross-functional collaboration. And driving this collaboration requires someone with a certain authority to take overall responsibility for the recovery of the business function layer. Such a person usually does not exist to focus all efforts on component recovery.