The key to successfully recovering from a real disaster is to test your disaster recovery plan. The point of testing is to find things that need updating—and you will always find them. If you find a bad link in your disaster recovery plan, then fix it. Do not consider this test a failure. In fact, perhaps you should consider a test that doesn’t find something wrong a failure.
- Have a stranger test procedures
Don’t have the person who wrote the procedure test the procedure. Have someone who is competent, but unfamiliar with your systems, do the test. Perhaps you can hire a consultant to test your procedures; they should be written so that such a person should be able to follow them. Not only is it a great way to find loopholes in your procedures, it is a great way to test what would happen if you lost some essential personnel.
- Dream up disasters
This is the fun part. Ask the most pessimistic person you know to dream up disasters for you. See if he can come up with one that you haven’t planned for.
- Full-test every six months
This is what the contracts of many disaster recovery companies require. Such a test should take a day or so and is well worth your time. One of the problems with this is the availability of personnel. Again, hiring consultants is a good way to get this test done. Just don’t use all consultants and no company personnel, because then nobody in-house will learn much from the test.
- D/R companies will require a test
This is a great way to force you to do a test. If you have a contract with a disaster recovery company, they will require you to test your plan. If you don’t test your plan, you are in breach of contract and the D/R company cannot be held responsible. There’s something about paying money to a company for nothing that forces you to do what they want you to do—test!
Get Unix Backup and Recovery now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
