管理灾难恢复

制定灾难恢复计划的方法多种多样。每个公司都必须利用各种工具和技术制定恢复计划，实施恢复战略，制定方法应该适应自身的商业模式、恢复需求和法规遵从。尽管方法各异，但灾难恢复计划绝非一日就能完成。在实际应用中，实施灾难恢复计划通常要改变存储设备，带来其它开销——开销问题必须加以解决。

　　恢复计划必须定期测试和更新，保证计划与公司同步发展，与IT基础设施同步增长。本质上说，灾难恢复管理必须同变化管理类似——必须成为公司日常管理的一部分，公司必须随时做好避免灾难的准备。

　　以下四点对于灾难恢复管理问题至关重要。

　　实施事宜
　　通常，灾难恢复战略包括现有存储和网络设施发生的变化。最终，存储管理员必须对硬件、软件、实施、培训、设备成本等因素做出预算和安排，适应灾难恢复战略的要求。添加硬件设备十分简单，就跟几年之前向磁带库添加磁带驱动器类似；但是现在还需要添加更多设施，如存储系统。举个例子，从NetApp公司购买NearStor虚拟磁带库（VTL），或从Data Domain公司购买重复删除存储阵列。

　　大多数情况下，根据最佳方案，为了恢复灾难而进行的备份应该发送到远程站点。Iron Mountain等公司提供的服务可以将物理磁带传送到安全的异地站点中，但是越来越多的公司开始采用磁盘备份，在两个或多个站点之间的存储系统中实施远程复制。例如，银行可能使用WAN链接从主数据中心的EMC Centera复制数据，也可能从备份数据中心的二级Centera复制数据。

　　灾难恢复策略需要依据软件而制定，通常包括一套或者更多的软件应用程序，如备份、快照、镜像和复制工具。EMC公司的TimeFinder等工具常用于创建数据卷的当地副本，称为业务连续卷(BCV)。这种存储阵列技术通常用于连接SRDF软件，意在复制Symmetrix DMX卷到远程站点中。NetApp公司的SnapShot、SnapMirror和SnapVault都是很好的软件产品，可以联合使用，成为灾难恢复战略的一部分。另外，还有独立的硬件复制解决方案，允许终端用户在不同的存储阵列之间复制，如Symantec公司的Replication Exec就属于此类产品。

　　无论软件是与存储系统绑定的，还是需要单独购买，IT人员必须花时间才能熟悉每项工具。精明的管理员应该能够保证关键的IT人员有时间学习每项工具。

　　部署了合适的灾难恢复设施后，还需要花很长的时间才能建立和维护最初的备份和复本。可能需要一个晚上或一个周末的时间，才能实现完全磁带备份，才能在WAN的站点中同步备份数据。最初的复制完成后，IT部门必须分配时间，实现增量磁带备份或隔夜复制。

　　安全事宜
　　公司依靠备份免受灾难影响，但是备份本身是否容易受到灾难影响？如果公司数据不受IT部门的直接控制，那么数据安全就显得非常重要。选择远程站点应该首先其评价物理安全。

　　磁带存储或远程数据中心设备都应该上锁，只有少数的授权人员才能接近。消防人员和灭火系统须采用气体灭火，才能保护电子设备和数字媒介（避免用水灭火）。存放地点应该保证不会受到水灾、地震或其它自然灾害的影响。根据公司特点，还应该考虑恐怖袭击等人为灾害。应事先检查远程设备。如果设备由Iron Mountain等公司管理，还应该用点时间讨论公司的安全和灾难计划，明确Iron Mountain等公司对你的数据应该承担什么责任。

　　数据本身需要通过加密技术保证安全。一般说来，只有私人信息必须保证安全，如社会保险和信用卡卡号等客户记录，不过公司复制数据时通常会选择加密所有的数据，以维护开放WAN的安全。通过备份软件可以实现加密功能，通过将加密产品集成到网络中也可以实现加密功能，如Decru公司的DataFort。

　　然而，在选择数据加密之前，应该首先评价其影响；你可能会选择其它技术来实施灾难恢复战略，需要评价加密措施对这些技术会产生什么影响。例如，如果对数据加密，数据重复删除技术就会丧失大部分（如果不是全部）精简数据的能力。

　　测试和培训
　　如果不能付诸实施，即使最先进的灾难恢复计划也无济于事。灾难恢复管理中一个重要的部分就是定期测试和培训，培养新的IT人员，加速灾难恢复进程，在具体的恢复时间目标（RTO）内实施恢复。

　　灾难恢复过程可能会干扰生产环境，因为需要将环境中一部分内容异地复制，才能真正测试恢复程序和支持程序的技术。在测试DR计划的同时，还必须制定合理的计划、采取适当的维护。

　　为了避免浪费生产时间、避免产生意外问题，一些公司往往会利用现有开发环境进行测试。这就有机会与生产网络采用相同的恢复性测试。这种方法虽然不能真正测试生产设备的可恢复性，却能为IT人员提供必需的参考价值。这种方法的实施步骤包括：IT人员讨论、评价DR计划，提出建议，改进灾难恢复进程。

　　没有指导手册指明灾难恢复计划应该多久测试一次，不过至少每年一次。除去常规测试，还可以根据需要进行附加测试，如人事调动、IT设备变动时，就需要对灾难恢复计划进行测试。如果你的公司与灾难恢复供应商签署了协议，协议内容通常会包括测试时间。这样，你就能远离生产环境，不加干扰地测试灾难恢复计划。不过，通常你需要提前安排测试时间。公司应该考虑知道，将一部分IT资源分配给灾难恢复计划测试，可能与常规责任不符。同理，要避免对生产环境造成不必要的干扰，需要制定合理的计划。

　　更新计划
　　最后，灾难恢复计划并非一劳永逸。存储资源、应用程序、IT人员、业务流程、公司实体（合并和收购）等都难免发生变化。变化发生后，灾难恢复计划必须及时更新，体现这些变化。例如，在系统中添加2 TB的存储容量、或者配置新的存储阵列后，灾难恢复计划就必须反应这些变化。另外，过去文件无需加密，而新的法律可能会要求对文件加密。

　　这些变化可能对灾难恢复战略产生负面影响。前面的例子中，添加了2TB同样的存储容量。由于存储越多，意味着备份时间越长，因此我们有必要考虑采用别的备份技术，或者增加WAN网络带宽，从而维持可以接受的RTO和RPO，实现数据复制。无论是哪种情况，公司的变化管理过程都必须包括灾难恢复计划。在实施灾难恢复之前，就确保IT人员变化不会对恢复能力产生影响。变化管理应该保证，在应用程序和基础设施的早期开发阶段，灾难恢复计划就已包括其中。