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.
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 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.