Your business needs a disaster recovery plan

RTO, RPO: behind these acronyms lie essential notions for keeping your business running after an IT incident.

The notions

Making backups is not enough. You must also test regularly that they can actually be restored. That is where the following notions matter: they define how much data loss and downtime your business can accept.

RTO – Recovery Time Objective

The maximum acceptable time to bring an infrastructure or service back online after an incident.

RTA – Recovery Time Actual

The time actually needed to restore the infrastructure. It measures the gap between the target (RTO) and operational reality.

RPO – Recovery Point Objective

The maximum amount of data the business can afford to lose. It is the interval between the incident and the last usable backup.

Why it matters

Many events can force a complete rebuild of your infrastructure. Cyberattacks come to mind first, but there are many other scenarios:

• Natural disasters: fire, flood, earthquake…
• Major hardware failures: servers, storage arrays or other essential components
• Burglary or vandalism

How to define them: an example

Imagine a company with 10 employees, each working 8 hours a day from 8am to 5pm, with an automatic daily backup at 11pm.

RPO

If an incident occurs at 4pm, everything created or changed since 11pm the night before is lost: a 17-hour window. The company must ask whether it can accept losing up to 8 hours of collective work, or 80 person-hours (10 × 8 h). This tells you whether the backup frequency is right or should be increased.

RTO

Suppose a disaster requires a full rebuild. If the goal is to be back up within 4 hours, the company must be able, in that time, to:

• Restore servers, systems and data
• Bring applications and third-party infrastructure, such as the network, back online
• Restore user access

Again, the question is strategic: how many hours of downtime can the business take without irreversible financial, operational or commercial consequences?

How to find your RTA

The RTA can be measured in two situations:

• During a restore test: simulate a disaster and measure the time really needed to reinstall, restore data and restart services.
• During a real incident: the RTA shows itself in real conditions and often exceeds the plan.

Comparing RTA with RTO reveals the gap between targets and reality, so you can adjust your business continuity (BCP) or disaster recovery plan (DRP).

Often-underestimated factors

• Ordering replacement hardware (servers, workstations, network gear): about 2 days for delivery on average.
• Preparing and installing the hardware, possibly in new premises or a recovery site.
• Actual recovery: configuration, restore, testing, then users back at work.
• Configurations specific to your business.

With these steps in mind, you get a realistic estimate of the time needed to get the business running again.

Conclusion

Defining your RPO and RTO is not a theoretical exercise: it is a pillar of your continuity plan. These metrics show the real impact of an incident and help you plan the means to limit losses. Without preparation, an outage can cost days of work. With the right strategy, you greatly limit the impact.