Requires Free Membership to View
When you register for SearchSMBStorage.com, you’ll also receive targeted emails from my team of award-winning editorial writers. Your company has different needs from that of an enterprise, and it’s our goal to keep you informed on the hottest topics, the latest news and the biggest challenges that are unique to your job.
Rich Castagna, Editorial Director
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.
This was first published in October 2009