没有任何一家厂商在卖灾难恢复（DR）解决方案时，敢夸口该方案万无一失，并保证能完好无缺地救回所有数据；如果你遇过这种厂商，那么他肯定在诓你，你最好赶快换一家，就像不是花大钱从电视购物买了台健身机，就能保证你一定减肥成功。

　　DR也是一样，不管贵公司现在使用的是Host-Based还是Storage-Based 备份方式，如果平常没有养成”正确”的DR测试、演习方式，那么最后大难来时，肯定还是会措手不及。

　　DR 测试人人都在做，巧妙也各自不同，怎样才能算是”正确”的方式呢？笔者认为，至少要先能够避免以下5点容易犯的错误，才不至于让平日辛苦的DR测试工作，最后都变成在作白工。

　　1）不完整的DR设定或不足够的DR资源：几乎大多数的公司都会犯上这样的毛病。明明就期望DR Site能够在Production Systems出状况时成功地接手进行Failover，而且RPO （Recovery Point to Object）和RTO （Recovery Time to Object）期望又其高无比，但分配给DR的资源却与Production天差地远。试想，贵公司系统出状况时，分配给DR Site的内存与CPU，真的足以撑起整个Production Load吗？

　　2）不同RDF群组所导致的数据复制不一致：在需要复制群组（Remote Data Facility， RDF）的大型EMC SRDF/S与SRDF/A环境中，特别容易产生这种状况，因为当不同的RDF群组同时提供储存容量给主机，并且被相同的数据库使用时，每个RDF群组都会对应不同的复制接收器与（或）网络基础架构，并产生不一致的复制数据。每次关闭应用程序、数据库或是主机时，或多会少都会让这些数据处于不一致的状况之下。

　　所谓「失之毫厘，差之千里」，每个复制版本有些微的差距，最后就会复制出差别超大的复制数据，而DR Site在接手救援工作时，要嘛就是救回错误的数据，不然就是救援时间会被拖得很长。然而多数的DR 测试当中，很容易会忽略RDF群组导致的数据不一致，也并不容易模拟。

　　3）数据毁损风险：通常我们并不会同时启动所有的主机，而且多数的DR 测试也只选择用小群组方式分批测试。然而在灾难发生时，这些主机很可能会被同时启动，如果其中部分主机存取数据库的权限设定有误，很容易造成RTO违规错误，拉长救援时间，而且也容易造成数据毁损。然而如果储存管理员能经常注意磁盘Mapping问题，避免发生失误的话，就比较能避免这样的惨事发生。

　　4）无用或错误的时间点数据快照备份（PiTC）：一般来说，PiTC快照通常被认为是避免人为疏失的第二道防线，但除非应用程序与数据一致性都经过严格的测试，否则这些PiTC仍然容易存在不一致的状况。如果在DR 测试时能针对所有服务进行测试，并同时开启、监控DR服务器与应用程序，比较可以发现系统中是否有这样的问题存在。

　　5）最后一项容易犯的DR 测试错误，就是自以为测试成功了，但其实根本就没做。这听起来很吊诡，但其实原因很简单。有些公司在进行DR测试时，忽略应把CIFS或NFS与Production Devices分开，而DR Site不管如何反正就是要从CIFS/NFS存取数据，因此无形中也使用了Production Devices的资源。换言之，Production Devices出状况的情况根本没有被考虑进去，而真实的灾难往往就是发生在Production环境中。

　　以上5点错误有的并不容易发现，有些则非常基本，然而若不去考虑这些可能发生错误的问题，状况来时可能就无法成功执行看似完备的DR计划。因此，笔者先提出上列5点供大家思考。下次，笔者将试着与各位读者讨论更多与DR测试有关的心得，例如，更多DR测试时应避免的错误，以及自动DR测试与监控的好处。