The Recovery Time Objective (RTO) is the time within which a business process must be restored after an incident in order to avoid unacceptable consequences for the company.

Table of Contents

• Definition of the RTO
• What is the difference between RTO and RPO?
• How do companies determine the RTO?
• What is the RTA?
• How can the Open Telekom Cloud help to lower the RTA of companies?

The RTO is a target that a company's management sets in the disaster recovery plan or business continuity plan. It determines how much time may pass after an incident such as a technical failure, a malware attack or a fire until the operation of a specific system, network or program can be resumed. It is measured in seconds, minutes, hours, or days.

Management makes this determination following a business impact analysis – an examination of the economic impact that a failure of certain processes could have on the company. In doing so, it must weigh costs against benefits: A near-zero RTO requires a larger budget for a failover data center or automated systems than a 14-day RTO. In contrast, a longer RTO causes more lost revenue and reputational damage when customers are affected.

The RPO (Recovery Point Objective), along with the RTO, is the critical target when defining a disaster recovery or data protection strategy. However, RTO and RPO can easily be confused because they are both defined in time units such as minutes or hours. 

While the RTO specifies the amount of time that may pass before an IT device or program is restored after a failure, the RPO specifies the amount of time that may pass between two backups to ensure normal operation after an IT goes down. The RPO thus specifies in days, hours or minutes how much data may be lost. For example, with an RPO of 15 minutes, a backup must be created every quarter of an hour.

A company's emergency team determines the RTO as part of a business impact analysis (BIA). To do this, it first examines for each business process what damage its failure would cause. Once the emergency team knows the damage level, it can determine the maximum tolerable downtime (MTA). It then defines the RTO for each process, which must always be shorter than the MTA. The RTO is made up of the time from incident to detection, the response time, and the time needed for the actual restart, i.e., the start of emergency operations. 

To determine whether the technical and organizational measures are sufficient, emergency teams must determine the Recovery Time Actual (RTA). This indicates how much time the company actually needs to restart the systems. As part of a target/actual comparison, those responsible can then check whether the planned RTO can be achieved with the existing measures. They can determine the RTA as part of exercises and tests. If the emergency team finds discrepancies between RTO and RTA, they must define measures to reduce the RTA.

The Open Telekom Cloud offers you a broad portfolio of options for reducing your RTA with disaster recovery solutions from the cloud. In a comparative test by the trade journal the cloud report, the Open Telekom Cloud took first place in the backup category. The reason given was that of all the cloud providers tested in the area of data backup and recovery, it had the "widest range of functions at moderate costs".

We provide virtual machines (Elastic Cloud Server, ECS), bare metal servers and suitable network technology on which you can operate your own disaster recovery solution. Our infrastructure provides the highest level of security, in accordance with European data protection regulations and, if required, also in accordance with the criteria of the BSI for georedundancy.

We also offer our cloud services, which you can easily book via our web console. Our Object Storage Service (OBS), for example, runs in a high-availability cluster by default. This is done by synchronizing data between three availability zones located in two independent data centers. As a result, your data is available even in the event of an extreme event that causes a data center to fail.

Also, for virtual machines from our Elastic Cloud Server offering and block storage from the Elastic Volume Service (EVS) of Open Telekom Cloud, you can achieve high availability and failover capabilities. This is made possible by using our Storage Disaster Recovery Service (SDRS) as an add-on. The service supports all solutions that do not have local hard disks or dedicated network cards assigned. 

Furthermore, you can use backup services such as Volume Backup Service (VBS), Cloud Server Backup Service (CSBS) or the Cloud Backup and Recovery (CBR) service to create backups and restore them quickly in case of damage.