实际上DR（灾难恢复）是非常难的，过多的工作或者偷工减料都会让DR更难。精心的计划是打造成功的灾难恢复的最好选择。

　　许多IT从业人员（也许包括一些业务经理）决心采取措施来避免一些可避免的故障事件，以及处理一些无法轻易避免的故障。简言之，他们都决定认真对待企业IT运营的数据保护和灾难恢复计划的问题。

　　为什么灾难恢复计划过程如此艰难

　　若处理得当，灾难恢复（DR）计划是一项复杂而耗时的任务，这有助于解释为什么在过去的几年中，调查显示有连续计划的企业数量在下降。在一个年度普华永道（PricewaterhouseCoopers）的研究中，有灾难恢复计划的企业下降到约为39％，而去年同期的调查为50％左右。这些公司中，那些真正测试DR计划的企业通常是声称有计划中的一小部分。这些只有灾难恢复计划文档但是没有实际测试的公司，其实际上对DR的准备更加让人担忧。

　　由于对灾难恢复必要性和实际价值的误解，相关的计划活动也少了。明显的，虽然“更少（的员工）更高效的工作”就是“使用计算机来提高效率，”并且较少员工数量实际上更加依赖于自动化资源不间断的使用以及减少（哪怕是短时间的）中断操作带来的误差，但是这些见解和确保自动化的连续性和弹性的需求并没有联系起来。

　　投入总是一道坎。管理层总是想方设法把资金投入到能让企业有更多产出的地方，而非总是把钱优先投入到一个可能永远都不会使用的连续功能上。将资金主力投入到有收益潜力的项目上，这种通常的投资优先级在市场经济不确定的今天甚至更加严重，经常以风险防护为代价。

　　灾难恢复就是投入

　　灾难恢复规划过程中与预算、资源和时间的分配需求相关的常识，也会随着服务器虚拟化、数据去重、云计算等技术的营销和大肆宣传而减少。

　　过去的几年里，供应商们花费了大量的努力试图说服用户，这些技术能增强数据保护和改善运营。“高可用性胜过灾难恢复，”一服务器虚拟化管理程序供应商的宣传册上写到。一个数据去重设备供应商在贸易展上在保险杠上贴着“Tape Sucks. Move On（磁带差劲，寻求新技术）”的标语。“用云实现第一级数据保护，”一个服务供应商的PPT里宣称。这些广告语都暗示着灾难恢复已经过时了，应该被新产品或者服务里有弹性可靠的功能所代替。但实际上这些广告大多数都是完全错误的，或者至少是在很多条件下才成立的。

　　1、不要把高可用性和DR划等号。也许搭建灾难避免和恢复能力系统时，第一个也是最重要的需要避免的错误，就是相信供应商大肆宣传的DR计划不合时宜的言辞 。虽然高可用性技术（HA，high-availability）有很大的改进，但是任然需要连续的计划。HA总是灾难恢复方可选方案中的一部分。但是HA策略的使用总是受预算的约束：HA（集群组件之间的故障转移）比起其它方案来说要昂贵得多，而且对不需要连续提供的负载和数据来说并不合适。对大多数企业来说，只有大约10%的工作负载需要使用持续提供的策略。

　　2、不要试图让所有的应用程序都适用于一个DR方案。第二个灾难恢复计划常见的错误，和第一个注意事项紧密相关：不要试图部署一个适用于所有数据保护的DR。同样的原因，集群故障转移并不适用于所有的工作，也不是所有的数据都需要磁盘到磁盘的远距离复制，磁盘到磁盘的镜像，通过镜像连续的数据复制或者其他方法。大部分的数据都能通过磁带进行高效的备份和存储。如果都使用磁盘（包括备份数据），表面上看起来没那么复杂，但其实其开销要昂贵得多且缺乏灵活性。考虑到磁盘存储的几个风险，包括跨存储阵列镜像、复制的硬件限制、WAN的高成本和延迟抖动的敏感性以及其他许多因素，磁盘到磁盘的数据保护也许不能有效地保护客户的不可替代的信息资产。至少，磁带弹性、可移植性的特点是磁盘缺少的。请思考“深度的防御”。

　　如今只有大约30%的存储需要经常备份和复制，用以捕获每天的变化，其他的70%则很少需要备份甚至没有备份。

　　3、不要试图备份所有的数据。期望使用一个备份程序来备份所有需要保护的数据，是另外一个常见的错误。实际上客户的大部分数据（也许多达40%到70%）是混合归档性质的二进制数据（非常重要但是不会改变的数据，需要从生产存储移动到归档平台）和垃圾文件（重复和非法的数据，应该从客户的存储空间完全删除）。而存储中只有大约30%的数据需要频繁的备份和复制来捕获每天的变化；而剩余的70%的数据需要很少的备份甚至不需要备份。如果客户把归档数据和生产数据分开，可以从数据保护中抽出大部分的投入，从恢复数据中节约许多时间。这样做也可以重复利用客户昂贵的生产存储空间，改变年度存储空间扩展的成本曲线，也许能节约出大部分的钱来支付整个数据保护需要的存储空间。

　　4、不要忽视那些没有存储在数据中心的数据。这错误就是忽略了存储在数据中心以外的数据。不是所有的重要数据都集中存储在企业级SAN或者一些复杂的扩大网络存储（NAS）中。任务关键型数据可能存在于分支机构、台式电脑、笔记本电脑、平板电脑以及越来越多的智能手机。TechTarget存储媒体集团最近的一项调查表明，即使在BYOD（自带设备）流行起来之前，企业都很难在数据保护程序中收集分支公司和PC网络中的数据。今年发行的另外一项研究表明，211个欧洲企业中有46%承认从未成功备份过用户客户端设备的数据，BYOD有成为丢失数据的重大隐患的趋势。客户需要纠正这个问题，知道如何使用云备份服务处理这个空隙，并且客户需要自己选择合适的备份云。

　　5、对数据和基础设施的管理不善。另外一个DR计划新手容易犯的错误是忽视导致故障的根本原因，那就是缺乏对数据和基础设施的管理。仅是缺乏对数据的管理，就会导致灾难恢复计划中开销巨大，更不用说不能根据存储优先级（根据数据所支持的业务流）对数据分类了。（如果）没有数据重要性的概念，那么所有的数据都需要用非常昂贵的设备来进行保护。对于基础设施而言不能保护不可见的数据。没有使用任何形式的基础设施检测报告功能意味着客户无法主动的响应设备的各种故障以及不请自来的灾难。如果部署归档和分类工具来更好地管理数据，部署基础设施管理工具来更好地管理基础设施，这个问题可以得到解决。关于基础设施的管理，告诉你的设备供应商，如果这些基础设施不能使用选择的软件管理工具管理，那就不再购买他们的设备。这也能从常规的IT运营中节约很多成本。

　　6、不要试图在恢复站点上完全复制设备的设置参数。在本文的DR规划注意事项排行第六的是在灾难恢复环境中使用完全备份产品设备配置信息的规划。假设在一次故障之后，仅有一小部分的应用和数据需要重新实例化，客户就不需要设计一个完全匹配你正常产品环境的恢复环境。最小设备配置（MECs，Minimum equipment configurations）能帮助客户减少DR环境的成本并且简化测试。虽然在正常的环境下无法这么做，可以在恢复环境中利用服务器虚拟化技术来承载应用程序。测试对于转变（环境）来说非常关键，无论是从物理主机到MEC主机还是物理主机到虚拟主机。

　　7、不要忘记加强WAN链接。本文DR规划注意事项中的第七项是过于信任WAN连接并低估了WAN连接对恢复时间的负面影响。无论是在企业级的设施还是在云平台的主机环境，WAN必须合适的设置，来保证数据恢复或者远距离应用访问数据时，能提供顶级的性能。不论客户与云服务提供商签订的服务级的协议怎么样，客户实际的体验决定于WAN。不要忘记预备冗余的WAN服务，以免客户的WAN在产品环境的某种情况下出故障。同时需要记住远程恢复设备以及备份数据存储点和产品站点需要保持在至少80公里以上来避免两个站点都因为大面积的地理原因而破坏。大多数城市的广域网都提供低成本、高带宽的MPLS（multiprotocol label switching，多协议标签交换）连接，但是并不提供针对飓风等灾害提供有效的防护措施。

　　如果你计划使用云来作为你的恢复环境，请确保云拥有说明手册上的所有功能。

　　8、不要对云服务供应商太有信心。虽然没有上文所提及的陷阱那么显著，我们的第八个注意事项是，在处理灾难应用程序托管和灾后数据恢复方面不要对云服务提供商抱有太多的信心。如果你正在使用一个在线备份应用供应商的产品，比如在往备份云中慢慢的移动数据。你会对服务供应商积攒的数据量、需要备份到恢复环境的时间和资源感到惊讶。记住：通过T1网络来移动10 TB的数据需要花费至少400天。相反如果在云设备供应商运营应用程序，以后可以作为“热点”（hot site）进行访问，确保亲自访问供应商的设备。1970年，热点第一次被提出来时，有一个人出售不存在的热点，当他的骗局被发现时，被逮捕前一直藏在一个不引渡政治犯的国家。如果你确实计划使用云作为恢复环境，至少确保手册上的功能都是存在的，包括T1数据中心。

　　9、不要让程序设计阻碍了DR规划。这个注意事项是程序上的，规划者需要拒绝DR规划是被动行为的概念。为了完全实现企业功能的连续，复原能力和恢复功能需要一开始就在应用程序和基础设施里搭建。但是很少DR规划从业者参与程序的设计，并且基础设施往往是被指定的。这必须改变，坦白的说，现如今存在许多糟糕的设计，这会影响到一些企业将来的灾难恢复系统，这些设计包括应用的平台、服务管理程序或存储平台的数据、使用不安全的函数编码、大量使用缓存来存储重要的数据等等。如果DR从业者能更早的介入，那么就能做出更好的选择，IT能以更低廉的成本进行恢复。

　　10、不要忘记跟着钱走。管理层掌握着钱袋子，所以不考虑商业价值而光光考虑技术层面的DR规划是很大的失误。你需要向管理层表现得你千方百计来减少DR规划的成本，甚至不惜以牺牲性能为代价。并且需要强调这个规划能降低投资风险，提高产率，实现商业价值的最大化。只有这样你才能说服管理层把资金投入到DR规划上，否则是不可能的。郑重声明，DR规划中成本最昂贵的不是数据保护、重装应用以及网络重置；而是测试。所以最好搭建的DR在每天的运营就能测试，缓解正式的测试安排，让测试就像确定数据是否能恢复的后勤演练一样。