At one point, I was asked to document the Disaster Recovery setup for a site. On the surface, it already existed. There was:

  • a dedicated link to another location
  • infrastructure in place at the remote site
  • even a Citrix environment intended to support users

It looked like DR but I didn’t think it was. The problem wasn’t the technology, it was the definition.

“the DR environment has been built in reverse… there are no services defined”

That was the core issue.

We had a link. We had network constructs. But we didn’t have a clear answer to a simple question:

what are we trying to recover?

In a real disaster scenario, the London core could be lost. The fallback was a single 100Mb link to another site. Expensive. Carefully controlled. Even manually shut down at times to avoid unintended traffic flows.

But what did that link actually provide?

  • Full user access?
  • Limited services?
  • Just connectivity for specific systems?

That part hadn’t been defined. This led to a fairly long-running disagreement. Not about configuration. About intent.

My view was simple:

You define the service first. Then you design the infrastructure to support it. What we had was the opposite. Infrastructure had been built first and the service definition was expected to follow. That’s not necessarily wrong but it creates ambiguity.

So the document I wrote ended up doing two things. First, it acknowledged the reality:

There was a DR environment, in the sense that there was a path to another site.

Second, it called out the gap: Without defined services, it’s difficult to say what “recovery” actually means.

The work itself was straightforward.

  • Define VLANs at the remote site.
  • Prepare routing.
  • Ensure that, if needed, the network could support traffic from London.

In a controlled state — often even left shut down until required. From the plan:

“the scope of restorative actions is kept to a minimum”

Which is a polite way of saying: We’re preparing the ground. Not delivering a complete solution.

The disagreement never fully resolved. We were using the same words to describe slightly different things.

Looking back, that’s the interesting part. Disaster Recovery isn’t just about links, hardware, or failover. It’s about:

  • what needs to work
  • how quickly it needs to work
  • and what “good enough” looks like under pressure

Without that, you don’t really have DR. You have options and sometimes, the most important part of the job is recognising the difference.

Tags: