What Are RPO and RTO

When an IT system fails, two questions quickly become important: how much data can your organisation afford to lose, and how long can the affected service remain unavailable?

Recovery Point Objective (RPO) and Recovery Time Objective (RTO) help organisations answer those questions.

Both are fundamental to backup, disaster recovery and business continuity planning. Although RPO and RTO are often discussed together, they measure two very different things. Understanding the difference helps organisations choose appropriate backup frequencies, recovery technologies and disaster recovery strategies for different workloads.

What Is RPO?

Recovery Point Objective (RPO) defines the maximum amount of data loss an organisation is prepared to tolerate following an incident, expressed as a period of time.

Put more simply:

RPO asks: How much recent data can we afford to lose?

Imagine an organisation backs up an important database every four hours.

If the database fails shortly before the next backup takes place, the organisation may need to restore from the previous successful backup. Potentially, several hours of changes could therefore be lost.

If losing four hours of data would cause serious operational or financial problems, the organisation needs a lower RPO and a protection strategy capable of supporting it.

An RPO might therefore be:

• 24 hours for relatively static or low-priority data
• 4 hours for general business systems
• 1 hour for important applications
• 15 minutes for critical systems
• Seconds or near-zero for highly transactional workloads

There is no universally correct RPO. It should reflect the importance of the data and the impact its loss would have on the organisation.

What Is RTO?

Recovery Time Objective (RTO) defines the target amount of time within which a system, application or service should be restored following disruption.

In simple terms:

RTO asks: How long can we afford for this service to be unavailable?

Consider an organisation whose customer-facing application becomes unavailable at 10:00.

If its RTO is two hours, its recovery strategy should be designed to restore the required service within that recovery objective.

For another system, an eight-hour or even 24-hour recovery period might be perfectly acceptable.

Again, there is no single correct RTO.

A payroll system, customer portal, transactional database and archive server are unlikely to have identical business requirements. Their recovery objectives should reflect their individual importance.

RPO vs RTO: What Is the Difference?

The easiest way to remember the difference is:

RPO is about data loss. RTO is about downtime.

Although both are measured in time, they describe different aspects of recovery.

An organisation could, for example, have an RPO of 15 minutes but an RTO of four hours.

That would mean it aims to lose no more than approximately 15 minutes of data while accepting that restoring the affected service could take up to four hours.

A Simple RPO and RTO Example

Imagine an online ordering system.

The organisation decides that losing more than 15 minutes of order data would have an unacceptable impact on customers and operations.

Its target is therefore:

RPO: 15 minutes

The organisation also determines that the ordering system should be operational again within one hour following a major incident.

Its target becomes:

RTO: 1 hour

Its backup and disaster recovery architecture now has two measurable requirements to work towards.

The organisation needs a data-protection method capable of providing sufficiently frequent recovery points and a recovery process capable of restoring the service within the required timeframe.

This is why RPO and RTO should ideally be defined before choosing recovery technology, rather than selecting technology first and allowing its capabilities to dictate business requirements.

How Do RPO and RTO Work Together?

RPO and RTO provide two sides of the recovery equation.

Consider a ransomware attack affecting an important application.

The RPO helps determine how far back the organisation may need to recover without losing an unacceptable amount of legitimate data.

The RTO helps determine how quickly the application needs to be operational again.

Meeting one objective does not automatically mean meeting the other.

An organisation might have a very recent backup and therefore satisfy its RPO, but if restoring that backup takes 12 hours when the application’s RTO is two hours, the recovery strategy still fails to meet its objective.

Similarly, an application could be restored very quickly but from a recovery point created eight hours earlier. If the business can tolerate only 30 minutes of data loss, the RTO may have been achieved while the RPO has not.

A resilient recovery strategy needs to consider both.

Different Workloads Need Different Recovery Objectives

One of the most common mistakes in recovery planning is treating every workload as equally important.

They rarely are.

Consider four systems within the same organisation:

These figures are examples rather than recommendations, but they demonstrate an important principle:

recovery objectives should follow business criticality.

Attempting to give every workload an extremely low RPO and RTO can introduce unnecessary cost and complexity.

Conversely, assigning relaxed recovery objectives to critical applications could leave the organisation exposed to unacceptable data loss or downtime.

The first step is therefore to understand which systems actually keep the organisation operating.

How Does Backup Affect RPO?

Backup frequency has a direct relationship with potential data loss.

If a backup is taken once every 24 hours, there could potentially be a significant gap between the most recent recovery point and the moment an incident occurs.

Increasing backup frequency creates more recovery points and can reduce that gap.

However, backup schedules need to consider factors including:

• data volumes;
• available storage;
• network capacity;
• application performance;
• retention requirements;
• backup windows;
• infrastructure;
• recovery requirements.

For some workloads, conventional scheduled backup provides entirely appropriate protection.

For others, an RPO measured in minutes or seconds may require technologies such as replication or continuous data protection.

How Does Backup Affect RTO?

Having a backup does not tell you how quickly you can recover from it.

RTO can be affected by:

• the amount of data being restored;
• where the backup is located;
• network bandwidth;
• storage performance;
• whether infrastructure needs rebuilding;
• application dependencies;
• recovery automation;
• availability of replacement infrastructure;
• the recovery method being used.

This is why simply stating that an organisation “has backups” does not constitute a disaster recovery strategy.

The organisation also needs to understand how those backups will be recovered and how long that process is likely to take.

Regular recovery testing is therefore an important part of validating whether an RTO is realistic.

Backup, Replication and Continuous Data Protection

Different data-protection technologies can support different recovery objectives.

Backup

Traditional backup creates recovery points according to a schedule.

It is well suited to many workloads and is particularly important for retaining historical copies of data.

Depending on backup frequency and recovery architecture, however, it may not always provide the extremely low RPOs and RTOs required by the most critical systems.

Replication

Replication maintains another copy of a workload or its data at a secondary location.

Because the recovery environment may already contain a replicated version of the workload, replication can help organisations achieve shorter recovery times than rebuilding systems entirely from backup.

Continuous Data Protection

Continuous Data Protection (CDP) captures changes much more frequently than traditional scheduled backup.

For appropriate workloads, this can provide highly granular recovery points and help organisations work towards very low RPOs.

This doesn’t mean CDP should replace backup everywhere.

The appropriate strategy often combines technologies according to workload requirements.

RPO and RTO in Disaster Recovery

Backup primarily protects data.

Disaster recovery considers how the wider service or system will be restored following significant disruption.

That can include:

• virtual machines;
• applications;
• databases;
• networking;
• compute infrastructure;
• storage;
• authentication services;
• dependencies between systems;
• failover and failback procedures.

RPO and RTO provide measurable objectives around which these recovery processes can be designed.

For example, if an organisation establishes that a critical application requires an RTO of 30 minutes, a recovery plan involving several hours of manually rebuilding servers is unlikely to be appropriate.

A replicated or pre-provisioned recovery environment may be required instead.

This is where business requirements begin to influence technology architecture.

RPO and RTO in Ransomware Recovery

Ransomware adds another dimension to recovery planning.

Rapid recovery is important, but organisations also need to ensure that they recover from an appropriate clean recovery point.

Restoring the latest available copy may not help if that copy already contains encrypted, corrupted or compromised data.

A ransomware recovery strategy therefore needs to consider:

• How far back might we need to recover?
• How quickly can we identify a clean recovery point?
• Are protected copies immutable or otherwise isolated from attack?
• How long will validation and restoration take?

This is another reason why recovery objectives should form part of a wider cyber-resilience strategy rather than being treated purely as backup settings.

How Should Organisations Define RPO and RTO?

RPO and RTO should ultimately be based on business impact, not arbitrary technical targets.

A useful starting point is to ask:

1. Which workloads are critical?

Identify the applications, data and services required for the organisation to operate.

2. What happens if each workload becomes unavailable?

Consider financial loss, operational disruption, customer impact, contractual commitments and regulatory consequences.

3. How much data could be lost?

Determine how much recent information could realistically be recreated or lost without causing unacceptable harm.

This helps establish the RPO.

4. How long could the workload remain unavailable?

Determine when disruption begins to create unacceptable consequences.

This helps establish the RTO.

5. Can the existing technology meet those objectives?

Assess backup frequency, replication, storage, network capacity, recovery infrastructure and operational processes.

6. Has recovery actually been tested?

A theoretical RTO is not the same as a demonstrated recovery time.

Testing helps organisations understand whether their recovery objectives are achievable in practice.

Lower RPO and RTO Are Not Always Better

It can be tempting to define every workload with an RPO and RTO as close to zero as possible.

Technically, that sounds ideal.

Operationally and commercially, it may make little sense.

Lower recovery objectives generally require more capable infrastructure, greater automation, additional storage or compute resources, more frequent data protection and potentially more complex recovery architecture.

An organisation therefore needs to balance:

business impact + risk + technical feasibility + cost

A system that can comfortably remain offline overnight doesn’t necessarily need the same recovery architecture as a revenue-generating application processing transactions every second.

The goal is not to achieve the lowest possible RPO and RTO.

The goal is to achieve appropriate recovery objectives for each workload.

RPO and RTO: Key Takeaways

Recovery Point Objective (RPO) defines how much data an organisation can afford to lose, measured in time.

Recovery Time Objective (RTO) defines how long a system or service can remain unavailable before it should be restored.

Both should be based on business requirements rather than chosen arbitrarily.

Different workloads can—and usually should—have different recovery objectives.

Backup frequency influences available recovery points, while recovery architecture and processes influence how quickly services can be restored.

Replication and continuous data protection can support more aggressive recovery objectives for appropriate workloads.

Most importantly, recovery objectives should be tested. A recovery plan that exists only on paper cannot demonstrate that the required RPO and RTO can actually be achieved.

Understanding Recovery Objectives Is the Starting Point

RPO and RTO turn vague requirements such as “we need our systems back quickly” into measurable recovery objectives.

Once an organisation understands how much data it can afford to lose and how long each critical service can remain unavailable, it can design backup and disaster recovery strategies around genuine business requirements.

That makes RPO and RTO more than technical terminology.

They provide the link between business resilience and the technology used to deliver it.