天堂和地狱永远只有一墙之隔。当企业因为信息化带来快捷的服务决策和方便管理时，也必须面对数据丢失的危险。

　　泰坦是一家电信服务商。至于为什么起了这个名字，CEO倪克自有一套想法。虽然历史上最豪华的巨轮泰坦尼克沉没在冰冷的北大西洋，但是我们要取其精华，弃之糟粕。我们也要做巨人，但是我们将把好每一关，我们的泰坦不会沉没。

　　然而，计划总是不如变化快，人算总是赶不上天算……

　　第一次沉没的理由 病毒

　　泰坦从创立开始，已经有3年的时间了。3年来，用户群飞速增长，业务不断扩大，呈现一片繁荣的景象。CEO倪克虽然时不时成为空中飞人，忙得不着家，惹得妻小埋怨，但心里还是很欣喜。

　　存好是一家做容灾解决方案的IT厂商。存好的CEO吴忧很早就认识倪克。看泰坦业务迅速发展，但没有任何灾备措施，吴忧就找到倪克说，作为一个电信服务商，数据对于泰坦来说非常重要。泰坦要上一套容灾系统来保护自己的关键数据。正在春风得意的倪克随口问了问报价，一听到那么高的费用，倪克就不愿意了，一句“吉人自有天相”把吴忧挡了回去。

　　然而天有不测风云。2003年的3月8日，对于泰坦来说，简直是个黑色的日子。早上10点，泰坦主服务器由于病毒侵入，发生近两个小时的故障，尽管网管员拼命抢修，仍然造成业务、用户、经营数据的大量丢失，其中包括近一年来企业用户的电话费用统计。没有了数据自然无法讨回所欠费用，最后算下来，造成近400多万元的损失。除此之外，在系统发生故障维修的时间内，很多用户都受到影响无法正常办公，有用户急得几分钟来一个电话，怨声一片。灾难远没有结束。事故发生后，许多用户开始对泰坦失去信任，泰坦因此流失很多用户。

　　倪克非常困惑：企业平时非常重视安全问题，也建立了牢固的防火墙和企业版杀毒软件，对工作人员的要求也很严格----为防止病毒干扰，规定工作机不能上网等，可是，病毒怎么还是入侵了呢?

　　任何东西都不是万能的，防火墙和杀毒软件并不是永远固若金汤。况且，再小心谨慎也不可避免会发生各种各样的灾难。除了病毒以外，系统硬件和网络故障、机房断电等，这些灾害也不是仅仅小心就可以避免的。

　　假如有一套备份的数据，损失就不会这么巨大了。倪克那个后悔啊。颓然了几天之后，倪克规定员工对重要数据一定要进行拷贝。但是，由于泰坦数据量巨大并处于变化中，要及时存储数据占用大量时间和磁带等存储资源，而且不太可能做得及时。CIO陈默陆续走访了其他电信和银行企业，发现有些企业有一套专用的容灾系统，备份与容灾所关注的对象有所不同，备份关系数据的安全，容灾关心业务应用的安全，备份是“数据保护”，而容灾称作“业务应用保护”。备份最多表现为通过备份软件使用磁带机或者磁带库将数据进行拷贝，也可以使用磁盘、光盘作为存储介质;容灾则表现为通过高可用方案将两个站点连接起来。陈默向倪克汇报了其他企业在发生灾难时的措施之后，倪克终于下决心，要给泰坦进行容灾保护。

　　找谁来建呢?泰坦不想自己承担，一是没那个人力，二是精力也不足。所以陈默主动找到吴忧，两人这次是一拍即合。

　　2003年8月，泰坦开始建自己的灾备系统。陈默在离办公大楼不远的地方建了一个机房作为容灾中心。这时的泰坦对灾备系统的要求比较简单：灾难发生后，重要数据可以恢复就行。存好公司承担了其灾备系统的建设任务。根据泰坦的要求，存好为其建设数据级容灾系统以对其数据进行保护。

　　泰坦数据级容灾采用三级备份，第一是数据的热备份，即采用复制软件实现源数据和目标数据实时同步。每次数据更新操作，同时在生产中心和灾备中心进行。第二是数据的冷备份。任何技术都会有其自身的局限性，复制软件可以实现高水平数据保护，发生链路故障或主阵列/辅助阵列处于不可达状态或遭自然或机械灾害损坏时，能够保护数据并及时实现再同步。但是，如果由于源数据的合法操作而导致数据库的失效、无法识别，目标数据的数据库将同样失效。因此，泰坦对数据源采取了数据的冷备份，每周六夜间进行定时的增量备份。该方案提供了人为和应用错误的数据保护。第三是数据的暖备份，即数据库复制技术。完整的数据拷贝保持在灾备中心，更新日志定期由生产中心经由网络传送到灾备中心。

　　数据容灾建成了，虽然3月份的那次病毒入侵还历历在目，不过，倪克相信这回可以高枕无忧了。

　　第二次沉没的理由火灾

　　就像是老天有意要考验泰坦的容灾一样，泰坦的数据容灾系统建成后，陆续出了几次小事故，一次是服务器突然宕机，还有一次工作人员操作失误将数据删除，启动容灾系统后都基本在24小时内恢复了。这下，倪克非常得意，钱没白花。为此陈默受到倪克的表扬，不受重视的信息中心增光不少。而且陈默还应邀到多家公司介绍经验。泰坦项目也成为存好公司典型案例而大为推广。

　　一天，陈默在公司楼下的餐厅吃午饭，突然看到外面非常喧闹，很多人惊惶失措地跑来跑去。很快，就有一个人冲进餐厅尖叫，“起火了!”吃饭的人匆匆忙忙丢掉碗筷，跑出餐厅。陈默也跑到外面去看火情。果然，浓浓的黑烟从楼房里面冒出来。不过，这一次的陈默并不是很担心。他有能力让公司的IT系统重新运转起来。陈默甚至认为大火又给了他表现的机会。

　　消防队来了，大火终于扑灭了。陈默发现，尽管数据在容灾中心完好无损，但是他要重新搭建系统，然后再重新把数据导入到新建的系统中。经过三天三夜的奋战，系统终于恢复了正常工作。而在这三天中，泰坦公司的竞争对手推出优惠促销活动，泰坦六成的客户都投到对手门下。倪克也差点愁白了头。

　　经过这场事故，泰坦公司大伤元气。但是万幸的是，凭借这几年电信业的快速发展，泰坦公司积累丰厚而没有彻底破产。倪克下了死命令，要求泰坦的容灾中心要在任何情况下，可以让系统在12小时内恢复工作。

　　陈默再次找来吴忧。吴忧听完陈默的诉苦之后，给陈默指出一条出路----应用级容灾。

　　在容灾建设中，两个关键的指标是RTO(Recovery Time Objective ，使系统恢复所需要时间)和RPO(Recovery Point Objective，可接受的数据损失程度)。其中RPO代表了当灾难发生时允许丢失的数据量，而RTO则代表了系统恢复的时间。倪克要求在12小时内恢复系统，其实就是对RTO的要求。不同级别的容灾系统有不同的RTO和RPO。数据级别的RTO大于24小时，而应用级别的RTO小于24小时。

　　泰坦原来建的只是数据级别容灾。这个级别的容灾系统能够满足企业对RPO的要求。 但是该级别灾难恢复时间较长，尽管用户原有数据没有丢失，但是应用会被中断，用户业务也被迫停止。

　　对于系统需要保持7×24小时连续运行的企业来说，需要高级别的应用容灾系统来满足他们的需求。应用级容灾是在数据级容灾的基础上，不仅把数据复制了一份，而且把应用处理能力也复制了一份。应用级容灾系统可以使企业的多种应用在灾难发生时进行快速切换，确保业务的连续性。

　　容灾的级别越高，RPO与RTO越小，但是用户需要的投资也越大，业务恢复及操作流程也更复杂，投资成本和维护成本也要增加。

　　听到这里，陈默犹豫了。建设更高级别的容灾看起来很好，但到底是不是值得呢?泰坦一定要上成本高昂的应用级的容灾吗?

　　吴忧说，这就需要根据业务间断对企业造成的损失来判断应该用什么级别的容灾系统。在泰坦公司还比较小的时候，相对于应用级容灾的投资，中断一天的业务造成的损失还不算很大，因此数据级别容灾也就够了。但泰坦不断在发展，中断单位时间的业务系统造成的损失增加了，业务中断三天让泰坦损失了百分之六十的客户。这时应用级别容灾的投资就是值得的了。

　　陈默不敢擅作主张。他把以上情况写了一个可行性报告递交倪克。成本的确是很高，但想到三天损失六成的客户，倪克就没有什么可犹豫的了。他拍板，泰坦要建应用级别容灾系统，要实现12小时系统恢复。

　　第三次沉没的理由 地震

　　在原来数据级别的容灾中心基础上，泰坦建设了应用级容灾中心。陈默自得了相当一段时间。作为一个中等规模的电信行业厂商，在短期内建了一套比较高端的容灾系统，而且运行起来很顺利，泰坦没有理由不满足。这不，泰坦还找了部分媒体，专程来报道自家的容灾系统。

　　这个周末的晚上，已经连续阴了好多天的城市，又下起了大雨，外加闪电、雷鸣、大风。冬天怎么还打雷?陈默虽然嘀咕了一声，但也不以为意。有暖气的房间里还是春意融融。陈默再一次捧起报道泰坦容灾的报纸，端着一杯香浓的哥伦比亚咖啡，准备再研读研读。突然，放在桌子上的水晶花瓶倒下来，滚到地上摔个粉碎。还没来得及心疼，正弯下腰准备检视瓶子现状的陈默听到一种奇怪的声音，一种振动的声音，由远及近，由小变大，再定睛一看，身边的桌子、椅子都在振动，而且频率越来越快，衣柜门自己打开了，里面的东西都被抛了出来，放在高处的东西丁丁咣咣往下掉，灯光忽明忽暗。楼外开始喧嚣，有人在惊恐地喊：地震了!地震了!

　　脑子里嗡的一声，陈默穿上外衣就往空旷的地方跑。一个念头飞速掠过，我的数据，我的容灾设备……但此时，陈默什么也顾不上了。等到震波过去，风平浪静，陈默穿过到处是废墟的街道赶到公司。最糟糕的事情果然发生了。

　　很多地方倒塌，容灾中心一片狼藉。光缆断了，网断了，主机显然被破坏了，那套昂贵的容灾系统不但没有救灾，反而自身受灾。

　　陈默站在废墟前，脑子里一片空白。又一次数据丢失、系统瘫痪，泰坦的业务怎么办?难道这一次泰坦真要倒下了吗?

　　怀着一丝侥幸，陈默马上通知存好进行系统修复，希望能挽回数据，减少损失。经过连续几天几夜的修复，存好公司告诉陈默，系统受损不是很严重，数据大部分可以恢复。这个消息让陈默喜出望外，大大松了一口气。

　　但是惊魂未定的倪克还是不踏实。他和陈默一起，亲自找来吴忧，想了解到底怎样，泰坦的业务才能真正安全。

　　吴忧再一次侃侃而谈。在系统设计中，企业一般会考虑做数据备份和采用主机集群的结构，因为它们能解决本地数据的安全性和可用性。这是针对慢性容灾的本地解决方案，如果当某台主机出现故障，不能正常工作时，其他的主机可以替代该主机，继续进行正常的工作。目前人们所注意到的容灾，大部分也都只是停留在本地容灾的层面上。但对某些地区的某类企业来讲，光有本地容灾是远远不够的。其关键业务应用，必须要防范地震、洪水、战争等自然灾难。因此应该采用异地容灾的保护措施。一套完整的容灾方案应该包括本地容灾和异地容灾两套系统。

　　远程容灾系统具备应付各种灾难特别是区域性与毁灭性灾难的能力，具备较为完善的数据保护与灾难恢复功能，保证灾难降临时数据的完整性及业务的连续性，并在最短时间内恢复业务系统的正常运行，将损失降到最小。其系统一般由生产系统、可接替运行的后备系统、数据备份系统、备用通信线路等部分组成。在正常生产和数据备份状态下，生产系统向备份系统传送需备份的数据。灾难发生后，当系统处于灾难恢复状态时，备份系统将接替生产系统继续运行。此时重要营业终端用户将从生产主机切换到备份中心主机，继续对外营业。

　　这种备份目前分为两种形式，一种是历史备份，一般采用每天凌晨备份的形式，出现问题可以恢复一天前的数据。如果对数据要求不是很高的话，可以采用三天，甚至一周备份的方式，可以节约很多成本。

　　那么我们泰坦要选择多远的距离来搭建异地容灾系统?几公里?几十公里?还是几千公里?陈默还是不太明白。

　　吴忧说，这就需要根据企业自身状况来定了。同样是容灾系统，如果容灾的目标只是在城市中防范火灾等较低级别的灾难事件，那么存储在与应用地距离几公里的地方就能较好地满足要求。如果是防水灾，则要求它们之间的距离在数公里以上。如果是预防地震，则需要保持几百公里的距离。基本来说，数据存储距离与应用地越远，容灾性也就越强，100公里以上的异地灾难备份将是未来的一种趋势。只要IP可达，并且网络带宽足够，数据不再惧怕自然灾害。吴忧总结道。

　　还在对刚刚结束的地震痛定思痛的倪克听完之后当场拍板，泰坦也要建异地容灾系统，而且地点要选得远一点，就在南方的沿海城市C城。隔着几百公里，这下总安全了吧?

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。