Designing a Disaster Recovery Plan

[SenseiSteve]

DESIGNING A DISASTER RECOVERY PLAN DOES NOT HAVE TO BE HARD
When I say that designing a plan shouldn’t be hard, that’s relative to the complexity of your network, the technologies you employ and its topology. Successful plans simply define step-by-step solutions on how to respond, and then validate those activities.

Your take on what should be in a disaster recovery plan, and how it should be executed ...

 

[Scaleblade]

Ultimately you want your disaster recovery plan to be made of two parts.

1. Data recovery
2. Temporary deployment solution

When **** hits the fan, the important thing is your data is backed up. Follow the typical 3-2-1 rule, 3 copies, 2 form factors, 1 off-site. Another thing some people miss is try to make your 3 copies at the source (ie the vm the database is on). Making 3 copies of a corrupt backup is not useful at all.

Typically we have our copies made on our centralised database server, copied once to our on-site storage (same cab, different machine) and then backed up to our Google Cloud Storage for long term.

We found having our second copy on some sort of “fast access” solution (such as another dedicated server in the same site) typically works out best when trying to minimise client disruption in an outage.

We have plans and partnerships with a multitude of different hosts as well as colocation agreements for smaller spaces in other European data centre's for if disaster strikes and London falls into a hole never to be seen again.

It is never too late to check your recovery plans, a dysfunctional system is no better than none at all.