Ask most business leaders whether the organisation has disaster recovery in place, and the answer is usually yes. Ask them what that means, and the answer is usually some version of: "We have backups."

Backups are not a disaster recovery plan.

This isn't a technicality. It's a meaningful distinction that affects what happens to your business when something goes seriously wrong. And the number of businesses that find this out for the first time in the middle of an incident is uncomfortably high.

What Backups Actually Do

Backups are a data protection mechanism. Done properly, they give you the ability to restore data to a point in time, recovering files, database records, or configuration state that has been lost, corrupted, or encrypted by an attacker.

That's genuinely valuable. Without backups, a ransomware attack or accidental deletion can be catastrophic in ways that are almost entirely unrecoverable.

But backups only solve part of the problem. They answer the question: can we get our data back? They don't answer the question: how quickly can we get our systems running again?

Those are different questions with different answers, and the gap between them is where most DR plans fall short.

What Backups Can't Do

Restoring from backup is one step in a recovery process that typically involves many more. Consider what actually needs to happen after a serious infrastructure failure:

The servers or cloud resources need to be provisioned. The correct operating system, software versions, and configurations need to be applied. The application code needs to be deployed. The database needs to be restored from backup and validated. Integrations with other systems need to be reconnected and tested. DNS, load balancers, and networking all need to point at the recovered environment. Access controls, certificates, and security configurations need to be in place. And only then can you validate that the system is actually functioning before you route real traffic to it.

Each of those steps takes time. Each can fail independently. And in a high-pressure incident scenario, with no documented runbook and a team that has never run through the process before, each is an opportunity for delay, error, and further damage.

Backups give you the raw material for recovery. They don't give you the recovery.

The Runbook Problem

A disaster recovery plan that exists as a shared understanding, rather than a documented, tested runbook, is not a plan. It's an intention.

The people who hold that understanding in their heads may not be available when an incident occurs. Steps that seem obvious in a calm planning conversation become uncertain under pressure. Decisions that could have been made in advance end up being made in the moment, slowly, by people who are stressed and working from incomplete information.

A runbook documents the recovery process in enough detail that someone unfamiliar with the system could follow it. It covers the sequence of steps, the decisions that need to be made, the tools and credentials required, the people who need to be involved, and the validation criteria at each stage. It answers the question: if this broke at 2am on a bank holiday weekend, what exactly would we do?

Most organisations don't have this documentation. Those that do often haven't updated it to reflect infrastructure changes made in the last twelve months.

The Testing Problem

Even a well-documented runbook is theoretical until it's been tested.

Systems change. Dependencies are added. Cloud resources are modified. Configurations drift. A runbook written against last year's infrastructure may not accurately describe this year's environment. And backup files that have never been tested may not restore cleanly when you need them to.

Recovery testing is the only way to know whether your DR capability works. Not a partial test of the backup restoration process, but a full recovery exercise, against a realistic failure scenario, that validates the entire sequence from failure to restored service.

Most organisations do this rarely, if at all. When they do test, they often test against a simplified scenario that doesn't reflect what a real incident would look like. The uncomfortable truth is that many organisations' first real test of their DR capability is an actual incident.

What Actual DR Readiness Looks Like

Proper disaster recovery readiness has a few non-negotiable components.

Defined recovery objectives. You need to know, for each system, how long you can afford for it to be down (your RTO) and how much data you can afford to lose (your RPO). These should be driven by the business, not assumed by IT.

Architecture that can meet those objectives. For critical systems with aggressive RTOs, backups alone are rarely sufficient. You need infrastructure that can be brought back online quickly, which may mean maintaining a standby environment, using AWS services designed for rapid recovery, or investing in redundancy that allows automated failover.

A documented runbook. Step-by-step, current, owned by someone, and reviewed regularly.

Tested recovery. At least annually. Against a scenario that reflects real failure modes. With documented results.

Clear incident response. Who gets called when something goes wrong? Who makes decisions? Who communicates with customers and stakeholders? This is part of DR and often the part that's least planned.

A Question Worth Asking

If your primary data centre, cloud region, or AWS account became completely unavailable today, not a partial degradation but a full loss, how long would it take to restore service? Who would do it? Do they know the steps? Have they practised?

If you don't have clear, confident answers to those questions, your DR position is weaker than you think.

That doesn't mean a crisis is coming. Most organisations never face a catastrophic failure. But the ones that do, and that haven't prepared properly, tend to find that the consequences go well beyond the technical, into customer relationships, revenue, regulatory standing, and executive accountability.

Getting this right is not a large IT project. It's a structured piece of work, done once properly, then maintained. The cost of doing it is predictable. The cost of not doing it is not.