The Gap Between "We Have Backups" and "We Have a Plan"

Ask most business owners if they have disaster recovery in place, and the answer is usually yes — followed by a description of a nightly backup job. Backups are essential, but they answer only one question: can we recover the data? Disaster recovery answers a much bigger one: can the business keep operating, and how fast can it get back online?

The distance between those two questions is where most disaster recovery plans actually fail. A business can have flawless backups and still suffer days of downtime, lost revenue, and damaged customer trust, simply because nobody worked out the steps, the order, or the time it actually takes to restore a working system from those backups.

Two Numbers That Define Whether a Plan Actually Works

Disaster recovery planning revolves around two metrics that are easy to state and consistently underestimated in practice.

Recovery Time Objective (RTO) is how long the business can tolerate being down. If an e-commerce checkout system goes offline, an RTO of four hours means revenue stops, support tickets pile up, and customers start looking elsewhere — but the business survives. An RTO of three days for the same system could mean the business doesn't.

Recovery Point Objective (RPO) is how much data the business can afford to lose, measured in time. A nightly backup gives an RPO of up to 24 hours — meaning a failure right before the next backup runs could lose a full day of orders, transactions, or customer records. For a high-transaction business, that might be unacceptable, and the answer is more frequent backups or real-time replication, not just bigger backups.

Most disaster recovery plans fail not because these numbers weren't met, but because they were never actually set. Without a defined RTO and RPO, "how fast can we recover" is a guess made under pressure during an actual outage — exactly the worst time to be guessing.

Why Disaster Recovery Plans Fail in Practice

• They were never tested. A restore procedure that exists only as a document, never rehearsed against real infrastructure, reliably turns up problems exactly when there's no time to fix them — a missing credential, an outdated runbook, a dependency nobody remembered.
• They assume one failure mode. Plans built around "what if the server dies" often don't account for a ransomware attack that also encrypts connected backup drives, or a data centre power event that takes out a server and its on-site backup simultaneously. A plan that only protects against hardware failure isn't a complete plan.
• Nobody owns them. When responsibility for disaster recovery is spread across "the IT person" with no formal ownership, the plan ages quietly. Infrastructure changes, the plan doesn't, and six months later the documented recovery steps no longer match reality.
• They don't account for dependencies. Restoring a database is one step. Restoring DNS, SSL certificates, third-party API connections, payment processor webhooks, and email deliverability configuration is the rest of the work — and it's usually the part that takes longest, because it's the part nobody wrote down.

The 3-2-1 Rule as a Starting Point, Not the Whole Plan

The 3-2-1 backup strategy — three copies of data, on two different media types, with one copy off-site — is a sound technical foundation. It's also only the data layer of a disaster recovery plan, not the plan itself. A complete plan builds on top of 3-2-1 with the operational detail that actually determines how fast a business gets back online:

• A documented, step-by-step recovery runbook that someone other than the original author can follow under pressure
• Pre-provisioned or rapidly provisionable replacement infrastructure, so recovery doesn't start with "first, let's order a new server"
• Clear communication plans for customers and staff during an outage
• A defined chain of decision-making authority, so nobody is waiting for permission mid-incident

For UK businesses specifically, infrastructure choices that support same-day or rapid hardware deployment matter here directly — the gap between "our backup is intact" and "our business is back online" is largely determined by how quickly replacement compute can actually be stood up.

Building a Practical Disaster Recovery Plan

1. Classify systems by business impact. Not every system needs the same RTO. A marketing website tolerates hours of downtime; a payment processing system often cannot tolerate minutes. Tiering systems this way focuses recovery effort and budget where it actually matters.
2. Set RTO and RPO per system, in writing. These numbers should come from business stakeholders, not just IT — the cost of downtime is a business question.
3. Separate backup infrastructure from production infrastructure. Backups stored on the same server, same rack, or same data centre as production don't protect against the failures that matter most.
4. Test recovery, not just backup completion. A backup job reporting "success" confirms data was written somewhere. It does not confirm that data can be restored into a working system within the target RTO. Quarterly recovery drills are what turn a plan from theoretical to proven.
5. Document the full recovery sequence, including non-technical steps. Who notifies customers. Who has authority to declare a disaster and trigger the plan. Which vendor contacts need to be called.
6. Review and update the plan on a fixed schedule. Infrastructure changes constantly; a disaster recovery plan that isn't reviewed at least twice a year drifts out of sync.

The Bottom Line

A disaster recovery plan is only as fast as the infrastructure behind it. eServers' UK dedicated servers, built for same-day deployment, give businesses a realistic path to meeting an RTO instead of starting recovery with a hardware order.