What is disaster recovery (RTO and RPO)?

Disaster recovery: definition and goals

Disaster recovery (DR) answers the question: what do we do when IT goes down and normal operations do not return quickly? Causes range from ransomware attacks and hardware failures to operating errors, fire, water damage or the failure of a data center. A DR plan defines which systems are restored in what order, by whom and how.

It is part of emergency and continuity management (business continuity) and complements backup and high availability: high availability absorbs partial failures, the backup supplies the data, and disaster recovery organizes the return to operations as a whole—with clear goals, a fixed sequence, named owners and procedures that are practiced regularly.

RTO and RPO: the two key figures

The recovery time objective (RTO) is the time within which a system must be running again after an outage. The recovery point objective (RPO) defines how much data loss is tolerable in terms of time. If backups run once a night, the RPO is up to 24 hours: everything that happened since the last backup would be lost.

Both values are derived from an analysis of what outages cost the company (business impact analysis). The shorter the RTO and RPO, the more complex the technology: from a simple backup and rebuild, through a prepared standby system, to continuous data mirroring to a second site.

Real-world example: a machine builder after a ransomware attack

A machine-building company falls victim to an encryption attack: ERP, file server and production planning come to a standstill. The company has nightly backups but has never practiced a restart. It is unclear in what order systems must start, where the installation media are and whether the backups themselves are intact.

Afterward it sets targets: ERP with an RTO of eight hours and an RPO of one hour, other systems later. Backups are additionally stored immutably at a separate location, a recovery manual is written and rehearsed twice a year. A vague intention becomes a reliable procedure.

Common mistakes and imple­menta­tion

The most common mistakes: backups that were never tested, backups on the same network as the production systems, missing prioritization and a plan stored only on the failed system. Contact lists and decision paths are often missing as well. A DR plan is only as good as its last successful exercise.

Nano Concepts supports you with analysis, target values and architecture: from backup concept and cloud recovery through restart plans to exercises. That way you know before an emergency what your business can actually withstand and how quickly it is running again, and you can justify investments in protective measures on objective grounds.

• Prioritize systems by business importance and set RTO and RPO per system
• Keep backups offline or immutable and in a separate location
• Test restoration regularly, not just the backup
• Keep the recovery plan and contact list available outside your own IT
• Name responsibilities for emergencies