RTO vs RPO: Two key components of BCDR success
Defining correct Recovery Time Objective (RTO) and Recovery Point Objective (RPO) parameters underpins successful business continuity and disaster recovery (BCDR).
Table of Contents
Helping clients understand these terms will allow them to define these two critical elements correctly. Their BCDR effort can then focus on RTO and RPO achievement so their disaster recovery plan can succeed.
What is a Recovery Point Objective (RPO)?
The RPO is the maximum length of time in the past from which an element of the business can revert without intolerable impact on operations. For information held in computer-based storage, this is the maximum age that any file can be before its data is unusable.
RPO will depend on how often information changes. Product details on a website may only change every few days, while order information may change every few minutes.
Calculating RPO requires assessing how much data loss you can tolerate if a disaster occurs.
What is a Recovery Time Objective (RTO)?
The RTO is the longest time an element of the business can be unavailable before its loss becomes intolerable. This element could be a computer, a network, or an application critical to the company. Alternatively, it could be access to information or loss of function like email, preventing business as usual.
The goal for any business is to build resilience and redundancy so that the loss of any element will be tolerable for as long as possible. The shorter the RTO, the faster the business must recognize the loss and complete disaster recovery actions.
RTO must cover business processes as well as the underlying technology. You can find more information on Business and Technology RTO Alignment from the Business Continuity Institute (BCI).
What are the differences between RPO and RTO?
The difference between RTO and RPO is fundamental. Both are core elements of BCDR related to recovery times, but they are independent and serve distinctly different purposes.
The RPO is the criteria businesses use to determine how frequently they must preserve critical information to retrieve it for recovery from an incident that has compromised that information.
For computer-held information, the RPO determines the backup frequency. For example, data with an RPO of one day will require daily backups, while a shorter RPO will require more frequent backups.
There will be a class of information, such as financial transactions, where any data loss can be critical to the business; hence the RPO is effectively zero. Techniques such as continuous backups will be necessary in these cases.
The RTO is the criteria that decides what policies are needed to recover business operations in the event of an incident causing data loss. These policies then dictate what processes and technological solutions are necessary to implement these within the constraints of the RTO.
To aid in the quantification, Axcient provides a helpful online RTO Calculator.
What are the similarities between RPO and RTO?
Comparing RTO vs RPO, both are critical components of any business continuity plan. Together they provide the criteria for a successful disaster recovery back to normal operations.
These recovery objectives are measurements of time that define the boundary between business recovery with tolerable impact and the point of intolerable loss of information, service, or function that will mean the business cannot recover. Both critical metrics drive BCDR planning and decision-making for recovery processes and technology.
Why are RPO and RTO essential for BCDR success?
Any significant period of downtime can be disastrous. The challenge is quantifying when the period between a process or service becoming unavailable and the failure to restore it becomes intolerable. Indeed, defining the criteria for intolerability can be challenging in disaster recovery.
RTO is critical for businesses, particularly those providing services or products. However, once the downtime becomes too long, new customers are lost, and existing customers look for alternative suppliers. BCDR planning ensures that the worst-case recovery time for any incident will be shorter than the RTO.
However, recovery of processes within RTO is insufficient if vital information is lost. Here, RPO determines if the BCDR process returns the business to normal operations without an intolerable loss of data that renders the operations ineffective.
Therefore, disaster recovery success relies on satisfying the data recovery point and recovery time objectives.
How to explain RPO and RTO to your clients
The best way to explain RPO and RTO is through practical examples in business recovery.
Starting with RTO, this is the period where an organization can afford for all activities to stop before successful recovery is impossible. For example, suppose the company is an online store. Then, it may tolerate its website being offline for one week. However, this period may be much shorter for its financial management and banking processes due to the inability to manage cash flow.
Next is RPO. Suppose that an incident involving a fire in a computer room destroys the equipment that holds the business’s data store, so they lose immediate access to all their information. The disaster recovery process will involve replacing the damaged equipment and recovering the information from a backup that they thoughtfully positioned in a different location.
Backup frequency is a critical factor. A once-a-day interval means an organization can lose a whole day’s work if an incident causes data loss close to scheduling the next backup. A 15-minute schedule reduces this impact but increases computing and network resource overheads. Creating an active-active high-availability virtualized mirror environment will prevent loss if a cost-benefit analysis deems this proportionate.
However, if the data backup contains only commercially critical file and folder data, restoring equipment configuration, services, and applications from scratch will take longer than if the data backups include a complete image. While minimizing data backup contents to information the business deems critical for its operations reduces overheads, it risks noncompliance with the RTO. Hence deciding what data to backup and its frequency affects both RTO and RPO.
You can read more about this in RPO and RTO: The Conceptual Vise Grips of BDR Sales.
How to implement RPO and RTO in BCDR planning
Effective BCDR planning requires a thorough understanding of the processes within the plan’s scope and the application of business impact analysis techniques.
Each process will have a maximum time that it can be unavailable before its impact on business viability becomes intolerable. The RTO is quantifiable as the longest time measured from when each possible disaster scenario starts to when the business becomes unviable.
Each process will have critical components necessary for that process to operate. Some components will, in turn, rely on access to mission-critical data to complete their function. Therefore, an objective review of each information type will establish the maximum age for data before it becomes outdated, preventing the process from operating. This age is the RPO, determining when the business must back up the applicable data.
RTO and RPO are two critical components of BCDR planning, defining key criteria of disaster recovery strategy and planning. However, while these are time-based parameters of normal business operations, they are unrelated.
The RTO and RPO for a critical process are defined through analysis to determine the distinction between a successful recovery and an intolerable impact. The business’s priorities will inform this analysis for recovery, its risk appetite, and its definition of intolerability.
Once established, the RTO and RPO are critical success criteria in BCDR planning. However, they are also valuable cybersecurity metrics. For example, this article shows how Cybersecurity Can Boost Your Bottom Line: 3 Often Overlooked Opportunities.
About the Author: Carissa Johnson // Product Marketing Manager, Axcient
Carissa Kohn-Johnson has a background in healthcare technology and information technology, and is now the Product Marketing Manager for Axcient. She has a lot of MSP Channel experience from planning and attending hundreds of conferences and tradeshows, and found her passion in IT. Carissa is also an elected official in Cary NC, a town chock full of technology-forward people. Connect with her on LinkedIn – perhaps you can contribute to the Axcient blog?