灾难恢复：你准备好了吗？

申请免费试用、咨询电话：400-8352-114

2004年7月5日，星期一，人们在度过一个愉快的周末后陆续进入这座位于费城最高的大楼准备开始一周的工作，楼内突然发生了停电故障。如果事情就此打住，人们也不必担心，因为灾难恢复专家们早就考虑到了这一点——大楼还有连接到另一电网的线路。但糟糕的是，维修中抢修人员无意中又弄断了这条备用线路。

Glenmede信托公司总部位于这幢大楼内，占据着其中的四层。其首席技术官Nick Voutsakis说：“每场灾难各不相同，所以没人能够准确地预测。你的规划一定要非常灵活，以便应对不测。”

像上面这样的事件让企业有机会看到部署的灾难恢复技术发挥作用。虽然有些公司效果非常好，但更多的公司计划不够全面、不合实际、技术上有缺陷。那么，哪些是经实践证明切实可行的最佳策略呢？应当部署哪些东西？IT部门又应当如何与整个组织合作，以便采取所有必要的防范措施？

“如果灾难恢复计划没有经过测试或者测试力度不够，企业最终会发现，它们受到的保护并不如想象的那么到位，”Mike Karp说，他是科罗拉多州博耳德的调研公司企业管理合伙公司的分析师。

防患于未然

一些灾难恢复计划过于简化，与现实并不相符，所以一旦遇到紧急事件，派不上多大用场。还有些计划过于复杂，没人能看得懂。Voutsakis认为，关键就在于找到平衡点。

但即便公司精心拟订了计划，如果需要实施，没有人能找得到，照样是一无用处。如果不知道计划放在活页夹的何处，或者放在因故障而停机的PC当中，同样是无济于事。所以，要把计划副本放在多个地方。Voutsakis说：“我们把计划副本连同食物、药品和手电筒等东西一起放在应急包里，发给员工。”

Glenmede公司主要采用Windows 2000/XP，使用思科公司的交换机和戴尔公司的服务器和桌面机。其灾难恢复计划分好几层，具体视情形而定：如果员工因为下大雪而无法上班，服务器会在总部继续运行，员工可以安全地在家办公。如果大楼停电，城市另一头的“热备份站点”可以在四个小时之内让关键系统启动起来。运营该站点的是Glenmede的业务连续性部门和外包提供商：SunGard公司，由SunGard数据系统公司的一个部门具体负责。如果灾难让员工无法来大楼上班长达一周，SunGard处备用的桌面机可以供重要员工使用。

独立日周末发生停电期间，Glenmede的管理人员在上午7：30宣布紧急事件。因为所有数据都复制到了热备份站点，该公司得以在11：30之前恢复了所有系统的运行。但大功告成需要一台运转顺畅的机器，这台机器就是团队合作。

康涅狄格州斯坦福的Gartner公司的分析师 Roberta Witty忠告：“应当制订业务连续性计划，专门成立两到五人组成的队伍，并得到高层管理人员的支持。”

Glenmede的灾难恢复基层委员会包括CTO、服务部门主管、风险管理人员以及IT审查委员会成员。该委员会进而任命20个经营部门的代表成立一个业务连续性小组。这些人受过业务连续性方面的培训，负责拟订计划，与经营部门合作。两个委员会的会计记录都要送交Glenmede的董事会。

每个经营部门都要评估自己的流程和需求。在Members集团公司——这家总部设在爱荷华州西得梅因的公司为信用合作社提供信用卡受理和抵押贷款等服务，恢复窗口因部门和时间的不同而大不相同。

Members集团公司的CIO Jeff Russell说：“你要与经营部门合作，这样才能充分了解每个应用背后的驱动因素。单单一名IT人员是不可能认识到每个部门的特定需求的。Members集团使用StoneFly Replicator，来保管存放在远地的关键数据的镜像。这个基于IP存储区域网络（SAN）的异步灾难恢复产品由总部设在圣迭戈的StoneFly Networks公司提供。”
　　
灾难恢复有哪些前沿技术

虽然人们对前沿技术有哪些莫衷一是，但专家一致认为，群集、SAN镜像和复制等应该属于前沿技术。不过专家们警告说，这些技术价格不菲。

在操作系统当中，OpenVMS和Unix比其他系统更受到青睐。譬如说，Alpha/OpenVMS就有内置的群集技术，许多公司用来对站点之间的数据进行镜像。许多金融机构依靠基于VMS的镜像机制来保护担当重任的交易处理系统，其中包括德国商业银行、国际证券交易所和德国证券交易所。

进行股票和衍生工具交易的德国证券交易所就在相距5公里的两个站点部署了OpenVMS群集。它还在网络中使用了总部设在圣何塞的博科通信系统公司的光纤通道交换机，以及思科的交换机和路由器，以确保高可用性。

“灾难恢复不单单涉及冷备份或者热备份，而是不管发生什么情况，都能确保数据随时可用，”德国证券交易所的系统和网络支持部门主管Michael Gruth说。“这就需要两个站点都要有群集技术。”

至于Windows方面，争议比较多。Nickolett说：“虽然我们恢复Unix系统从未失过手，但Windows就不一样了。常见问题包括：恢复失败、软件有冲突以及补丁或者服务包存在问题。”纽约的福布斯网站公司也偏向于Windows之外的平台。在每个工作日，该公司在网上要发布1500多篇文章，大量使用运行在Intel/Linux平台上的广告工作流系统，以及放在运行Sun Solaris的高端富士通服务器的内容管理系统。两个系统都使用Revivio公司的连续保护系统（Continuous Protection System）加以保护。千兆以太网线路使用基于主机的镜像技术，连接到一个不知名的数据中心。福布斯网站负责运营的总经理Michael Smith说：“万一主系统出现了问题，我们就能够切换到该设备上。”

但不是所有人都认为应当避免使用Windows。实际上，圣安东尼奥的癌症治疗和研究中心（CTRC）就大胆地使用微软、EMC和思科的工具用于基于主机的镜像技术。在这家医学中心，21台服务器——主要是Windows 2000/2003，外加几台Linux服务——把数据保存在EMC Clariion FC4700存储阵列上。两个思科SN 5428 iSCSI路由器和一个思科MDS 9506交换机通过千兆以太网网络，把数据和大容量图像文件镜像到远在22英里之外的研究中心的另一个Clariion阵列上。据CTRC的CTO Mike Luter声称，要恢复停机的服务器只要10分钟。

Luter说：“对我们而言，业务连续性远比灾难恢复重要得多。我们希望可以随时使用应用软件为治疗病人提供帮助。如果我们没法使用大楼，而要在其他地方治疗病人，我们需要的就不仅仅是几个计算机系统。”

重在测试

最好的技术和最到位的规划，许多公司认为在灾难恢复方面已经做得足够多了，但这还远远不够。为了防备实际灾难，需要大量的测试。佛罗里达州克利尔沃特的业务连续性顾问John Glenn说：“常见的错误就是，没有坚持进行测试，找出并纠正计划存在的缺陷。”

Glenn说，这并不是说让IT管理员在周末一个人“不断试验”计划。你应当在星期天让所有系统停止运行，看看远地的运作是不是如同预期。并且请来十几名员工，进行实际测试，看看经营部门会受到怎样的影响，财务部门可以继续核算吗？销售人员可以继续销售吗？生产部门可以继续生成产品吗？福布斯公司的Smith提议，还要在工作时间进行几次出奇不意的随机测试。

Glenmede的Voutsakis说：“我们对整个计划每年测试七次。我们评估遭遇不同程度的灾难和各种事件下的运行状况，包括让员工回家办公，看看在家办公效果如何。”他说，真正遇到灾难后可能让公司陷入瘫痪的问题只有在实际测试当中才会出现。

Members集团就遇到过这种情况。它原以为有足够带宽进行异地复制。但事实上其T1线路无力胜任。比如，该公司的SQL数据库就无法有效复制，原因是带宽受到限制，于是无法传输到IP SAN。同样，该公司的服务器有一半以上仍没有进行镜像处理。Russell说：“我们将在不久搬迁，到时会增加更多带宽。”

来源：CCW