The specific situation, defined priorities and the disaster recovery (DR) plan at hand will define how to perform your customer's DR testing.
Keep in mind that redundancy has a huge impact on the DR exercise. For instance, the effort to rehearse failing over to a continuously updated redundant storage array in a secondary data center is relatively simple; in contrast, having no secondary array to fail over to requires restoring terabytes of data and rehearsing the loss of the data center itself. The DR testing efforts and costs associated with the two scenarios differ greatly, and companies need to do a thorough analysis before deciding whether to invest in redundancy or to pour money into a more elaborate rehearsal. The real payoff of redundancy comes into play when an actual disaster strikes. Loss of business productivity, caused by long recovery times, can easily exceed the cost of redundancy.
DR documentation needs to be updated continuously and reviewed periodically; a DR test must execute the documented steps meticulously. For instance, when a new system or application is procured for a customer, the DR plan should be updated and tested to account for those additions.
A solid change management and verification process must be in place to ensure that changes are performed according to procedure. Change management tools like Finisar Corp.'s NetWisdom, Onaro Inc.'s SANscreen, Tek-Tools Inc.'s StorageProfiler, as well as those tools built into storage, network and system management suites, track changes in your customer's environment that could ultimately make or break a DR plan.
For detailed DR planning considerations, read the full feature from Storage magazine: Disaster recovery: Test, test and test some more.
