What Is Disaster Recovery?

Disaster recovery is the restoration of technology systems and data after a disruptive event. It is the technical component that sits inside business continuity, and it is measured against the objectives set by an impact analysis.

Its quality is determined almost entirely by whether restores have been tested. Backups that have never been restored are an assumption rather than a capability.

Backups are not a recovery capability

A backup is a copy. Recovery requires knowing what order to restore in, having somewhere to restore to, having the credentials and documentation to do it, and having the time.

Organisations discover during real events that the backup is fine and the restore takes eleven days, or that it depends on a system that is itself down, or that nobody knows the procedure because the person who did it has left.

Ransomware changed the requirements

Attackers locate and destroy backups deliberately, because recoverable victims do not pay. Backups reachable with domain credentials, or stored on infrastructure joined to the same directory, are not protection against this.

What is needed is at least one copy that a compromise of the production environment cannot alter or delete: immutable storage, separate credentials, or genuinely offline media. That is now the defining requirement of a recovery design.

Testing, and what a real test includes

Restoring a single file proves very little. A meaningful test restores a complete system to a usable state, in the sequence dependencies require, within the stated objective, performed by someone following the documentation rather than by the person who built it.

Recording how long it actually took is the point. The gap between the stated objective and the measured time is the finding, and it is usually substantial.

Recovery site and cloud considerations

A warm site reduces recovery time and costs continuously. Cloud recovery has made this considerably cheaper, and introduces its own dependencies: if authentication, name resolution or network connectivity depend on the failed environment, the recovery environment cannot be reached.

Testing recovery in isolation from production is what surfaces those, and it is the part most commonly skipped because it is disruptive to arrange.

Documentation and the knowledge problem

Recovery procedures written by the person who designed the system assume knowledge the person executing them under pressure at three in the morning may not have.

The test of documentation is whether someone else can follow it. Having a different person perform the annual test is the cheapest way to find out, and it consistently finds gaps.

The order things come back in

Recovery is sequenced by dependency, and the sequence is frequently discovered rather than planned. Authentication before applications, name resolution before almost everything, databases before the services that read them.

A documented recovery order, derived from the dependency mapping in the impact analysis, is what prevents a team restoring the visible application first and then waiting for the infrastructure it needs. It is also the part a tested restore of a single system does not exercise.

Where to start

Establish when you last restored a complete system from backup, how long it took, and whether the person who did it was following documentation. If the answer is never, that is your recovery capability.

See designing for outages and backup testing. GuardsArm delivers incident response planning.