Understanding recovery time objective in disaster recovery planning

Setting your recovery time objective (RTO) is crucial, especially when network hacks and ransomware attacks are on the rise. You never know when you are the next victim. At this juncture, if your RTO is not defined, how would you come up with a data backup and recovery plan?

This post will define recovery time objective and examine the factors to consider when setting your RTO.

What is recovery time objective?

Recovery time objective is a metric used in disaster recovery and business continuity planning. It’s the maximum duration an application, network, system, or computer can be down after a disaster or failure occurs before an organization suffers significant damage. Factors like loss of revenue and a disruption to business continuity can impact RTO. RTOs vary greatly depending on the systems and processes involved.

RTO time suggests the time taken to recover and finish system restoration of a failed system as defined within the service level agreement. The service level objective accounts for the recovery time set by the organization to recover or restore its mission-critical IT processes or operations to normal from when a disaster occurs to ensure business continuity.

Pro Tip: You should always aim to attain the lowest possible RTO to minimize the impact of a disaster. To determine your RTO, you must first identify the effect of the length of duration on your business in which the data is unavailable.

For example:

• If 10% of data must be available within 24 hours,
• And after a complete loss of the database, 50% of data must be available within 2 days,
• The remaining 40% of data must be available within the next 5 days, then,

Your total RTO is = 8 days.

To cite another example:

Suppose the exchange server is down. If your RTO is at five hours, then your organization can tolerate downtime of five hours, and your exchange server’s RTO should be less than five hours. Your disaster recovery policy must include the necessary steps taken by the IT department to back up and restore the data.

Recovery time objectives can be set to recover data, there’s no one-size-fit solution for a business continuity plan. RTOs can be set to recover data after a disaster strikes. However, should an incident occur, the real-life practicalities of your disaster recovery plan also depend on specific tools and technology employed to provide recovery. So, the ability to hit RTO varies as different technologies and DR tools vary in their capabilities. RTO is measured even before the outage has begun and includes the time taken to repair the servers, install priority applications, and restore data. It also includes the methods of recovery and the backed-up data that needs to be recovered.

What does RTO determine?

RTO is a targeted duration time wherein applications, systems, and/or processes survive downtime and are non-functioning before the disruption begins. The RTO is of paramount importance to determine the length of time to prioritize applications and processes within the RTO parameters. In the data protection plan and disaster recovery strategy, RTO answers the question, “What is the target time established for service restoration after a service disruption notification?”

RTOs can determine:

• The time it takes to recover a site in real time — from the moment an incident occurs until operations are restored
• What IT preparations should be designed for carrying out the disaster recovery plan
• The level of data loss that is acceptable when the system or key applications go down

How to calculate RTO for disaster recovery planning?

An RTO metric sets the target expectation for the IT team in advance as it determines the threshold as to how quickly the system or application can be recovered after the downtime and bring your system back online. After defining this measure in terms of the amount of “real-time” to restore the system, you can then plan your recovery strategy to get the service operational again. To calculate RTO, you must consider the losses associated with a break in the (BCP) Business Continuity RTO. Also include an impact analysis that explains the short-term or long-term effects of business interruption of services. This includes risks, lost revenue, expenses, customer-facing applications, mission-critical applications, and less-priority applications that are affected or will become unavailable. RTO is more concerned with the downtime and time limitations for the data recovery process.

To work out an RTO, you might need multiple RTO categories because certain outages might not need much recovery time, while some might require different long-term protection solutions. For example, the RTO might be much longer for less mission-critical applications (not used frequently). Based on the levels of complexities of multiple security systems in operation, you might have to set the RTO according to short and long-interval backups. This might happen due to a ransomware event or other massive catastrophe incident.

Prime factors to consider when calculating RTO

• Cost/benefit equation for recovery solutions
• Priority applications of individual systems and data
• Steps to be taken by the IT department based on the processes, automated techniques, or technologies to restore the IT infrastructure
• Outage and mitigation cost
• The complexity of the recovery procedure 

RTO sample intervals

Achieving a near-zero RTO is costly for most IT enterprises, but it’s possible to achieve if you are prioritizing applications and data. For less business-critical applications, the RTO clock might consume longer objective times than usual. Near-zero RTO plans for mission-critical applications might require you to consider immediate failover capability. 

Depending on the severity of the outage, you can set the achievable target RTO time. However, the RTO restoration time also depends on the limitations of the IT organization. For example, if restoring all the IT functions and operations takes 3 hours, the RTO must be at least 3 hours.

Note: From the disaster recovery (DR) perspective, the RTO clock starts right when the recovery processes start.

As you calculate RTO for your business units, consider these sample intervals:

One hour

This interval is for redundant data backup on external hard drives.

Five Days

In this case, the most cost-effective solution would be backing up data using a compact disk, tape, or offsite disk storage.

Achieve RTO, the Zmanda way

RTO and Recovery Point Objective (RPO) are incredibly important goals and are the foundation of a recovery plan. How do you determine the series of steps of practical recovery objectives? This is where we can help!

With Zmanda’s DRaaS plan and custom service level agreements, irrespective of the size of your business, we can help you shorten outage times and avoid the pain of downtime depending on your business needs. Apart from hybrid backups to support the transition and achieve relatively faster RTOs, our enterprise solution combines Amazon Glacier with a 20X lower cost of long-term data archival that deploys a robust high availability and ensures business continuity. 

We tailor our enterprise backup solution to meet your requirements, offering a product that integrates backup processes, data continuity, and long-term storage archiving. Get the reliability and security you need when the unexpected happens — even in the event of a total server failure.

Want to try Zmanda Pro for yourself?

See how Zmanda Pro can help you shorten outages and avoid downtime. Sign up for a Zmanda Pro free trial and strategize your recovery time objectives. During the 14-day trial, you’ll have full-feature access, and we’ll keep you updated about your trial status. If you have any questions about our solutions, reach out to our experts.