The idea of a test, whether a full scale, or partial activity, should be performed to audit and verify that information and processes are properly documented and communicated to who will most likely need them. For example, a full-scale test may only be needed periodically. However, you should continually test or validate different pieces of the process. These tasks are as simple as testing to see if an individual file, volume, device or system can be recovered to a different system, physical or virtual.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The goal of a disaster recovery test is to validate that the processes you think are working actually do work, or, to identify issues ahead of time, whether these issues are with people, processes, or documentation. Also, note that in the course of testing, be careful not to introduce a disaster to your environment. Make sure you don't accidentally restore a file to the wrong location or disrupt a production application during a DR test. Furthermore, make sure you have a copy of your BC/DR documentation somewhere else besides on the systems you may need to recover. A little common sense can go a long way in disaster recovery planning and testing.
Dig Deeper on Small-midsized Business Disaster Recovery
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.