We have backup. Why do we also need disaster recovery?

Backup tells you the data survived. Disaster recovery tells you how fast you're working again. After a serious failure, restoring files isn't enough — you have to bring up servers, network, applications and identity in the right order. Without a plan that's improvisation under pressure, with a loss counter ticking.

How do you set RTO and RPO?

From the question of what an hour of downtime actually costs you and how much data you can lose without disaster. For a sales system RTO may be minutes; for an archive, hours or days. Not everything needs the top tier; we match it to the importance of the system, because every minute of RTO has a price.

How often should a DR plan be tested?

At least once a year, and more often for critical systems and after any major infrastructure change. Testing is the only way a plan on paper becomes certainty. We'd rather the first real recovery wasn't the first one ever.

Disaster Recovery: RTO, RPO and a Plan That Actually Works

"We have backup" is a reassuring sentence — until the day you need to use it. Because backup answers only one question: did the data survive. The second, more important one for the business — how fast do we get back to work — is answered only by disaster recovery. After a serious failure, that difference decides whether you're down for hours or days.

TL;DR

Backup ≠ DR: backup is a copy of data, DR is the ability to restore a working environment
RTO: how long the return to operation may take
RPO: how much data you can lose, counting back from the failure
These two numbers drive the whole DR project — and its cost
An untested plan is an assumption, not a safeguard

Backup versus disaster recovery

Backup is a copy of data — files, databases, machines. Disaster recovery is the ability to restore a whole working environment after a failure: servers, network, applications and identity, in the right order and on time. Backup without a DR plan is the worst case: the data exists but the business is down, because nobody knows what to start first or how long it will take.

The simplest analogy: backup is the spare parts, disaster recovery is the manual and the crew that assemble a working car from those parts before the customer walks away.

RTO and RPO — two numbers that govern everything

RTO (Recovery Time Objective) is the maximum time the return to operation may take. RPO (Recovery Point Objective) is how much data you can lose, counting back from the failure — i.e. how often a copy must be made.

These two numbers drive the architecture and the cost of the plan. An RTO measured in minutes needs a ready-to-boot replica; an RTO in hours allows cheaper solutions. So we set them up front, from a simple question: what does an hour of downtime of this system actually cost you? Not everything needs the top tier — a sales system and a document archive are two different leagues.

How fast an environment can be recovered

In practice we build DR on Veeam. Instant Recovery lets you boot a machine directly from backup in minutes — for critical systems we offer plans with RTO under 15 minutes. Offsite replication keeps a ready copy outside the premises, and immutable copies protect against the case where ransomware encrypts the backup too. There's also an element that's easy to forget: recovery order — what has to come up first (e.g. a domain controller, a database) for the rest to start at all.

A plan nobody tested is an assumption

The most common sin is a written DR plan that was never verified. Such a plan works beautifully — on paper. The first real recovery during an actual failure is the worst moment to discover a missing password, a missing license, or that the order is wrong. So we run periodic recovery drills and give a report from each. Testing turns a plan into certainty.

Not sure what RTO and RPO your systems have — or whether a DR plan even exists? See how we build disaster recovery or book a free consultation — we'll set the targets and cost the plan. We run backup as a service under managed backup.