没测试过的灾备系统才是企业最危险的敌人

在自然灾害频发的地区，企业往往比较重视灾难备份、恢复的工作；但是每年真正遇到灾难的时候，总是有企业因为关键数据的恢复遇到问题而遭受损失。在这种情况下，是否真实的测试你的灾难恢复系统，是确保在灾难真正来临的时候能够按照预期进行数据恢复的关键要素；而且身为管理员，一定要清楚的认识到，不是所有的数据都需要在第一时间得到恢复，确认哪些数据是业务最关键的部分也是在制定恢复策略中重要的工作之一。下面，CIO.com的企业应用和SaaS专家Todd R. Weiss为我们介绍了他对灾难恢复系统定期测试的建议和经验。

如今美国已经整体步入夏季，这意味着我们企业中的IT系统随时可能在刹那间遭受飓风、龙卷风、洪水、森林火灾、剧烈的雷暴以及其它各种自然灾害的袭击。

考虑到上述情况，相信大家一定都已经为自己的企业IT系统及关键性企业应用准备了灾难恢复方案。然而，这些方案只能说是防范措施的基础。

上述体系一旦搭建完成，只需轻按一个开关，我们就能在必要时从异地数据中心处托管自己的关键性应用程序备份。然而要保证其正常工作，必要的维护、更新及定期测试绝对不能缺少。因为只有这样，灾备体系才能在灾难来临时真正成为积极可靠的安全后盾。

对于多数IT机构来说，往往压根不做这类测试。事实上如果没有按计划严格执行的审查及测试，灾难恢复体系本身就是一颗蠢蠢欲动的定时炸弹。

没做过测试，一切都是浮云

“我理解对于机构来说，随便凑过去按下开关将正在运行产品的服务器关闭这种状况听起来有多可怕。不过在进行灾备机制检测时，这是必要的一环。”Daniel M.Kusnetzky说道。他是Kusnetzky集团有限责任公司的首席分析师。“其实一套从未进行过测试的灾备系统才是企业最危险的敌人。”

测试整套体系最重要的原因是，Kusnetzky说，一旦设备并未如预期般运作，那么立即着手处理问题总比到了电力真的中断时才干着急要好。毕竟进行测试时我们的技术支持团队能提供在线指导、整套业务系统也并未真正面临自然灾害。

IT专职人员必须能在紧要关头为关键性业务应用的上线及运行、包括这些应用所必需的一切连接系统提供保障，Kusnetzky说道。“这不仅涉及到应用程序，同时还要考虑支持这类应用运行所必不可少的完整配置。如果这些条件不能保证，我们恐怕就必须对进程或是应用程序本身进行重新配置。”

而要想检验上述设置是否按既定方针实施，惟一的方法就是进行测试。测试、调整、再测试，灾备体系必须通过这种流程加以完善，他说。

“仅仅将应用程序复制到别处并尝试启用，这种无意义的做法不会为企业中的员工带来任何实质性的帮助，”Kusnetzky如是说。

在这方面，虚拟化技术能够帮上大忙，因为如果工作负载实际是运行在一套或多套虚拟机上的，那么这些负载就能够良好地适应我们在灾难恢复策略中所预留的后备硬件设备，Kusnetzky指出。基于同样的原因，使用虚拟存储技术也是有所助益的。

与此同时，虚拟化也要被客观看待，它无法解决灾备方案中的全部问题。“虚拟化帮得上忙，但与其它各种技术一样，它也不是万能的。”他说。“它只是种工具。我们需要同时引入其它技术协同作战。”

测试方式的选择非常关键

Gabriel咨询集团的一位分析师Dan Olds在谈及灾备时表示，灾备机制测试方式的选择非常关键。他认为最好的办法是每次对企业内部的单独一套系统进行测试，这样不仅达到了预期目的，更可以尽量减少对IT人员及公司日常工作的影响。

“这不仅是为了保证紧急情况下能够正常工作而对你的（灾难恢复服务）供应商进行测试，这个过程同时也能够让企业中的员工切身了解具体的操作流程，”Olds说道。“有了这样的知识及经验储备，意外发生时大家就不会惊慌失措了。事实上灾备体系的使用过程应该是舒适自然的，而且以这样的状态进行操作也的确能使其发挥更好的保障效果。通过体验我们会认清启动灾备不需要像与时间赛跑那样搏命，也不存在洪水持续上涨那种不成功便成仁的紧迫感。”

通常情况下，这种注重细节的测试并不该由客户来进行，当然干脆不做就更不可取了。“我要对这些应用程序进行测试；我必须有胆量着手进行。大家要给自己这样的信念。”

Olds强调，请务必留心冗余性与可用性之间的差异，这在涉及到紧急情况下企业数据及应用程序的保障方面至关重要。“我们都希望自己的数据得到全天候的保护，无论遭遇何种恶劣的情况，数据绝不能丢失。当然，轻度损失在所难免，最近半小时的数据无法保障可以理解。”

但我们同时要看到，如果灾难真的来临，并不是所有数据都需要立即恢复访问。那些最重要、最关键的业务信息才是我们在紧急情况下亟需保护的重中之重。

“这就要求我们制定优先次序，”Olds说。“将整套基础设施完全制作成镜像，虽然可以保证立即恢复每一个应用程序，但这种做法无疑是愚蠢的，且带来的成本既高昂又不必要。绝大多数企业根本不需要这种级别的可用性。”

排布优先级的方式之一，是为那些在紧急情况下会最先被用到的业务应用及数据制作名单，恢复时即从名单上的项目入手。而其它那些相对将要的应用程序及数据则可以在灾难过后慢慢恢复。

同时，在制订这些规划时也别忘了从企业内部听取不同的声音。“IT部门负责人需要确认自己名单上的项目确实是最关键、最需要及时恢复的业务内容，”他说。“我们必须确保IT人员的想法能够得到业务部门人员的认可和支持。”

通过对应急预案进行定期测试，我们能够确保全部关键性内容都涵盖其中而没有遗漏，例如网络拓扑细节及公司的IP地址等。“这都是我们无需论证就必须保护好的重要信息，”Olds说道。“大家必须竭尽所能将其全部导入镜像，以便在服务中断时能够借助企业外部的基础设施使其尽快重新运作。而如果企业中的数据中心被洪水吞没，那么这种灾备预案还要具备一定的可持续性。”

一旦大家开始进行测试，一定记得将这种良好的习惯坚持下去，尤其是应用程序或基础设施出现变动时。原因很简单：我们必须确保系统方面的定期变动不会与现有的灾难恢复系统相冲突，并进而导致紧要关头失去保护作用。

“我们要时刻提醒自己，能够通过正确的数据及其它相关因素将应用程序恢复到灾前状态才是我们建立灾备机制的根本目的，”他说道。“目的清晰是关键。我建议大家在应用程序更新过程中添加检查对话框，这样一来就能及时了解应用程序或系统的变更是否会对相关备份恢复计划产生影响。一切按计划进行是我们的终极目标，因此上述类型的变化都应详细加以记录并不断检查，以确保整套体系运行良好。”

缺少了测试，这样的灾难恢复规划就是不完整的，并且很可能在需要的时候起不到应有的作用——这就违背了当初我们部署该系统的初衷了。