Establishing Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs)

With sufficient funding and infrastructure, any system can theoretically achieve nearly constant uptime. Reality dictates a more conservative perspective. To create an applicable budget and practical plan, you will need to define your organizational tolerances for interruptions and losses. This article examines the related terminology and processes.

Now, you'll need to ensure that your system's key personnel can explore the question more deeply. If the term "business impact" does not express the desired level of urgency, ask the following questions:

"How much does it cost us per hour when this system is offline?" and

"After losing one hour of data, how many hours of work do we need to recover?"

Establishing Recovery Time Objectives

A simple question like "How long can we operate without this system?" might get your teams started. The term "Recovery Time Objective" (RTO) refers to the target defined by this inquiry. RTOs specify the maximum desired time a system can be down before it is restored to a defined state of availability.

Complex systems may have different RTOs. For example, you might set a four-hour RTO for restoring a core electronic records system after a major outage, but establish a one-hour separate target for minor disruptions. Your objectives can also define different levels of acceptable functionality.

Your organization may consider a ticket printer working in customer service as a meaningful success metric; it may have its own RTO as part of a larger recovery objective.

RTOs should be clearly included in your long-term disaster recovery planning. Rely on individual system managers and operators for guidance. Use managers to resolve conflicting priorities. Additionally, they may need to give you the ability to override decisions to ensure proper functionality is restored.

Establishing Recovery Point Objectives

RTOs are primarily applicable to functionality. Events that trigger recovery actions also tend to cause data loss. Your organization needs to establish tolerance. Naturally, no one wants to lose something, which will make these discussions harder.

Most backups occur at specific time intervals, so you use them as a basis for "Recovery Point Objectives" (RPOs). An RPO sets the acceptable maximum time interval between the last backup and the data loss event.

This determination overlaps with the work of defining the impact of an outage on business. The downtime of a system not only prevents users from accessing or using its content but also requires post-recovery work: staff will need to recreate data not in backups and complete delayed tasks.

You will need to establish multiple RPOs for most systems. Not all events will have the same effect, so set your expectations accordingly. For example, you may have options for continuous replication and backups.

These work well as a buffer against physical hardware failures. However, they are weak against malicious attacks, especially ransomware.

You can create a layered recovery approach to address various risks. For example:

• First-line hardware failure or breakdown: Zero-hour RPO using continuous replication
• Corrupted data: 1-hour RPO using on-site hourly backups after detection of corruption
• Site loss: 24-hour RPO using offsite daily backups and cloud hosting providers

Consider the potential outcomes of each risk category when calculating your RPOs. You do not need only data to recover; you need something to recover.

If you need to acquire spare hardware or bring in third parties for help, this can take time. If you have a secondary site, add an RPO item for recovery to that location. Also, add an item addressing inter-site difficulties. Do not forget to account for the presence of critical staff.

Defining Retention Policies

There is one more important decision your teams need to make: how long they will retain data. These decisions largely depend on the nature of the business and the data itself. For European-based operations, you may also need to consider GDPR requirements. If you don't have an immediate answer, use these two guiding principles:

• Legal requirements. For example, you may need to retain records of taxable events for several years.
• How long will the data remain valuable?

Make sure these questions are not solely the responsibility of IT. Since the word "data" is involved, some may naturally consider it a responsibility of technology personnel. However, IT typically does not hire legal experts, and the burden often falls on corporate responsibility managers.

Regarding the second point, IT may have some business knowledge, but "value" generally implies a subjective assessment that should include at least the data owner.

Use the answers to these questions to create "retention policies." A retention policy determines how long data can be kept. You will most likely need more than one policy at the company level. "Forever" may seem like an obvious answer for some things, but make sure everyone understands that data storage has associated costs.

There are two layers to data retention:

• Live storage
• Backup storage

In disaster recovery planning, IT typically considers only the backup layer. However, remember that a backup of any age captures existing data. Therefore, if you have records in a live database dating back ten years, your last backup includes ten-year-old information.

Therefore, both your current live data and your previous backup meet a ten-year retention policy.

To comply with both live and backup layers, retention policies need to consider two things:

• Policies for cleaning up active data
• The possibility of accidental deletion without being noticed

Some electronic record systems prevent actual deletion from databases without a cleanup action. "Deleted" records might be moved to a previous table or have a flag that removes them from visibility in client applications. These measures reduce the chance of accidents.

They can also help against malicious deletion. Remember that people with management access can usually override application-level security. For the highest security, assume you cannot reach your retention policies for live data.

You may relax this expectation for non-critical data. Consider the factor from the effect analysis results of previous exercises.

Ask, "If we lose this data forever, how will it affect the organization?"

Adjusting RTOs, RPOs, and Retention Policies to Match Practical Restraints

Shorter RTOs and RPOs almost always require more financial and technical resources. Short backup intervals consume more media space and network bandwidth. Longer retention policies increase storage and management costs. Layered approaches that cover various risk profiles can amplify these needs.

Backup operations add a load to the production system, which may add more than your existing equipment can handle. Replication and continuous backup technologies require more technical expertise than typical nightly backups. Personnel should periodically test the validity of backup data, adding effort and extra load.

Clarify all these constraints during early planning meetings. Make sure managers and department heads understand that costs will increase for quick RTOs and short RPOs. They may need to adjust their expectations accordingly.

Your plans should also account for the time and cost of rebuilding infrastructure after an error. You may need to replace physical systems. Critical infrastructure such as access control systems automatically take priority over everything they are connected to. Adjust your RTOs and RPOs accordingly for dependent systems.

The backup software you choose will play a role in your RTO and RPO constraints. Hornetsecurity's VM Backup V9 offers not only Continuous Data Protection (CDP) but also highly customizable backup scheduling options. You need this level of detailed flexibility to balance your backup needs with available resources.

Reviewing Recovery Objectives

The main activities of this article include inputs from all sectors of the business. Through discussions, surveys, and meetings, you can form an organizational view of what needs to be protected. Then, you need to determine how to implement this protection.

You have not completely finished working with non-technical departments, but you can allow them to collect the necessary data as the project moves to a different phase.

To properly protect your virtual environment and all data, use VM Backup by Hornetsecurity to securely back up and replicate your virtual machine.

For comprehensive guidance, get the indispensable resource that serves as your go-to for priceless information on backup and disaster recovery: the comprehensive Backup Bible.

Stay up to date with the latest articles and applications by visiting Hornetsecurity blog now.

Final Thoughts

In conclusion, understanding the significant differences between RTO (Recovery Time Objective) and RPO (Recovery Point Objective) is essential for disaster preparedness. While achieving continuous uptime is ideal, practicality and budget constraints require a balanced approach.

By clearly defining your organization's tolerances for outages and data loss, you can develop a resilient disaster recovery strategy that aligns with your resources and objectives. Carefully evaluating RTOs and RPOs will help your business navigate unforeseen challenges more safely and efficiently.

Source: Solving RTO vs. RPO: Fundamental Factors in Disaster Preparedness - Hornetsecurity