What is a recovery time objective?

Recovery time objective explained

A recovery time objective (RTO) represents the amount of time an application can be down and not result in significant damage to a business and the time that it takes for the system to go from loss to recovery. This recovery process includes the steps that IT must take to return the application and its data to its pre-disaster state. For high-priority applications, an RTO can be safely expressed in seconds, as long as the IT department has invested in failover services.   RTOs require your IT department to first sort applications based on their priority and risk of business loss. IT then allots these applications the appropriate amount of your enterprise’s resources, namely time, money and IT infrastructure.

Determining a RTO

RTOs are used to measure how much time it takes after the disaster for the IT department to recover the data. For their assessment basis, RTOs represent the overall needs of your business and determine how long your business can survive withoutIT infrastructure and services. RTOs first need to be aligned with what’s possible by your IT department. IT administrators need a strong comprehension of the different type of restore speeds to calculate an RTO that meets the needs of the business. For example, an RTO of one hour can’t be met if the minimum possible restore time is two hours.   

Because the process involves restoring all IT operations, RTOs are often complicated. Your IT department can streamline some of the recovery process by automating as much as possible.  The RTO may have greater costs than that of a granular RPO, and a demanding RTO involves your entire business infrastructure and not just data. The cost of attaining an RTO or RPO is matched with your IT department’s prioritization of applications and data. IT prioritizes applications and data based on their revenue and risk.  If an application’s data is regulated, then data loss from that app could result in large fines regardless of how often that app is used.

RTO examples

Granular item recovery is one example of an RTO. For this example, a user at a busy company deletes an important email and empties the trash folder. This company uses Microsoft Exchange as a business-critical application and it’s IT department perpetually backs up delta-level changes in Exchange along with a backup app that features granular backup and recovery. This feature allows the IT department to quickly retrieve the important email in about five minutes instead of restoring a full virtual machine for only one email. 

Difference between a RPO and RTO  

RTOs coincide with recovery point objectives (RPOs), a measurement of time from the failure, disaster or similar loss-causing event. RPOs calculate back in time to when your data was last usable, probably the most recent backup. RPOs and RTOs are crucial concepts for business continuity and are necessary business metrics for determining how often your enterprise should schedule its data backups.

Getting a near-zero RTO or RPO

While RTOs and RPOs vary regarding the application and data priority, it’s incredibly costly for any enterprise to deliver a near-zero RTO or RPO for all their applications. A 100 percent uptime for RTO and zero lost data for RPO can only be attained by investing in continuous data replication and virtual environments.