Back to Glossary Home | Recovery Time Objective
Recovery Time Objective (RTO)
What Is Recovery Time Objective (RTO)?
Disaster Recovery (DR) is the IT capability to restore enterprise applications, services, networks, and infrastructure to normal operations following a service disruption such as a power outage, network disruption, DDoS attack, application crash, cybersecurity incident, or a natural disaster.
In disaster recovery planning, a Recovery Time Objective (RTO) indicates the targeted length of time within which a specific application, network, or service should be restored to normal operations to avoid unacceptable consequences following an unplanned service interruption.
The purpose of defining RTOs in disaster recovery planning is to implement DR processes that help avoid unacceptable consequences of unplanned operational downtime, including things like revenue loss, SLA violations, and degrading customer experience. Enterprises account for a variety of factors when determining RTOs for applications and services, including the criticality of the service, potential for lost revenue or poor customer experiences, compliance needs, SLA requirements, and budget constraints.
Recovery Time Objective vs. Recovery Point Objective - What’s the Difference?
RTO and Recovery Point Objective (RPO) are both metrics that define key goals and business requirements for recovering critical IT systems, applications, or services following a service disruption.
As mentioned above, RTO represents the target timeframe within which an application or service must be restored following a disruption to avoid significant negative consequences. For example: if a customer-facing application has an RTO of 2 hours, it means that the organization can tolerate up to 2 hours of downtime in case of a service disruption.
To meet this objective, the organization must implement DR processes like failover and failback that can reliably restore the system to normal operations within 2 hours of a disruptive event.
In contrast, Recovery Point Objective represents the maximum tolerable amount of data loss that an organization is willing to accept in the event of a service disruption. RPO targets help determine how frequently data backups should occur. If a system has an RPO of 1 hour, it means that the organization can accept up to 1 hour of data loss in the event of a service disruption.
To meet this objective, the organization must perform data backups or replication processes at least once every hour.
How Do Recovery Time Objectives Work?
Determining an RTO isn’t a solitary project. Instead, it’s decided alongside a recovery point objective (RPO) and requires a solid understanding of the systems and workloads that are necessary for business operations. A business can’t achieve an RTO without the appropriate tools and controls in place.
RTOs are Set Through Business Impact Analysis
For enterprise IT organizations, the process of establishing RTOs begins with a business impact analysis (BIA). Conducting a BIA involves creating an inventory of systems and applications used by the organization, then predicting the potential consequences to the business if each of those systems or applications experienced a service disruption.
As part of a BIA, enterprise IT organizations must ask the following questions about the applications and services they operate:
- How much revenue would be lost if this system experienced unplanned downtime?
- What other applications or services could be disrupted if this system failed? What are the RTOs for those services?
- Which services are connected to customer SLAs? What are the requirements for service availability?
- Which services are customer-facing? For which applications or services could unplanned operational downtime negatively impact the customer experience or result in customer loss?
RTOs are Based on the Perception of Unacceptable Consequences
RTOs are subjectively determined based on how long a service can remain inaccessible before enterprise stakeholders perceive unacceptable consequences.
For customer-facing applications, consequences for downtime can often include lost revenue and potentially lost customers. When the predicted cost of downtime is high, enterprises are more likely to set a shorter RTO and attempt to minimize downtime as much as possible.
For internal applications or services, consequences for unplanned downtime might be limited to inconveniencing staff and limiting productivity. When the predicted cost of downtime is low, the enterprise can implement a less costly DR protocol that restores the service over a longer period of time.
So, an internal email server might have an RTO of 6 or 8 hours, while a mission-critical, customer-facing application with binding SLAs could have an RTO of less than 1 minute.
RTOs Inform Disaster Recovery Planning
After conducting a BIA and establishing RTOs, enterprise DR teams can implement a disaster recovery plan with the appropriate people, processes, and technologies to meet RTOs across all applications and services.
In general, longer RTOs are associated with less frequent data back-ups, less stringent technological requirements, and lower costs. Achieving shorter RTOs comes at a greater cost and often requires real-time or near real-time data replication and automated failover systems with high-availability infrastructure.
Disaster Recovery Testing Helps Validate RTO Achievability
DR involves securely replicating data, maintaining back-up infrastructure, and shifting application and workloads from the normal production environment to a redundant back-up environment to restore service in case of an outage.
Enterprises use both manual and automated failover processes to meet RTOs for disaster recovery. Disaster Recovery Testing involves simulating service interruptions to validate the function of DR protocols, assess recovery times, and ensure that established RTOs are achievable in the event of a genuine service disruption.
Communicating RTOs to IT Stakeholders
Documenting RTOs and communicating them to IT stakeholders (e.g. employees, customers, investors, DRaaS vendors, etc.) is a critical aspect of both coordinating recovery efforts across the DR team and managing expectations during a service disruption.
Updating RTOs to Align with Business Requirements
RTOs are never set in stone and should be reviewed and updated periodically to ensure their alignment with business requirements.
Why is Recovery Time Objective Important?
It's important for an organization to form a recovery time objective because failing to do so can have substantial consequences for revenue, business resiliency, and trust, both internally and externally. Planning is essential. The goal is to avoid finding your RTO limits during a disaster or outage without a backup plan in place.
Taking the time to identify which systems and workloads are most critical to the business, allows you to meet recovery time objectives
Avoiding Unacceptable Consequences of Service Interruption
By clarifying the maximum tolerable downtime and implementing DR protocols to recover systems in an acceptable time frame, enterprises can avoid unacceptable consequences from service disruptions, including:
- Lost revenue,
- Customer loss, churn, or poor customer experience/satisfaction,
- Lost productivity and efficiency,
- Degraded customer trust and brand perception,
- SLA violations, and
- Regulatory/compliance breaches
Disaster Recovery Planning and Strategy
Establishing RTOs is a critical aspect of disaster recovery planning for enterprise IT organizations. DR teams strategically design cost-effective failover, failback, data back-up, and data replication protocols to effectively recover services within the allotted time frame based on the established RTO.
Enterprise IT organizations may collaborate with a Backup as a Service (BaaS) or Disaster Recovery as a Service (DRaaS) provider to cost-effectively implement and manage disaster recovery processes.
Managing Expectations for Disaster Recovery
Clearly establishing and communicating about RTOs allows enterprise organizations to effectively manage expectations for recovering and restoring services in the event of a disruption.
Two Recovery Time Objective Examples in Disaster Recovery
Example One: Financial Trading Platform
In a financial trading platform with a high number of transactions occurring in real time, a short RTO is essential to avoid disruption to trading, prevent financial losses, and maintain the platform’s trusted reputation. RTO might be set to as little as 10 seconds or less. Achieving this low RTO requires high-availability architecture, real-time data replication, and automated failover systems.
Example Two: Employee Intranet
An RTO of 8 hours or more might be acceptable for an employee Intranet whose immediate availability is not considered critical to revenue-generating business operations. An RTO of 8 hours may be achieved with a regularly schedule of snapshot-based data replication along with relatively simple and inexpensive manual recovery processes
What is a Reasonable Recovery Time Objective?
A reasonable RTO depends on the nature of the business and what is mission-critical to keep operations going, as well as the potential impact downtime has on the business. For some, this may be minutes, other businesses may be able to go a few days or longer being able to operate fairly normally. Your RTO will be set based on a variety of factors and should be tailored to your business.
TierPoint Helps Enterprises Define and Meet Disaster Recovery RTOs
TierPoint offers managed Disaster Recovery as a Service, providing the technology, processes, and professional expertise that enterprises need to meet their RTOs, efficiently recover applications and services after an outage, and avoid unacceptable consequences of unplanned operational downtime.
Ready to Learn More?
Book an intro call with TierPoint and see how we can help you build a DRaaS solution that minimizes data loss and downtime for your critical services.
