After the recent storms, one might have guessed that my phone has been busy. Firstly let me say that Disaster Recovery by its very title is a bit of a misnomer. While I have some abilities to recover lost data using some forensic skills developed over decades of twiddling bits, that is not really disaster recovery.
Disaster Recovery and business continuity are about planning for an event which may or may not happen. The “plan” assumes that your business systems will be affected negatively and puts forth a tested strategy to recover from the said event.
With the recent devastation by hurricanes and earthquakes, one would think that those businesses not affected would be learning from those that were. If you search my blogs on this site, you will see that I have laid out
Do not ask him or her, are we covered just in case, ask them specific questions laid out in this blog here.
Yes is not a satisfactory answer, demand the details and the proof. I don’t care how much of a friend he or she is, demand the evidence. The devil is in the details, and the last thing you want is a bunch of excuses.
I am learning from phone calls that too many have been assured that they are covered, and that is very possibly why today they are looking for ways to recover data from destroyed equipment.
Disaster recovery is not some dark magic spell cast under the voodoo magic of bits and bytes in the wiring closet or back part of the computer room. The bottom line is to test it, whatever your people come up with, check it. Keep checking it until you can recover your business with outside contractors and hardware with data and documents prepared by your staff. There is to be no input from you or your staff during the test. The hurricane, earthquake, fire, attack from zombies or employee error took you and them away from the scene. The plan provided must work!
This is why we who do this insist that companies use “best practice” standards in the industry when creating your individual networks and systems.
One such company has a senior IT staff littered with programmers. These people think they know more than Microsoft. Using kludges from Unix, Linux and other programming wizardry to subvert some of the basic tenants of networking, they have made their network so unique that it will depend on them to be there to recover.
If it is not broken, don’t fix it!
Writing programs that workaround things like DNS is just crazy stuff and now it is dependent on the network never changing, at all.
If your data is successfully mirrored offsite, an excellent team of engineers might get you going in weeks, not days if you have failed to follow best practices. While your data might eventually be usable, you and your company will be on the sidelines as most businesses do not recover from such a catastrophe.
Folks I have been at this since 1982, I have learned a thing or two in those years. Ask your team the questions or be prepared for unpleasant surprises should you ever face a business stopping event.
Got to go and explain once again what disaster recovery is and is not.