IBM容灾白皮书5篇范文

第一篇：IBM容灾白皮书

IBM的容灾白皮书 内容简介

随着时代的发展，人类对于灾难的防范意识和要求越来越高。灾难的概念范畴非常广泛，本书针对于企业环境，对业界当前讨论的热门话题--IT容灾系统的概念和实现方法及设计流程做了深入浅出的分析，并从多个层面介绍了相应的解决方案。希望读者通过本书可以加深对于容灾系统的理解，对设计出一个切实可行的容灾系统能够有所帮助。

第一章 信息—企业的财富与麻烦

前言

1.1 IT大集中 － 把蛋都装进篮子里

1.2 容灾－覆巢之下，亦有完卵

第二章 容灾概述

2.1 概述

2.2 容灾的实质是确保永不停顿的业务运营

2.3 容灾的IT实现

第三章容灾方案分析

3.1 业务连续性开发模式

3.2 七层灾难恢复解决方案

3.3 如何选择最优的灾难恢复方案

第四章 容灾系统的设计过程

4.1 灾难恢复计划描述

4.2 灾难恢复计划项目阶段

4.3 数据收集和关键需求分析阶段

4.4 风险分析阶段

4.5 数据保护阶段

4.6 恢复阶段

4.7 测试和培训阶段

4.8 维护和修改阶段

4.9 选择灾难恢复方案的步骤介绍

第五章 典型方案介绍

5.1 基于软件的数据备份技术

5.2 HACMP高可靠性灾备方案

5.3 基于磁盘系统的PPRC数据级灾难备份解决方案

附录A.容灾方案演示环境

6.1 基于磁盘系统的PPRC数据级灾难备份解决方案典型应用环境

附录B.术语

第一章 企业面临的挑战以及发展趋势

1.1前言

1958年，Bill Gore 和他的太太 Vieve Gore在美国特拉华州Newark市，自己家里的地下室成立了Gore公司。1969年，Gore公司研制成功独特的，具有防风、防水、透气功能的GORE-TEX面料并广泛应用于生产具有功能性、保护性和时尚感的服装和鞋类产品。目前，Gore公司已成为一家在全球拥有6000多名员工、40多间加工厂的跨国公司，并在氟材料的技术研究和应用领域始终占据世界领先地位。

对于Gore这样的以研发新型材料作为企业动力的公司而言，材料的研发过程记录、研发历史数据、研发结果数据是企业最可宝贵的财富。请假设这样一种情况，如果这些数据在一次事故中全部丢失，Gore公司会蒙受多么大的损失？

1983年，当个人电脑还处于萌芽期的时候，美国青年戴尔成立了自己的个人电脑公司，主要销售IBM的旧电脑和自己组装的品牌电脑。那是一个电脑群雄激烈厮杀的年代，当行业的领导者们争相以引人注目的技术推出计算机时，戴尔注意到了平凡的供应链。戴尔公司利用信息技术全面管理公司生产过程。通过互联网，戴尔公司和其上游的配件制造商能够对客户的定单迅速地做出反应：当定单传至戴尔的控制中心时，控制中心把定单分解为一个个子任务，并通过网络分派给各独立配件制造商进行生产。各制造商按照戴尔的电子定单进行生产组装，并按照戴尔控制中心的时间表来供货。戴尔所需要做的只是在成品车间完成组装和系统测试，剩下的就是客户服务中心的事情了。―经过优化后，戴尔供应链每20秒钟汇集一次定单‖，―平均库存时间仅有7小时‖。虽然没有傲视群雄的杰出技术，现在的戴尔公司却已成长为一个年销售额达410亿美金的企业。

对戴尔公司来说，市场信息的获取、物流信息的传递以及合作伙伴的信息交换，这些共同构成了拉动企业正常运转的信息链。如果有一天，一场意外的事故导致供应链的崩裂，戴尔该如何面对客户恼怒的面容和企业直线下滑的利润？

信息，作为企业宝贵的资源，其重要性已经得到了人们的充分认识。但是我们该如何保护这一资源？假设您就是某企业的一位高级管理人员，当您的企业遭遇以下事故时，您将如何去面对： 1． 某一天，证券公司的交易数据因操作失误而损坏； 2． 某一天，保险公司的所有保单数据因电源故障而丢失；

3． 石油勘探公司辛苦一年获取的地质数据因人为的恶意操作而丢失； 4． 医院保存的所有病历因为磁带的损坏而无法使用； ……

这样的例子还有很多很多。那么这样的事故所带来的后果是什么？至少，很难想象这个不幸的企业还能毫发无损的健康生存。因为，对于信息时代的企业而言，健全的信息往往是维持其运转所必须的基本条件。所以，如何保护企业的信息资源，如何使企业免遭信息灾难，已经成为企业所必须考虑的沉重问题。

1.2 IT大集中 － 把蛋都装进篮子里

在计算机应用的早期，是大型主机一统天下的时代。这是一种高度集中的信息应用模式。昂贵的计算机和同样昂贵的存储设备躲藏在幽深的机房里，客户仅能依靠哑终端与主机进行交互，以完成自己的工作。

随着IT设备的降价和网络技术的发展，客户机/服务器体系结构和浏览器/服务器体系结构这样的信息应用模式应运而生。这两种全新的信息应用模式，降低了用户进入计算机应用系统的门槛，推进了计算机应用在现代社会的全面普及，并产生了今天计算机应用分布式存在和数据存储分布式存在的局面。

合久必分，分久必合。随着网络速度的进一步提高以及高速存储设备的降价，高速信息交换、大容量存储等困扰IT人员多年的问题基本得到了解决。同时，过于分布的应用和数据所导致的日益昂贵的维护和运营费用，已经给大型企业的发展带来了束缚。于是，大集中的号角重新吹响。

目前，在银行信息化领域，数据大集中已经成了一个热门的话题。在国内，中国工商银行在2000年就前瞻性地启动了数据大集中工程，并在2002年完成了全部工程的建设。现在，中国工商银行已经将分布在全国各地的四十多个数据中心整合为互相连接、互为备份的北京、上海两大数据中心，建成了全行统一的计算机系统平台。同时，国内的其它银行和大型证券公司也纷纷迎头赶上。大集中已经成为包括银行、证券、保险等行业在内的整个金融信息化发展的大趋势。

鉴于信息资源对于企业的宝贵作用，我们不妨把它们比作一枚枚金蛋，而信息基础设施就是用来装这些金蛋的篮子。过去，不同的金蛋分布在不同地域的篮子里，而大集中所带来的信息基础设施整合则意味着我们将把越来越多的金蛋放进同一个篮子。此刻，一个不得不考虑的问题出现了：如果这个篮子翻了，怎么办？覆巢之下，岂有完卵？

1.3 容灾－覆巢之下，亦有完卵

2001年9月11日，美国世贸中心双子大厦遭受了谁也无法预料的恐怖打击。灾难发生前，约有350家企业在世贸大厦中工作。事故发生一年后，重返世贸大厦的企业变成了150家，有200家企业由于重要信息系统的破坏，关键数据的丢失而永远的关闭、消失了。其中的一家公司称，自己要恢复到灾难前的状态需要50年的时间。

2003年，当AT＆T无线试图对Siebel客户关系管理（CRM）软件进行升级的时候，原定一个周末就能完成的项目演变为一场历时六个星期的灾难。这次CRM软件的升级使AT＆T无线损失了1亿多美元，仅增加的用户欠款、员工加班费和承包商的佣金就高达7500万美元。此外，技术故障也导致该公司去年第四季度的新增用户数急降82％。而其损失并不仅限于这些，AT＆T无线对分析师发布警告称：―2004年上半年的用户退网率将进一步增加。‖ 2003年，国内某电信运营商的计费存储系统仅发生了两个小时的故障，就造成400多万元的损失。这些尚不包括对公司声誉的影响所导致的无形资产流失。

这些灾难的发生或许是偶然而难以预料的，但是，对灾难的预防却绝对不应该是一个偶然的话题。

据IDC的统计数字表明，美国在2000年以前的10年间发生过灾难的公司中，有55%当时倒闭。剩下的45%中，因为数据丢失，有29%也在两年之内倒闭，生存下来的仅占16%。国际调查机构Gartner Group的数据表明，在由于经历大型灾难而导致系统停运的公司中，有2/5再也没有恢复运营，剩下的公司中也有1/3在两年内破产。

美国德克萨斯州大学的调查显示：―只有6%的公司可以在数据丢失后生存下来，43%的公司会彻底关门，51%的公司会在两年之内消失。‖

另一份针对这一课题的研究报告也显示：在灾难之后，如果无法在14天内恢复信息作业，有75%的公司业务会完全停顿，43%的公司再也无法重新开业，20%的企业在两年之内被迫宣告破产。

美国明尼苏达大学的研究也表明，在遭遇灾难的同时又没有灾难恢复计划的企业中，将有超过60%在两到三年后退出市场。而随着企业对数据处理依赖程度的递增，此比例还有上升的趋势。

灾难的发生对企业的打击往往是致命的。但是，面对灾难，企业就真的不堪一击吗？

答案是否定的！

同样是令人恐怖的―9.11‖，世贸大厦倒塌后，在世贸大厦租有25层的金融界巨头摩根斯坦利公司最为世人所关注。但是事发几个小时后，该公司宣布：全球营业部可以在第二天照常工作。这都是因为该公司建立的数据备份和远程容灾系统，它们保护了公司的重要数据，在关键时刻挽救了摩根斯坦利，同时也在一定程度上挽救了全球的金融行业。

这一独特的例子说明了什么？它说明拥有先知先觉的防范意识和充分的技术准备，即使是在突如其来的覆巢之灾下，亦有完卵，亦有企业的一线生机。

因此，预防灾难的发生，充分考虑灾难发生后的快速恢复手段，成为现代企业的一门必修课。其实，在这一问题上，中国古代的智者早就提出了自己的观点：生于忧患，死于安乐。无论是对一个国家，还是一个企业，都是如此。第二章 容灾概述

2.1 概述

常言道，―知己知彼，百战不殆‖。要实现容灾，首先要了解我们的―敌人‖－ 灾难。那么，哪些事件可以定义为灾难呢？典型的灾难事件是自然灾难，如火灾、洪水、地震、飓风、龙卷风、台风等，还有其它如原先提供给业务运营所需的服务中断，如设备故障、软件错误、电信网络中断和电力故障等等。此外，人为的因素往往也会酿成大祸，如操作员错误、破坏、植入有害代码和恐怖袭击。现阶段，由于我国很多行业正处在高速发展的阶段，很多生产流程和制度仍不完善，加之缺乏经验，这方面的损失屡见不鲜。事实上，我国2003年遭遇的―非典‖，某种意义上也是灾难。对此，我们认为需要做到两点：一是建立切实可行的应急机制，这主要包含一套基于充分且清楚地将风险予以分类定义的业务持续计划，二是在危机突然降临时，此计划能被有效执行。

对于IT系统，除了上述的灾难之外，与系统相关的计划外宕机也可视作灾难（见图1）。

图1.停机原因分析－北美

自―9.11‖之后，全球各企业均认识到灾难防范保护的重要性。某些大型金融机构之所以能够在两天内恢复营业，其主要原因是它们不仅象一般公司那样在内部进行数据备份，而且在数英里外的数据备份中心也保留着数据备份。这些备份都是通过数据备份软件和数据复制软件进行的。采取了这种措施后，一旦工作现场发生意外，企业就可以立即使用另一套数据。华尔街的金融机构重新对灾难恢复的步骤做了评估，并认识到灾难恢复只是技术手段之一，它们开始强调 Business Continuity“灾难”恢复。因为过去的“灾难”恢复计划并没有强调全局性及对整个市场的影响，而如何维持业务的连续运作将成为企业运营风险评估中至关重要的一环。事实证明，只有对数据存储备份制定完备、持续且可执行的容灾计划，特别是业务连续计划，才能为人们提供万无一失的数据安全保护。

严格的说，容灾计划包括一系列应急计划，如业务持续计划(BCP-Business Continuity Plan)，业务恢复计划(ERP-Business Recovery Plan)，运行连续性计划(COOP-Continuity of Operations Plan)，事件响应计划(IRP-Incident Response Plan)，场所紧急计划(OEP-Occupant Emergency Plan)，危机通信计划(CCP-Crisis Communication Plan)，灾难恢复计划(DRP-Disaster Recovery Plan)等等。

业务持续计划(BCP)它是一套用来降低组织的重要营运功能遭受未料的中断风险的作业程序，它可能是人工的或系统自动的。业务持续计划是高层管理人员的首要职责，因为他们被委任于保护公司的资产及公司的生存。业务持续计划的目的是使得一个组织及其信息系统在灾难事件发生时仍可以继续运作。为了能对灾难事件有适当的对策，严密的计划及相关资源的投入是必须的。

业务恢复计划(BRP)它也叫业务继续计划，涉及紧急事件后对业务处理的恢复，但与BCP不同，它在整个紧急事件或中断过程中缺乏确保关键处理的连续性的规程。BRP的制定应该与灾难恢复计划及BCP进行协调。BRP应该附加在BCP之后。

操作连续性计划(COOP)COOP 关注位于机构（通常是总部单位）备用站点的关键功能以及这些功能在恢复到正常操作状态之前最多30天的运行。由于COOP涉及到总部级的问题，它和BCP是互相独立制定和执行的。COOP的标准要素包括职权条款、连续性的顺序和关键记录和数据库。由于COOP强调机构在备用站点恢复运行中的能力，所以该计划通常不包括IT运行方面的内容。另外，它不涉及无需重新配置到备用站点的小型危害。但是COOP可以将BCP、BRP和灾难恢复计划作为附录。

危机通信计划(CCP)机构应该在灾难之前做好其内部和外部通信规程的准备工作。危机通信计划通常由负责公共联络的机构制定。危机通信计划规程应该和所有其它计划协调，以确保只有受到批准的内容公之于众，它应该作为附录包含在BCP中。通信计划通常指定特定的人员作为在灾难反应中回答公众问题的唯一发言人。它还可以包括向个人和公众散发状态报告的规程，例如记者招待会的模板。

计划(IRP)事件响应计划建立了处理针对机构的IT系统攻击的规程。这些规程用来协助安全人员对有害的计算机事件进行识别、消减并进行恢复，这些事件的例子包括：对系统或数据的非法访问、拒绝服务攻击、或对硬件、软件、数据的非法更改（如有害逻辑：病毒、蠕虫或木马等）。本计划可以包含在BCP的附录中。

灾难恢复计划(DRP)正如其名字所表示的，DRP应用于重大的、通常是灾难性的、造成长时间无法对正常设施进行访问的事件。通常，DRP指用于紧急事件后在备用站点恢复目标系统、应用或计算机设施运行的IT计划。DRP的范围可能与IT应急计划重叠，但是DRP的范围比较狭窄，它不涉及无需重新配置的小型危害。根据机构的需要，可能会有多个DRP附加在BCP之后。

场所紧急计划(OEP)OEP在可能对人员的安全健康、环境或财产构成威胁的事件发生时，为设施中的人员提供反应规程。OEP在设施级别进行制定，与特定的地理位置和建筑结构有关。设施OEP可以附加在BCP之后，但是独立执行。

BCP关注在中断期间和之后维持机构的业务功能。业务功能的一个可能的例子是工资的支付处理或客户的信息处理。BCP可以专门为某个特定的业务处理编写也可以涉及到所有关键的业务处理。IT系统在BCP中被认为是对于业务处理的支持。在某些情况下，BCP可能没有涉及到对过程的长期恢复并使其回到正常运行状态，而只是包含过渡的业务连续性需求。灾难恢复计划、业务继续计划和场所紧急计划可以附加在BCP之后。在BCP中设定的职责和优先顺序应该和其在操作连续性计划（COOP）中的一致以消除可能的冲突。

按一般惯例，备用站点维持机构（通常是总部）要支持长达30天的运行，直到整个系统恢复到正常状态，COOP正是为了达到这个要求而制定的。BCP涉及到在重大中断期间和之后维持业务处理所需的业务功能和IT系统。BRP记录了机构在备用站点进行业务处理的持续规程。与BCP不同，BRP不涉及在紧急事件期间对关键处理的连续性维持。DRP是指设计用于重大和通常是毁灭性灾难之后的目标系统、应用程序或计算机设施的恢复，它是以IT为主的计划。两个计划都提供了IT系统的恢复和继续规程。由于包括了对无需重新部署到备用站点的小型中断进行系统恢复的规程，所以这类计划比DRP的范围更广泛。计算机事件响应计划建立了使安全人员可以确定、防止和恢复针对机构IT系统进行的计算机攻击的规程。OEP则提供了在人员的健康和安全以及环境或财产等受到威胁的紧急情况下，设施工作人员所遵循的指导方针。计划的制定者之间必须进行协调以确保各自的策略和规程能够互为补充，必须将所有有关计划、系统和处理的变化情况反馈给系统和相应处理计划的制定者。2.2 容灾的实质是确保永不停顿的业务运营

让我们来看一个真实的故事：

Fred Alger基金管理公司的总部设在世贸中心北楼的93层。在上个世纪90年代，Fred Alger曾是美国业绩最好的一家基金管理公司。它旗下的―光谱共同基金‖（Spectra mutual fund）的年均收益率曾达到让人惊羡的29%。然而，公司2000年的业绩大幅下滑，其前景不容乐观。2001年9月11日上午发生恐怖袭击后，该公司正在上班的35人全部遇难，老板David Alger也在其中，这对Fred Alger公司来说无疑是灭顶之灾。

所幸的是，该公司居安思危，在繁荣期建设的IT系统早早就考虑到容灾的需要，在50英里以外的新泽西中心区建有一个数据备份点。―9?11‖过后的第三天，该公司幸存无几的人在那里发现，袭击之前所有的交易记录和所有的研究报告都有详细备份，并被完好无损地保留了下来。

所以，Fred Alger公司没有选择关张，而是决定重建。他们并非盲目地不认输。几年前就已退休的Fred Alger，在弟弟David去世后立刻再度出山。当整个市场在去年9月17日重新开市时，Fred Alger公司成了华尔街经纪公司中的股票大买家。

此后，当其他基金管理公司的业绩在去年出现滑坡时，他们的利润反而因此大大增加。很快，Fred Alger公司的投资管理队伍也空前兴旺起来，并在第五大道的2层楼建立了新的总部。类似的故事令全世界在一夜之间认识到，金融市场的数据备份和交易备份绝对不能缺少。

自美国建国以来，华尔街就一直主宰着美国的金融。而此次袭击已经给了华尔街以致命的一击。事实上，对世贸中心的袭击完全改变了纽约的金融景观。以往，曼哈顿4/5写字楼的底层都是金融服务机构。而如今，这些金融机构中的一半以上都迁走了，大多都换了个小地方。在曼哈顿中心区的5万名金融服务人员中，已有19000名离开了这个城市。其中也有像摩根斯坦利和高盛公司这样的―金融巨人‖。

因此，即使在曼哈顿区还在燃烧时，监管者们已经开始考虑，如何才能重振金融业，并让它强大到足以抵御下一次灾难。在银行家和监管者们看来，―9?11‖并不能被称为信用事件。但下一次灾难，不论是什么样的灾难，它一定会是一场信用事件。在庞大的支付链条上，一旦某个具有实力的环节受到支付困难的威胁，整个市场，如外汇交易或美国财政债券交易就有可能出现大塞车。

为此，英国的金融服务管理局在一个储存有备份数据的秘密地点，进行了多次―业务持续‖演习。美国的监管者也抛出一份建议书。这份建议书的目的在于，要保持市场参与者之间实时的信息和通信联系，即保持数据备份点之间的通信联系。监管者和市场应该能够抵御住沉重的打击，并应在4小时以内恢复工作。而对那些由15～20家大银行和5～10家证券公司所组成的金融主干系统来说，在它们主要参与的市场中应享受优先权，须在一天之内恢复营业。

在―9311‖以前，银行之间（包括独立的通信和信息技术系统之间）的应急计划很少有彼此的沟通。为此，设在巴塞尔的发达国家10国 ―金融稳定性论坛‖，已经起草了一个―应急协议名单‖。被列入这一名单的，都是些全球最重要的金融实体。根据这个协议，名单中的金融实体的监管方可以在任何情况下及时取得联系。

此外，美国监管机构已经提出，要持续不断地进行应急计划测试，以对付―一切可以想象得出的事件‖。例如，进行产业范围的战争预演已经提到议事日程，而―无线战争‖被最先纳入其中。

那么，如何确保企业业务的连续运营以及数据的安全呢？严格的说，业务持续计划的建立和实施过程，实际上是进行一个涉及企业运营的项目，因此也涉及到项目管理的方方面面。标准的业务持续计划项目应按如下流程进行： 1。项目启动和管理

确定业务持续计划（BCP）实施过程的相关需求，包括获得管理支持、以及组织和管理项目使其符合时间和预算的限制要求。2。风险评估和控制

确定可能造成机构及其设施中断的灾难、具有负面影响的事件和周边环境因素，以及事件可能造成的损失、防止或减少潜在损失影响的控制措施，提供成本效益分析以调整控制措施方面的投资，达到消减风险的目的。同时，由于风险会随着系统的发展而变化，所以风险管理过程也必须是动态的。

3。业务影响分析

确定由于中断和预期灾难可能对机构造成的影响，以及用来定量和定性分析这种影响的技术。确定关键功能、恢复优先顺序和相关性以便确定恢复时间。4。制定业务连续性策略

确定和指导备用业务恢复运行策略的选择，以便在恢复时间目标范围内恢复业务和信息技术，并维持机构的关键功能。5。应急响应和运作

制定和实施用于事件响应以及对事件所引起状况进行稳定的规程，包括建立和管理紧急事件运作中心，该中心用于在紧急事件中发布命令。6。制定和实施业务连续性计划

设计、制定和实施业务连续性计划，以便在恢复时间目标范围内完成恢复。7。意识培养和培训项目

准备建立对机构人员进行意识培养和技能培训的项目，以便业务连续性计划能够得到制定、实施、维护和执行。

8。维护和演练业务连续性计划

对预先计划和计划间的协调性进行演练、并评估和记录计划演练的结果。制定维持连续性能力和BCP文档更新状态的方法，使其与机构的策略方向保持一致。通过与适当标准的比较来验证BCP的效率，并使用简明的语言报告验证的结果。9。公共关系和危机通信

制定、协调、评价和演练在危机情况下与媒体交流的计划；制定、协调、评价和演练与员工及其家庭、主要客户、关键供应商、业主／股东以及机构管理层进行沟通和在必要情况下提供心理辅导的计划，确保所有利益群体能够得到所需的信息。10。与公共当局的协调

建立适用的规程和策略，用于同地方当局协调响应、连续性和恢复活动，以确保符合现行的法令和法规。

当然，实际应用中，如果受时间、成本等因素的限制，加之容灾目标有限（企业不需要承担应由政府负责的国计民生之重任），我们可以简化并适当改变上述标准流程。事实上，随着IT系统在企业内部应用的深入，IT系统更容易受到各种灾难的伤害而导致中断，特别是在许多情况下，关键资源可能属于不可控范围（如电力和电信）。对于倚仗IT系统的企业来说，从确保业务连续能力的角度出发，可以依据下列容灾规划步骤：

1． 灾难类型分析 2． 业务冲击分析

3． 当前业务环境及恢复能力分析 4． 容灾策略制订 5． 容灾方案设计 6． 业务连续性流程设计

7． 业务连续性流程及容灾方案管理和测试

每一个步骤的相关职责一般会落在―计划协调人‖或―应急计划制订人‖的身上，他们通常是职能或资源部门的经理。协调人在其他相关系统或业务处理部门的职能经理和资源经理的协助下制定应急策略；应急计划协调人通常管理应急计划的制定和执行。

2.3容灾的IT实现

除了详尽的容灾计划，实际上还需要合理的IT系统架构来确保企业的容灾计划得以实现。对于IT系统而言，在技术层面上，容灾需要考虑：

* 数据版本保护 － 建立容灾的多版本保护底线（Bottom Line）* 实时数据保护 － 数据复制，近乎0的数据丢失，数据一致性

* 应用系统恢复 － 恢复时间（包括数据库恢复）、应用版本的一致性（PTF）等 * 网络系统恢复 － 数据访问点变化、建立新网络路径、动态路由（收敛时间/稳定性）* 容灾切换决策 － 及时发现灾难（容灾系统管理）、容灾切换的损失和补救办法 * 容灾切换过程 － 变更管理

同时，无论任何时候，备份都是非常重要的，并要定期测试备份的可靠性。一种技术只能减少或防止某些类型的灾难的影响。除了简单或一成不变的应用，在没有特别要求的情况下，尽量不要采用操作系统层面以上的数据复制技术。而没有文档化的流程就相当于没有流程，没有流程的系统能够在要求时间内恢复完全靠运气（通常不能）。

另外，在通常情况下，IT系统相关的灾难备份方案设计都必须考虑以下五大因素，1，灾难类型

需要考虑哪些灾难？怎样的灾难？会使业务中断多久？ 2，恢复速度

灾难发生后需要多久来启动及运行系统？能否承受数天或数分钟的等待？ 3，恢复程度

需要恢复每条记录和交易吗？可以使用上星期或昨天的数据吗？需要恢复一切吗？有不相关的文件吗？什么是合法隐含的要求？有少数的一组人输入交易吗？他们可以重新输入灾难期间丢失的交易吗？这些交易十分重要而不容许丢失吗？ 4，可用的技术

必须结合考虑所选技术在本地区的适用性、实现条件以及在实施时是否受某些现有条件的制约？ 5，方案总体成本

实现灾难备份需要多少投资？不实现灾难备份会损失多少钱？ 综合以上所述，可以如图2所示：

图2.灾难备份方案选择标准

2.3.1容灾的7个层次

据国际标准SHARE78的定义，灾难恢复解决方案可根据以下主要方面所达到的程度分为七级，即从低到高有七种不同层次的灾难恢复解决方案。可以根据企业数据的重要性以及您需要恢复的速度和程度，来设计选择并实现您的灾难恢复计划（参见图3）。这取决于下列要求： 备份/恢复的范围 灾难恢复计划的状态

在应用中心与备份中心之间的距离

应用中心与备份中心之间是如何相互连接的 数据是怎样在两个中心之间传送的 有多少数据被丢失

怎样保证更新的数据在备份中心被更新 备份中心可以开始备份工作的能力

现已证明，为实现有效的灾难恢复，无需人工介入的自动站点故障切换功能是一个必须被纳入考虑范围的重要事项。目前通用的异地远程恢复标准采用的是1992年Anaheim的SHARE78，M028会议的报告中所阐述的七个层次：

0层-没有异地数据(No off-site Data)Tier0即没有任何异地备份或应急计划。数据仅在本地进行备份恢复，没有数据送往异地。事实上这一层并不具备真正灾难恢复的能力。

1层-PTAM卡车运送访问方式(Pickup Truck Access Method)Tier1的灾难恢复方案必须设计一个应急方案，能够备份所需要的信息并将它存储在异地。PTAM指将本地备份的数据用交通工具送到远方。这种方案相对来说成本较低，但难于管理。

2层-PTAM卡车运送访问方式+热备份中心(PTAM + Hot Center)Tier2相当于Tier1再加上热备份中心能力的进一步的灾难恢复。热备份中心拥有足够的硬件和网络设备去支持关键应用。相比于Tier1，明显降低了灾难恢复时间。3层-电子链接(Electronic Vaulting)Tier3是在Tier2的基础上用电子链路取代了卡车进行数据的传送的进一步的灾难恢复。由于热备份中心要保持持续运行，增加了成本，但提高了灾难恢复速度。4层-活动状态的备份中心(Active Secondary Center)Tier4指两个中心同时处于活动状态并同时互相备份，在这种情况下，工作负载可能在两个中心之间分享。在灾难发生时，关键应用的恢复也可降低到小时级或分钟级。

5层– 两个活动的数据中心，确保数据一致性的两阶段传输承诺（Two-Site Two-Phase Commit）

Tier5则提供了更好的数据完整性和一致性。也就是说，Tier5需要两中心与中心的数据都被同时更新。在灾难发生时，仅是传送中的数据被丢失，恢复时间被降低到分钟级。6层-0数据丢失(Zero Data Loss)，自动系统故障切换

Tier6可以实现0数据丢失率，被认为是灾难恢复的最高级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力，当发生灾难时，能够提供跨站点动态负载平衡和自动系统故障切换功能。

2.3.2容灾的业务恢复时间段

对于IT系统的容灾指标，我们可以通过下列参数表示： * 以恢复点为目标(RPO--Recovery Point Object）– – 数据的完整性(无数据丢失)– – 数据的一致性(数据正确且可用）

* 以恢复时间为目标(RTO---Recovery Time Object）* 以网络恢复为目标(NRO---Network Recovery Object）* 以服务支持能力为目标(SDO---Serviceability Degrade Object)– – 性能

– – 地域/ 支持的客户总数 – – 功能的限制

图4展示了业务恢复的不同时间段。

图4.容灾的业务恢复时间段 2.3.3容灾所涉及的恢复技术

DR（容灾 Disaster Recovery）项目的实施中涉及到多种技术。这些技术可以分为三类：应用恢复，网络恢复，数据恢复。应用恢复技术

常用的应用恢复技术或方法如下：

* 通过负载均衡提供永不停顿的系统运行能力(Tier-7)例如：IBMS/390的GDPS技术给用户提供一个无中断的操作环境,来运行那些关键业务的应用程序，通过自动应用恢复能力来满足其第7级容灾要求 * 通过事先写好的脚本来实现自动的热接管(Tier-6)例如：GDPS也可以在热待命状态下运行，来为S/390系统提供第6级解决方案。

HAGEO提供与GDPS热待命相似的解决方案，并常被用来作为大型关键业务UNIX数据中心的DR解决方案

* 按预案手工实现站点接管(Tier 4/5)例如：有些设施的DR包括必须有人介入和决策的手动应用恢复程序。

在实际灾难发生时，一些这样的设施因为对人工操作的依赖，造成恢复过程的延误。因此，我们认识到，容灾的实施必须包括一定程度的自动化，这也是GDPS和HAGEO这样的软件的主旨。网络恢复技术

常用的网络恢复技术或方法如下： * 4-7 层交换机(Tier-7)例如：无中断的第7级网络恢复需要动态网络路由重选，来保证应用能够在不中断最终用户的情况下转入备用数据中心。在SNA环境下通过APPN来完成，而在IP环境下则通过第4-7层转换来完成。APPN是在IBM S/390 GDPS环境下，为动态网络恢复而开发的SNA网络技术。通过标准的基于路由器的技术，可以在通用的IP传输上使用APPN * 路由(Tier-6)例如：在第6级DR的实施中，网络恢复可以通过APPN和/或标准的路由协议来完成(OSPF / EIGRP / BGP-4)在非GDPS环境中，APPN应用路由在容灾系统备用路径可用时，自动恢复网络连接

* 2层 Reconnect(Tier-4/5)例如：SNA子网在以太网/SNA中通过ATM / 帧中继 / DDN 链路进行互联，如果发生链路故障，则可以通过手工切换来实现网络恢复

数据恢复技术

数据容灾系统的实现可以采用不同的技术。一种技术是采用硬件进行远程数据复制，我们称为硬件复制技术。这种技术的提供者是一些存储设备厂商，其技术例如PPRC、SRDF。数据的复制完全通过专用线路实现物理存储设备之间的交换；另一种技术是采用软件系统实现远程的实时数据复制，并且实现远程的全程高可用体系（远程监控和切换）。这种技术的代表则是一些存储软件厂商，其技术例如HAGEO、VVR。

数据复制是一个复杂的议题，但一般来说这，它可以在硬件或软件层上实施（参见图5）。今天，市场上的硬件和软件技术提供不同的第4级和第7级数据恢复，对硬件或软件的选择取决于很多与设施相关的因素，如工作量、网络成本要求、工作点和数据恢复点间的距离、同性或异性的平台支持等等。我们将在下面的章节对以上两种技术进行详细的论述。

图5.数据复制技术 第三章 容灾方案分析

业务连续性开发模式 | 七层灾难恢复解决方案 | 如何选择最优的灾难恢复方案

在现代企业的IT系统管理过程中，常常会遇到各种有关灾难备份范畴的需求，例如：

―无论发生任何问题，业务系统必须在最短的时间内恢复！‖； ―无论发生任何问题，数据绝对不能丢失！‖ ……

针对这些问题，有经验的管理人员可能会考虑到一系列由此引发的问题： ―究竟有些什么因素可能导致业务中断？‖ ―究竟最短的时间是多长？‖

―是否所有的应用系统数据都不能丢失？‖ ―这些恢复目标是否合理？‖

―目前的IT架构是否能够满足所要求的恢复目标？‖

―是否IT系统得到恢复，就意味着业务部门可以对客户进行服务？‖ ―如何衡量灾难备份方案的投入产出比？‖ ……

回答以上这些问题的过程，就是考虑企业业务连续性的过程。事实上，随着IT系统在企业内部应用的深入，灾难备份在企业中已不是IT一个部门的问题，而是整个企业各业务部门与IT部门紧密合作的问题。其内容也不仅局限于数据的备份和应用的接管，还包含了网络的冗余、人员与组织架构的整理、恢复流程的设计等一系列技术以外的范畴。目的在于保证在灾难环境下，企业真正从业务的角度得到保护，而不仅仅是IT环境的恢复。

3.1业务连续性开发模式

各行各业的用户，需要针对自身情况，设立可行的业务恢复目标，并制订出切合实际、投资合理、可靠的业务连续性及技术方案。这种业务连续性开发模式，体现在业务连续性或灾难备份的项目中，就是灾难备份项目实施的步骤：

1.灾难类型分析 2.业务冲击分析

3.当前业务环境及恢复能力分析 4.容灾策略制订 5.容灾方案设计 6.业务连续性流程设计

7.业务连续性流程及容灾方案管理和测试

其过程如下图所示，是一个周而复始的过程，随着企业内部环境的变化随时灵活变化：

图一.灾难备份项目实施过程

3.1.1阶段

一、灾难类型分析（风险分析）

在本阶段，需要进行详细而量化的风险分析，以确定当前IT环境之中存在哪些无法接受的物理威胁或者可能发生的灾难，并对灾难发生的可能性、目前可能的防护措施的有效性和该灾难所威胁的资产价值进行分析，最终得到带有优先级别的需要防护的灾难列表，并制订可能的处理方法，如接受该灾难发生的风险而不进行防护、自行制订该灾难的防护方法或者采取购买保险等风险转嫁策略。其结果可以由下图表示：

在该图中，横坐标为风险发生的可能性，纵坐标为风险发生所造成的损失。在某一风险发生的可能性极小时，即使造成的损失极大，也可能属于可接受的风险范畴，例如美国的―9?11‖事件。但该接受程度是与时俱进的，在―9?11‖事件发生后，事实是大部分没有考虑这种大范围灾难性事件的企业基本没有得到恢复的机会。目前业界也已经将低概率事件逐渐纳入防护的范围。

3.1.2阶段

二、业务冲击分析

在本阶段，应该针对各种业务流程进行分析，通过走访各业务部门的相关人员，了解各种业务流程本身对该企业的重要程度。（例如在银行业里，储蓄和单据、网上支付、电话银行等业务就具有不同的优先等级。）同时根据一定的评判原则，得出在核心流程由于灾难的发生而无法正常进行时对企业本身的损失情况。这种损失可能是可以量化的，例如单据的丢失、计算的错误而导致的直接损失；也可以是无形的损失，例如客户满意度及竞争优势的丢失。通过对可量化和不可量化损失的综合考虑，得出各种核心业务流程由于灾难受损的可容忍程度及损失的决策依据。体现在IT系统上，是三个指标：

数据恢复点目标（RECOVERY POINT OBJECTIVE）：体现为该流程在灾难 发生后，恢复运转时数据丢失的可容忍程度；

恢复时间目标（RECOVERY TIME OBJECTIE）：体现为该流程在灾难发生后，需要恢复的紧迫性也即多久能够得到恢复的问题；

网络恢复目标（NETWORK RECOVERY OBJECTIVE）：即营业网点什么时候才能通过备份网络与数据中心重新恢复通信的指标；

对于不同的业务流程，这三个指标可能相差非常之大，各个流程本身对这三个目标的优先程度也是不一样的，有的流程可能要求数据丢失的程度较小，但恢复时间可以较长，而另一些流程可能要求短时间内恢复，但数据的丢失程度可以放大一些。这三个指标直接影响所使用的容灾策略及技术方案，并指导企业的投入成本。可以用下图表示：

图3.业务冲击分析曲线

在该图中，横坐标为灾难持续时间，纵坐标为灾难损失，在某一程度以下属于可接受的程度，即横虚线所示。这种可接受决策应该由负责该流程的业务部门综合考虑后做出。

3.1.3阶段

三、企业容灾环境分析 本阶段主要针对业务冲击分析的结果，对目前的内部环境进行评估，得出与恢复目标之间的差距。分析的对象为业务流程需要的资源，如IT环境等。通过本阶段的工作，得出各业务流程所牵涉的企业资产及资源（人力资源、IT架构、技术储备、技术使用程度、网络环境等），并分析得出目前的业务环境对容灾需求、冗余程度、可能造成的数据损失是否能够支持等方面的报告。用下图表示：

图4.容灾环境分析

图中右边红线为目前环境所支持的容灾能力，左边红线为经过业务冲击分析所得到的需要达到的恢复能力，在灾难恢复时间和灾难造成损失两个方面都需要得到降低。

3.1.4阶段

四、容灾策略制订

在本阶段，结合以上各阶段的分析成果，以及企业本身在容灾上的投入能力，制订企业短期、长期范围内的容灾策略和目标，并有意识地将企业本身的人员组成和组织架构做出调整以适应策略要求。最重要的是制订出容灾实施步骤，优先解决最为重点的问题。如下图所示：

图5.容灾策略制订

3.1.5阶段

五、容灾方案设计

容灾方案可供选择的范围很大，但所有的容灾方案都必须考虑的因素包括恢复时间、实施与维护容灾策略所需的投入等。容灾恢复时间的需求越短，所需的实施成本就越大，实施难度也就越高。恢复时间与投入的比值可以用以下这张曲线图加以说明：

图6.容灾方案层次

图中的各种层次方案可以分别满足不同的数据恢复目标和恢复时间目标，需要根据业务冲击分析的结果，针对每一种业务流程，综合选择能够满足容灾目标的方案。

3.1.6 阶段

六、业务连续性流程设计

有了IT系统的恢复方案，只能够保证在灾难环境下，IT系统的恢复能够保证业务冲击分析的目标，但是业务的连续性并不只是IT系统的恢复，还包括办公场地、办公设备、紧急流程、指挥架构、人员调度等等多方面、各部门的综合考虑。只有业务流程执行过程的每一个环节都达到容灾目标的要求，才能够认为业务冲击分析的目标得到了满足。一般来说，每个企业都应该设立一个由领导挂帅，各业务部门和IT部门联合组成的一个容灾指挥小组：

图7.容灾组织架构图

由该小组指挥，IT部门和业务部门分别执行，IT恢复计划和业务连续性计划才能得到同步，从而达到容灾设计的目标。

3.1.7阶段

七、业务连续性流程及容灾方案管理和测试

任何制订的计划，都必须经过不断的测试和修正，才能满足企业不断发展的需求。同时，通过测试过程，也能够使企业内部各部门及人员熟悉自己在业务连续性计划中所扮演的角色，做到胸有成竹，才能够在灾难真正发生的时刻有条不紊地开展恢复的过程。

测试的过程可以分为―纸上谈兵‖和实地演习两种方式，根据企业需要及对业务影响的不同分别采用。

需要注意的是，无论平时的测试如何完善，也没有办法预测可能发生的灾难情况。关键人员的损失或者关键文档的丢失，都有可能对灾难恢复计划的执行造成巨大影响。因此，在灾难演练过程中要注意到人员的交叉备份情况，除了每个人自己所担负的责任外，尽量做到关键步骤有后备人选作为应变。

3.2七层灾难恢复解决方案

在谈到灾难恢复方案时，经常提到灾难恢复解决方案的7个层次(tier)。那么什么是7层解决方案？该如何为关键的业务应用选择最优的容灾方案？

3.2.1恢复的7个层次

灾难保护计划的目的是，确保关键业务持续运行以及减少非计划宕机时间。所有与容灾方案相关的计划都试图在方案本身、宕机时间和实施方案所需成本三者之间找到一个平衡点。

图8.三者的平衡关系

灾难恢复方案中的恢复时间与下列因素有关： 数据有效性的恢复 IT基础设施的恢复 可操作流程的修复 关键业务的修复

图9.灾难恢复的层次划分

3.2.2细述7个层次

灾难恢复方案的7个层次提供了一个简单方法论--如何定义当前的服务水平、风险以及期望的服务水平和环境。

0层：无异地备份数据(No off-site Data)对于使用0层灾难恢复解决方案的业务，可称其为没有灾难恢复计划，主要表现为： 数据仅在本地进行备份恢复，没有任何数据信息和资料被送往异地，没有处理意外 事故的计划。恢复时间：在此种情况下，恢复时间不可预测。事实上也不可能恢复。

例如，目前我们通常在机房内所做的数据备份，备份介质保留在机房内，用于本地的数据恢复。当灾难发生时，数据备份和设备有可能一同被毁，无法进行恢复。

1层：有数据备份，无备用系统（Data Backup with No Hot Site）

使用1层灾难恢复解决方案的业务，通常将需要的数据备份到磁带上，然后将这些介质运送到其它较为安全的地方。但在那里缺乏能恢复数据的系统，若数据备份的频率很高，则在恢复时丢失的数据就会少些。此类业务应能忍受几天乃至几星期的数据丢失。

例如，PTAM（Pickup Truck Access Method）是一种许多数据中心所采用的标准备份方式。在完成所需的数据备份后，用适当的运输工具将它们送到远离本地的地方，同时备有数据恢复的程序。灾难发生后，一整套系统安装需要在一台未开启的计算机上重新完成，系统和数据可以被恢复并重新与网络相连。这种灾难恢复方案相对来说成本较低(仅仅需要运输工具的消耗以及存储设备的消耗)。但恢复的时间长，且数据不够新。

2层：有数据备份，有备用系统（Data Backup with Hot Site）

使用2层容灾解决方案的业务会定期将数据备份到磁带上，并将其运到安全的地点。在备份中心有备用的系统，当灾难发生时，可以使用这些数据备份磁带来恢复系统。虽然还需要数小时或几天的时间来恢复数据以使业务可用，但不可预测的恢复时间减少了。

2层相当于在1层上增加了备份中心的灾难恢复。备份中心拥有足够的硬件和网络设备来维持关键应用的安装需求，这样的应用是十分的关键的，它必须在灾难发生的同时，在异地有正运行着的硬件提供支持。这种灾难恢复的方式依赖于PTAM方法去将日常数据放入仓库，当灾难发生的时候，再将数据恢复到备份中心的系统上。虽然备份中心的系统增加了成本，但明显降低了灾难恢复时间，系统可在几天内得以恢复。

3层：电子链接（Electronic Vaulting）

使用3层容灾解决方案的业务，是在2层解决方案的基础上，又使用了对关键数据的电子链接技术。电子链接将磁带备份后更改的数据进行记录，并传到备用中心，使用此种方法会比使用传统的磁带备份更快地得到更新的数据。所以，当灾难发生后，只有少量的数据需要重新恢复，恢复时间会缩短。

由于备用中心要保持持续运行，与生产中心间的通讯线路要保证畅通，增加了运营成本。但消除了对运输工具的依赖，提高了灾难恢复速度。

例如，某企业在每天下班后，将当日的流水全部记录下来，通过网络传到备份中心；备份中心在备用系统上，重新将所有业务重做，保证与生产中心的一致性。这一领域的产品可以分四层：

1）存储设备层：IBM-ESS-PPRC、IBM-DS4000-RM、EMC-SRDF、HP-EVA-StorageWorks Continuous Access、FALCONSTOR-IPSTOR、NETAPP等。

2）操作系统及系统软件层：IBM-GEORM、VERITAS-Storage Replicator/Volume Replicator、LEGATAL-RepliStor。

3）数据库层：IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE-DATA GUARD等。

4）应用程序层：应用程序开发时考虑到数据的复制。

4层：使用快照技术拷贝数据（Point-in-time Copies）

使用4层灾难恢复方案的业务，对数据的实时性和快速恢复性要求更高些。1-3层的方案中较常使用磁带备份和传输，在4层方案中开始使用基于磁盘的解决方案。此时仍然会出现几个小时的数据丢失，但同基于磁带的解决方案相比，通过加快备份频率，使用最近时间点的快照拷贝恢复数据会更快。系统可在一天内恢复。

4层灾难恢复可有两个中心同时处于活动状态并管理彼此的备份数据，允许备份行动在任何一个方向发生。接收方硬件必须保证与另一方平台在地理上分离，在这种情况下，工作负载可能在两个中心之间分享，中心1成为中心2的备份，反之亦然。在两个中心之间，彼此的在线关键数据的拷贝不停地相互传送着。在灾难发生时，需要的关键数据通过网络可迅速恢复，通过网络的切换，关键应用的恢复也可降低到小时级。支持这种工作方式的产品包括IBM-HAGEO、VARITAS-Global Cluster Manager。

5层：交易的完整性（Transaction Integrity）

使用5层灾难恢复方案的业务，要求保证生产中心和数据备份中心的数据的一致性。在此层方案中只允许少量甚至是无数据丢失，但是该功能的实现完全依赖于所运行的应用。

5层除了使用4层的技术外，还要维护数据的状态-要保证在本地和远端数据库中都要更新数据。只有当两地的数据都更新完成后，才认为此次交易成功。生产中心和备用中心是由高速的宽带连接的，关键数据和应用同时运行在两个地点。当灾难发生时，只有正在进行的交易数据会丢失。由于恢复数据的减少，恢复时间也大大缩短。数据库的数据复制功能一般可以工作在这样的方式下：IBM-DB2-HADR、ORACLE-ORACLE-Replication等。

6层：少量或无数据丢失（Zero or little data loss）

6层灾难恢复方案可以保证最高一级数据的实时性。适用于那些几乎不允许数据丢失并要求能快速将数据恢复到应用中的业务。此种解决方案提供数据的一致性，不依赖于应用而是靠大量的硬件技术和操作系统软件来实现的。

这一级别的要求很高，一般需要整个系统应用程序层到硬件层均采取相应措施。

1）应用程序层采用基于交易（TRANSACTION）的方法开发。

2）数据库可以采取数据复制。IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE-DATA GUARD等。

3）操作系统使用集群软件、站点迁移软件、数据复制软件：IBM-HACMP、VARITAS-Global Cluster Manager等。

4）硬件层使用同步的数据复制：IBM-ESS-PPRC、IBM-DS4000-RM、EMC-SRDF 或使用带有CONSISTANCY-GROUP功能的异步数据复制IBM-ESS-PPRC、IBM-DS4000-RM。

7层：解决方案与具体业务相结合，实现自主管理(Highly Automated , Bussiness Integrated Solution)

7层灾难恢复方案在第6层的基础上，集成了自主管理的功能。在保证数据一致性的同时，又增加了应用的自动恢复能力，使得系统和应用恢复的速度更快、更可靠（按照灾难恢复流程，手工操作也可实现整个恢复过程）。

7层可以实现0数据丢失率，同时保证数据立即自动地被传输到恢复中心。7层被认为是灾难恢复的最高级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力。7层是灾难恢复中最昂贵的方式，但也是速度最快的恢复方式。当一个工作中心发生灾难时，7层能够提供一定程度的跨站点动态负载平衡和自动系统故障切换功能。现在已经证明，为实现有效的灾难恢复，无需人工介入的自动站点故障切换功能需要一个应该纳入考虑范围的重要事项。

3.3如何选择最优的灾难恢复方案

在选择解决方案时，非常重要的一点是，解决方案所需的投资在IT商业价值中应占切实可行的部分，任何人都希望用较少的投资换取更多的利益--灾难恢复解决方案的投资一定要少于灾难本身带来的财政损失。

按照下述目标，为一个商业应用选择解决方案时，决定起来就会简单：

（按用户的投入、希望恢复的速度等目标来选择，灾难恢复越快所需的投入就越多）* 恢复时间目标（RTO – Recovery Time Objective）没有应用系统，可以忍受多长时间？

* 恢复时间点目标(RPO – Recovery Point Objective)系统恢复后，可以允许重新创建多少数据？

* 降级操作目标（DOO – Degraded Operations Objective）数据中心减少了，会有什么负面影响？

* 网络恢复目标(NRO – Network Recovery objective)网络切换需要多长时间？

通常，构成应用业务连续可用性的因素只适用于同一机房内的环境。机房本身就是一个单点故障。为了抵抗灾难，我们必须选择一种比连续可用性考虑更多的恢复方案。

恢复方案一定是在全面衡量了实施费用、维护费用、灾难对财政的影响，并对业务影响进行了分析后而得出的一个综合方案。

3.3.1四个关键目标

每一层灾难恢复方案的恢复时间通常是指恢复处理业务服务所需的安装时间。然而在现实的灾难中，需要对其他更多的事项进行考虑。例如，有些业务可以容忍较长时间的停机服务，但要求一旦业务开始就需要使用最多的实时数据；有些业务必须在尽可能短的时间内恢复服务，而不考虑数据的实时性；还有一些既需要最短的时间内恢复服务，也需要最多的实时数据。

通过评估具体场地的实际灾难恢复需求，为恢复计划开好头。

3.3.2方案成本与业务停止带来的损失

灾难恢复方案的成本是根据以下两点得出的： * 客户需要在多快的时间内恢复数据 * 不能继续业务处理将带来多少损失

恢复数据所需的时间越少，业务处理服务中断的时间就越短，所需的方案成本就越多。

另一方面，不能进行业务处理的时间越长，由此带来的损失就越大。

最优的方案就是，方案成本曲线和业务停止带来的损失的曲线的交集。成本/时间窗口。

3.3.3与系统体系结构的关系

为了灾难保护，需要建立一个可靠并经过验证的基础结构，系统的每一级部件都一定要有冗余，这是必须的。

存储设备级（Storage Device Level）

存储设备级，是指存储的物理实体，如磁盘或磁带机。为了实现设备级的可用性，使用嵌入在设备自身中的功能，这些冗余功能可通过在磁盘中使用备用磁道或在磁带机中使用特定的写机制来实现。

存储服务器（存储子系统）控制器级

存储控制器自身的接口用于连接SAN或服务器（Servers）和存储设备。存储控制器的内置功能负责所有与存储相关的执行操作。

* 内置的拷贝功能，如Point-in-Time 拷贝，远程镜像 * 内置高可用性机制（冗余、接管Fail over）

SAN（Storage Area Network）级

SAN级的冗余可通过冗余SAN的基本模块--SAN交换机或使用导向器（Director）来实现。SAN交换机和导向器的主要区别在于可维护性和可用性。导向器类的产品可以在不中断服务的同时，在线进行Microcode/Firmware的升级。在出现硬件故障时，导向器通常只需更换一个部件。

操作系统中设备驱动程序级

设备驱动程序是存储设备，服务器的操作系统和主机适配卡之间沟通的桥梁，它负责实施与操作系统中所展示的全部硬件功能相关的操作，并负责与存储设备之间的通讯，如光纤通道环境中多路径和通道接管功能。

操作系统级

在操作系统级，通过使用群集技术可以实现操作系统级的高可用性，如 HACMP for AIX，STEELEYE for LINUX 和 Microsoft Windows Clustering。可以考虑将群集技术作为灾难保护的一部分。在灾难保护方案中群集本身不代表基础设施。

应用级

要想在应用级实现冗余，在很大程度上依赖于应用的类型。如在三层的SAN环境中，通过使用多个应用服务器（Multi Application Server），应用层可以做到高可用性。如果任何服务器发生故障，加在其上的负载就会被重新分布到其他运行中的服务器上，业务可继续进行。

功能级

功能级是系统整体架构中最重要的一级，它依赖以下级的可用性： * IT基础设施架构的可用性（操作系统+服务器+存储+网络）* 应用的可用性（应用+数据）+IT基础设施架构的可用性 * 业务流程的可用性（应用的可用性+外部相关条件）

在规划灾难保护的功能级时必须包括所有外在因素，如不同企业间的相互协作等。

第四章 容灾系统的设计过程

灾难恢复计划描述 | 灾难恢复计划项目阶段 | 数据收集和关键需求分析阶段 | 风险分析阶段 | 数据保护阶段 | 恢复阶段 | 测试和培训阶段 | 维护和修改阶段 | 选择灾难恢复方案的步骤介绍

容灾方案的制定是一个系统的过程，包含一系列的工作及计划的制订，包括Business Continuity Planning(BCP)，Business Recovery Plan(BRP)，Continuity of Operations Plan(COOP)，Incident Response Plan(IRP)，Occupant Emergency Plan(OEP)，Disaster Recovery Plan(DRP)等计划，在此我们主要介绍灾难恢复计划（Disaster Recovery Plan 或 DRP）的制订过程及方法

相比于其它机构和领域，IT系统更容易受到各种灾难的伤害而导致中断，特别是在许多情况下，关键资源可能属于不可控范围（如电力和电信），于是有效的灾难恢复计划、履行计划和对计划进行有效地测试对于削减系统风险与各种服务的不可用性就显得非常重要了。为了保证灾难恢复计划的成功，管理者应该做到以下几点：

1.理解灾难恢复计划的全部过程及其在整个运行连续性计划和业务连续性计划过程中的地位。2.制定或复查其应急策略及计划过程并运用计划周期要素，包括预备计划、业务影响分析、备用站点选择和恢复策略。

3.制定和复查其灾难恢复计划策略，重点在于计划的维护、培训以及对应急计划的演练。4.1灾难恢复计划描述

简单地讲，灾难恢复计划的重点在于IT的恢复，如系统、应用、数据和相关的设施（如网络等）。灾备的主要目标是在事件发生时，能够保证全部或部分计算机服务的持续可用。灾难恢复计划就是指，在灾难发生时需要采取的响应步骤的详细过程。

灾难恢复计划包含了一系列灾难发生前、过程中和灾难发生后所采取的动作，灾备方案计划书应该文档化，并经过充分的测试，以保证灾难处理过程中各种操作的连续性和关键资源的可用性。

根据灾难发生的时段或业务中断的严重程度的不同，一个企业的生存能力也依赖于管理层重建其关键业务的能力。一般来讲，这些业务功能的重建需要几年的时间。但是，对于管理层，必须在几个小时或几天的时间内重建，确实是一个难题。重建复杂的商业环境要求有一个经过慎重考虑且具体的计划，以备在灾难发生时执行。从这份计划中我们可以看到，为恢复初始环境，在重建过程中应该采取的步骤。

在一个组织中，灾难的发生是不可预测的。对客户而言，最想知道的事情是灾难什么时候发生。系统和工作人员可以应对灾难，并对可预知的灾难进行反应是最终的目标。换句话说，灾难发生时，不需要等待，而只需要确定你的计划是否可行。

灾难发生时，客户、供应商和员工通常会关心中央处理设备的停机时间。在这种情况下，这些人都没有什么过分的要求，只关心停机的等待时间，而停机时间的多少则依赖于灾难恢复方案。通常，这种停机时间可以分为以下两个部分： a)服务丢失

表示从灾难发生到系统恢复正常所损失的时间。b)数据丢失

表示用户数据的丢失，也就是说，系统恢复到灾难发生前的数据层面，要花费多少时间可以重新工作。

一个组织的大部分收入，如果过分的依赖于生产系统，一旦应用和网络停机，则将会造成巨额收入的损失。在不同的行业，如果以小时为单位计算收入损失，因灾难而造成的收入减少也是不同的，如能源、电信、制造行业和金融部门，造成巨额收入的损失并不惊奇。另外，实际收入损失所占的百分比也和运营的关键业务有关系

总之，灾备计划就是要保证灾难发生后，能及时地按照一定的策略、过程和技术等方法迅速恢复IT系统、操作和数据。4.2灾难恢复计划项目阶段

如何制订灾难恢复计划，前面的章节中（参看3.1节 业务连续性）给出了指导性的建议步骤。上述步骤中，每一步都包含了相关方面的各项内容。实际上，在制定灾难恢复计划时，我们可以将这些步骤细化为下图的操作流程。在下图的流程中，包含了灾难恢复计划的各个阶段，并直观的告诉我们，灾难恢复计划的制定是一个循环往复的过程。

图1.灾备计划不同阶段图表

对上图的简单分析如下，更详细的内容，将在以下的章节中给出：

1）项目启动及项目组的选择

此阶段包括取得管理层的正式同意、选择项目协调人员和项目组成员、信息收集方式的标准化以及项目资源的调度等方面的内容。2）数据收集和需求分析

此阶段包括收集业务过程的信息、技术基础架构的支撑环境、潜在的停机费用消耗、灾难类型以及其它公司使用的相应技术和策略等方面的内容。3）风险分析

在风险分析阶段，我们将对为达到灾难恢复计划的设定目标收集的数据进行处理，以便对风险以及在可接受的时间范围内恢复所需要的资源有较深的理解。

作为风险分析的结果之一，灾难防范技术的实施可以帮助我们防止可以避免的灾难。比如：火灾的侦测和防止，不间断电源系统等。4）数据保护

数据保护是灾难恢复计划中的关键模块。必须清晰、完整地表述出各类数据（记录、胶片、电子及光学数据等）的保护方法。5）恢复计划

恢复计划是指对意外事件所采取的策略及明确的规划。如替代的系统、网络和终端用户。6）培训和测试

培训和计划性的测试可以对所设计的灾难恢复策略进行测试，并且提供了一种可以对灾难恢复计划中的不足方面进行发现和修改的手段。7）计划的维护管理

计划的维护管理提供了一种机制，可以使灾难恢复计划随着业务和IT系统架构的改变而改变。下面我们对各个阶段给出较详细的解释。

项目启动和项目组选择的阶段可细分为以下几个主要组成部分： 1 最高管理层的承诺

企业的最高管理层必须支持且参与计划的制定和协调，以确保灾难恢复计划在本公司内的有效作用。制定一个有效的计划，必须要有时间和资源的保证，时间就是计划的制定所需要的时间，而资源则包括预算和人力。2 建立计划制定委员会

计划制定委员会负责监控计划的制定和实施，由公司各个部门的代表组成，关键的委员会成员应当包括业务运营经理和数据处理部门经理。委员会还应当定义计划的适用范围。委员会的另一个职责是定期把项目信息通知给最高管理层，因为这是一个比较敏感的主题，可能需要花费较多的人力和财力，这些都需要最高管理层来支持。3 范围

尽管大多数灾难恢复计划只包含数据处理相关的项目，但是一个复杂的计划也包含数据处理以外的操作领域，如果同时考虑到灾难的其它方面，灾备计划涉及的范围是相当广泛的。4 假定

制定计划要考虑的最基本问题就是设想最坏的场景。对运营系统而言，最坏的场景就是主要设备的损坏。计划的制定就是基于这样一个前提，每一个灾难恢复计划都基于一组假定的设想。这些假定对计划所涉及的环境做了限制，这些限制定义了公司准备接受的灾难量级，它们可以通过以下问题来识别：

a）哪些设备被破坏 b）中断的时间是多少

c）哪些记录、文件和资料需要保护 d）灾难发生时，哪些资源是可用的 1）员工 2）设备 3）通讯 4）传输 5）后备场地

在制定灾难恢复计划时，可以借鉴以下典型的假定： a）公司主要的生产设备被破坏

b）拥有在可以执行计划之内的关键性功能的员工

c）员工可以被通知到，并且可以到备份地点执行关键性的恢复和 重建工作

d）灾难恢复计划是可用的

e）部分计划可用于恢复相应的环境中断 f）备份设备是可用的

g）在异地或别的设备中保存有足够多的备份 h）备份地点可以处理公司的工作 i）公司本地和远端的通讯链路是可用的 j）本地基本的传输是可用的

k）灾难发生时，供应商应根据承诺对公司提供支持

以上的假定并不包含全部可能性，但在计划制定的开始阶段可供大家参考。5 项目组及其责任 灾难恢复计划可以按照组的形式来制定，特定的任务可以分配给特定的组。意外发生时的公司架构可能与现有的架构有所不同，那时通常是以组为基础，不同的组负责不同的功能领域，这些组可能包括： a）管理组 b）业务恢复组 c）部门恢复组 d）计算机恢复组 e）损坏评估组 f）安全组 g）设备支持组 h）后勤支持组 i）行政支持组 j）用户支持组 k）计算机备份组 l）异地数据存储组 m）软件组 n）通讯组 o）应用组 p）人力资源组 q）市场和客户关系组

企业并不需要建立以上所有的这些组，但我们强烈建议与上述的每个组相关联的功能都能被包含在其中。

根据员工的技能和领导能力，可以将其选入不同的组。一般来讲，各组的成员所拥有的技能应与其平时的工作相一致。例如，服务器恢复组的成员应当包含系统管理员。组成员不仅要知道计划的目的，而且要知道执行恢复策略的过程。考虑到可能会联系不到某些成员的情况，成员的组建应基于―互有备份‖的原则。同样，成员也应当了解其它组的目的和执行过程。

每一个组由组长领导，组长要负责本组的运行，承担同其它组的协调工作，向组员及时传达需要的信息，并在组内做决定。另外，如果组长不能行使其职能，必须指定代理组长。在灾难恢复计划中，最重要的组是管理组。他们在事故发生时负责协调所有组的工作。管理组一般由高级管理经理负责，如CIO。

以下是各个组的主要职能： a）负责计划的执行

b）促进与其它组之间的交流，监督计划的测试和执行 c）所有或是某一个成员可能领导特定的组 d）协调恢复过程

e）评估灾难，执行恢复计划，联系组长 f）监控并记录恢复的过程

g）是最终决定优先级设置、各种政策和过程的人

4.3数据收集和关键需求分析阶段

要确定一个企业的关键性需求，每个部门应该将本部门执行的功能文档化，经过一定的分析来确认部门内部和外部的主要职能。

部门的日操作记录可以对确定关键性需求起到辅助作用。以下是一些辅助问题：

1）如果灾难发生而没有现有的设备和部门架构，部门能运转多长时间？

2）在部门内，什么任务的优先级最高？（包括关键的手工功能和处理）这些任务 被执行的频率是多少？如每天、每星期或每月等。

3）执行最高级别的任务，需要那些人力、设备、和供应等？ 4）对于关键的设备及供应，在灾难的环境中应如何替换？ 5）上述这些关键信息的替换需要多长时间？

6）部门内有没有可供参考的手册和操作步骤？灾难发生时这些是如何替换的？ 7）任何供应、设备和操作过程或手册等，有没有在异地存放？

8）确定原始文档的存储设备和安全性。在灾难的时间中，这些信息如何被替代？有没有更多的地方来保存？

9）当前计算机的备份过程是什么？如何恢复备份？任何关键的备份拷贝有没有在异地存放？ 10）在灾难发生后，临时性的操作步骤是什么？ 11）一个部门的运转中断，对其它的部门有什么影响？ 12）依赖于正常运转的企业以外的服务商和供应商有哪些？ 13）有没有经过跨部门培训的人员？ 14）谁负责维护部门的异常计划？ 15）灾难恢复计划有没有其它的考虑？

在上述问题的基础上，我们列出了以下需要进行文档化的信息：备份地址列表，关键电话号码记录，通讯目录，分发记录，文档目录，设备目录，表格目录，保险政策目录，主要的计算机硬件目录，主要客户列表，主要供应商列表，计算机硬件和软件列表，通知列表，办公用品供应列表，异地存储地址列表，软件和数据文件备份和调度，电话目录等资料和文档。

关键性需求可以通过问卷的方式来获得，问卷主要是将每个部门的关键性工作记录在案，并找出最小的必备资源，如人力、设备、供应商、文档等资源。

确定了各部门的关键性需求并将其文档化以后，管理层就可以为各部门在整个企业的灾难恢复过程中设置优先级别。每一个部门的操作可以按照下面的方式给出优先级：

1）基本操作（必需）：服务中断超过一天，将严重地危害到公司的运转。2）推荐操作（关键）：服务中断超过一个礼拜，将严重的危害到公司的运转。

3）其它操作（非关键）：这些信息的存在可以方便业务操作，如果 一旦丢失也不会 影响到业务的正常运转。

根据RTO和RPO的不同，各公司采取的策略也会有所不同。以下是一些通用的标准，可以根据这些标准将应用进行分级：

1）必需：从停机算起，RTO<8小时，RPO在15分钟以内 2）关键：从停机算起，RTO<72小时，RPO从停机的那一天开始 3）非关键：从停机算起，RTO<168小时，RPO48小时以内

4.4风险分析阶段

计划小组负责准备风险管理的流程和业务影响的分析（Business Impact Analysis）。它们包括一定范围内的灾害，如自然、技术或人为的灾害。

针对于几种假定的灾难设想，企业的每一个职能领域都应当分析和判断相应的潜在结果和影响，在风险分析阶段还将评估关键文档和重要记录的安全性。

在多样的中断过程中，IT系统更容易受到损害。作为企业风险管理的一部分，有些风险是可以通过技术、管理和操作执行方案来避免的，但不可能避免所有的风险。灾难恢复计划就是一种用来弥补这些风险管理和安全操作不能涉及的灾难的高可用性方案。由此看来，灾难恢复计划可以提供一种紧急事件发生后的快速恢复手段。

4.4.1风险管理过程

风险管理过程范围广泛，包括确定、控制和减轻IT系统的潜在风险。从风险管理的行为分析，可以分为两个大的主要功能：

1）通过减少或消除风险，进而避免或减少破坏性的事件。这些措施主要是对从自然、人为和技术方面的威胁进行的安全控制，从而减少或消除风险。

2）降低或限制灾难对系统造成的后果。主要措施是预估可能的事件，并在相应的事件 发生后采取相应措施，建立基本的灾难恢复计划。

下图示意了预先采取安全控制和灾难恢复计划实施的事件间流程：

4.4.2商业影响分析

商业风险分析是灾难恢复计划过程中的重要步骤，隶属于风险分析阶段。这一过程集中分析系统需求、过程及其内部的依赖关系，并使用这些信息判断可能意外发生的事件及其优先级，图示为风险分析的示例过程：

上图的示例分为三个过程： 1）确定关键资源

2）确定中断的影响及允许的停机时间 3）设计恢复的优先级

4.4.3建立可靠的系统

业务恢复计划的目的是保证员工和设备在灾难发生过程中的安全。风险分析的主要目的之一是确定在任何时候应采取的正确防范措施。对灾难的防范和准备工作应从企业的最高管理层开始，管理层的支持体现在对先进的安全和风险防范技术的选择，以及对未知风险的准备等方面。灾难预防技术包含两个方面：流程方面的预防和物理方面的预防。流程方面的预防

流程方面的预防与日常的操作相关，主要是操作规则的定义，相关主题为安全和恢复。流程防范是同每一个员工的行为相联系的，公司为每一个员工分配相应的职责。流程防范的目标是针对于不同的灾难类型定义相应的操作，并使得这些操作成为规则 物理方面的预防

从场所的建造就开始为灾害做准备，包括为建筑物配备特殊设备。如为不同的设备配置火灾保护。这些特殊的考虑包括：计算机区域设置，火灾侦测装置和灭火装置，记录保护，空调设备，热敏和通风设备，电子供应系统和UPS系统，双路电源保护，突发事件过程和档案系统。

4.5 数据保护阶段

数据保护是指在公司内部为保护公司资产、确保记录的准确性和可靠性以及操作的有效性而采取的措施。可以从履行保险和分类记录各种信息两个方面来考虑。

4.6 恢复阶段

恢复计划是一种主要考虑在灾难发生后，如何快速有效的恢复IT系统的策略，策略的制定应当考虑商业影响分析中所涉及的风险，而且在系统设计和实施的阶段中，它与系统的架构设计相集成。在设计恢复计划时，应考虑下面的情况： 1）系统恢复

系统恢复应针对于关键应用主机，如集中式和分布式 2）网络恢复

网络恢复计划主要针对以下方面：

a）关键商业应用系统的内部局域网和网络设备的支持 b）外部广域网和电信服务

c）待恢复系统和终端用户间的通讯 3）启动各灾难恢复小组

灾难恢复管理组负责协调恢复过程中所涉及的各个项目组。在异常情况下，准确快速的决定会起到关键的作用。管理组将负责包括财务决定在内的所有决定。成功的灾备计划，即使在关键的成员不能工作的情况下，也可以恢复并维持业务的运转。4）最终用户恢复

最终用户的恢复计划，在传统的灾备计划中常常被忽略掉，合理的灾备计划为终端用户提供了一种可工作的机制

4.7测试和培训阶段

灾备计划的测试是灾备方案准备过程中的一个关键要素。测试可以暴露灾难恢复计划的不足之处，测试也可以帮助我们评估计划执行人员的快速响应能力和效率，灾难恢复计划的每一个要素都必须测试，保证其恢复过程的准确性。测试包含以下几个方面： a）从备份磁带恢复系统

b）执行恢复计划的各项目组之间的协调 c）内部和外部的互连

d）使用备份设备时的系统性能 e）正常业务操作的恢复

这里所推荐的测试过程是让灾难恢复计划的关键人员重复执行灾难恢复计划，这样做可以不断更新文档，并修补可能的遗漏，以保证即使主要人员休假，灾难恢复计划也可以执行。

培训是对测试过程的补充，主要目的是明确灾难恢复计划中各成员的责任，培训内容包括： a）计划的目的

b）跨项目组的协调和沟通 c）汇报制度的流程 d）安全要求

e）项目组特有的流程 f）成员的责任 4.8 维护和修改阶段

灾难恢复计划应反映系统的需求、执行的流程和规则。因为商业需求、新技术的不断升级以及新的内部和外部规则的变化，IT系统也会随之改变。所以，要确保灾难恢复计划的有效性，就必须定期的检查和修改计划。一般来说，当每年或当计划涉及到的内容有重大改变时，灾备计划需要作相应的检查，而有些内容更需要作频繁的检查，如人员的联系途径等。以下是至少需要定期检查的几个方面： a）运行环境要求 b）安全要求 c）技术程序

d）硬件、软件和其它的设备 e）各项目组的成员名称及联系方法 f）关键信息记录（电子或书面文档）

4.9选择灾难恢复方案的步骤介绍

本节主要介绍制订灾难恢复方案的简单过程，仅供参考。

1）按照一定的顺序询问特定的问题

按照一定的顺序，询问一系列与商业灾备需求相关的问题，通过这些问题，可以确定灾备方案的基本环境、基础构件及期望的恢复时间。以下提供一些基本的问题，部分问题答案的给出需要基于风险评估和商业影响的分析。另外一些问题则需要运营部分基于其IT基础架构给出答案： a)哪个或哪些应用需要恢复？ b)应用运行的平台是哪些平台？ c)期望的RTO是什么？ d)灾备实施场所之间的距离？

e)连通方式，或者在灾备地点传输数据的基础架构的传输 方式是什么？带宽是多少？

f)有没有特殊的硬件和软件的配置需要恢复？ g)RPO是什么？

h)需要恢复的数据量有多少？

i)期望的灾难恢复层次（计划/未计划/交易集成）？ j)谁来设计灾备方案？ k)谁来实施灾备方案？

以上并不是所有可能的问题，但这是一个很好的开始，你可以设计其他一些问题，这些问题是如何使用的呢？参考下图：

以上模型称为沙漏模型，在沙漏瓶颈以上的问题定义了基本的业务和IT需求，这些基本的问题必须有充分的答复，因为任何问题的缺少都意味着我们要投资的方案可能会没有正确的评估。采用这样的方式，在灾备方案实施前可确保收集到正确的业务和IT基础架构的需求。

我们必须保证这些问题的答案已经广泛征求了企业管理部门、商务部门、应用组合IT维护组的意见。

2）使用层/RTO（Tier/RTO）和恢复的层次定位灾备方案的子集

现在我们可以定义初步的方案，注意：在灾难恢复的七层中，一层总是建立在前一层的基础之上。对应于计划停机、非计划停机和交易一致性，相应的灾备技术和方案也有所不同： 计划停机：这一方案只有助于计划中的停机或者数据移植，对非计划的停机没有作用。非计划停机：在硬件和数据一致性的层面，这一方案有助于非计划停机的恢复，也意味着支持计划停机。在应用和数据库层面，这一层次的恢复不支持交易一致性的恢复。

交易一致性：对于非计划的停机，方案要求在应用和数据库交易一致性的层面提供恢复的能力。这一方案隐性要求硬件层次支持计划停机和非计划停机。

确定了合适的恢复层次、结合RTO、参考下图，可以很快的确定需要的灾难恢复方案。

3）排除非方案的东西

现在我们通过把第一步中收集到的问题答案应用于候选的方案并剔除不合适的方案，来定义初步、候选的灾难恢复方案。请参考下图：

通过第一步中获得的问题答案，如距离、不支持的平台等，可以剔除不符合要求的方案。

如果在这一步骤完成后存在多个灾备方案，这都是正常的，它们都是可用的方案。

4）将确定的方案提交给评估组

经过第三步后，将一组初步的灾备方案和可用的技术提交给资深的评估组，这个组由一些资深的成员组成。他们将详细的比较和分析这些备选方案，同时对有效的候选方案注明所需要的技能。

评估组需要充分详细的配置每一个候选方案。最后，评估组将决定最终选择最合适的灾备方案。

第五章 典型方案介绍

基于软件的数据备份技术 | HACMP高可靠性灾备方案 | 基于磁盘系统的PPRC数据级灾难备份解决方案

5.1 基于软件的数据备份技术

在应用软件进行灾难备份的解决方案中，应从下面三个层次考虑： 用户应用程序

客户机软件 数据库引擎

其中用户应用程序和客户机软件一般不包含关键数据，几乎所有数据都由数据库引擎管理并放置在数据库服务器中。在这三者之中，数据库中的数据保护最为重要。

一般情况下，用户应用程序和客户机软件只需要将其执行代码和参数配置文件做以备份，当灾难发生时，可以通过这些备份重新安装和配置用户应用程序和客户机软件。

对数据库的备份，如果采用硬件级灾难备份有两种方法：一是采用备份的方法，即定期地将数据备份到硬盘和磁带/磁带库上，这些磁带可以通过运输的方式运到远程，以防磁带在本地的灾难中发生毁坏。这种方法的缺陷是实时性较差，恢复时间较长；另一种做法就是硬件镜像的做法，这种做法在硬件的投资上较大，对两点间的网络带宽有较大的要求。那么，有没有一种两者兼顾的解决方案呢？数据库产品提供的数据库复制技术就是一种两者兼顾的灾难备份解决方案。在前面提到的灾难恢复方案的7个层次中属于第5或第6层次。

数据库复制技术在数据库级别的灾难备份解决方案中可以实现远程容灾。目前已有的产品有IBM DB2 HADR、IBM INFORMIX HDR以及ORACLE DATA GUARD。

IBM DB2 HADR是High Availability Disaster Recovery 的缩写，HADR 将HA（高可用性）和INFORMIX DR的技术紧密结合起来。INFORMIX HDR是High Availability Data Replication的缩写。

HDR的工作原理是通过将主数据库服务器（简称为A）的逻辑日志缓冲区复制到备份数据库服务器（简称为B），而且能在主数据库服务器操作失败时自动切换到备份数据库服务器。复制方式有同步方式和异步方式两种。我们将在下面详细介绍HDR的工作原理以及同步方式和异步方式。

正常状态下，主数据库服务器做数据库的读写操作，备份数据库服务器为只读方式。当主数据库服务器失败时，备份数据库服务器会自动接管主数据库服务器的事务处理。此时，备份数据库服务器作为主数据库服务器进行数据库的读写操作。当主数据库服务器被修复后，主数据库服务器作为新的备份数据库服务器。

此时备份数据库服务器虽为只读方式，但并不是空闲的。它可以分担主数据库服务器的负载，例如执行查询、出报表等任务。

数据库复制对硬件的要求相对较低，只要主数据库服务器和备份数据库服务器的硬件配置相同即可，不是必须使用高端存储设备，例如IBM ESS等。主数据库服务器和备份数据库服务器的距离不受限制，而且对网络的压力并不大，但需要更强的数据库管理能力。

下面介绍一下HDR的工作原理。如下图所示：

在逻辑日志缓冲区（Logical Log buffer）刷新之前，它里面所有的交易（Transaction）将拷贝到数据复制缓冲区（Data Replication Buffer）。数据复制缓冲区的大小和逻辑日志缓冲区相同。数据复制缓冲区通过TCP/IP网络将数据发送到备份数据库服务器的数据复制缓冲区中。在备份数据库服务器端，一个数据复制线程接收数据复制缓冲区的数据并把他们放入到恢复缓冲区（Recovery Buffer）.另一个数据复制线程（或一些线程）记录数据库日志信息。主数据库服务器和备份数据库服务器都有一个―Ping‖线程在运行，它会定时唤醒并且检查两个数据库服务器的连接。如果任何一台服务器上的―Ping‖线程检测到连接中断，都会发一条出错信息到消息日志中。

HDR有两种复制方式：同步方式（Synchronous）和异步方式（Asynchronous）

在同步复制的方式下，主数据库服务器的逻辑日志缓冲区只有在下面的过程完成后才可以刷新：

1.Copy: 逻辑日志缓冲区数据拷贝到数据复制缓冲区；

2.Send: 数据从主数据库服务器的数据复制缓冲区通过网络传送到备份数据库服务器； 3.Acknowledge:当备份数据库服务器接收到数据后发回确认信息； 4.Flush: 此时，主数据库服务器才可以刷新其逻辑日志缓冲区的数据。

采用同步方式的优点是两边数据库服务器的数据一致，但是由于每笔在主数据库服务期提交的交易需要发送到备份数据库服务器而且得到确认后才算真正成功完成，由此而产生的时间延迟会使性能受到一定的影响。

如果采用异步复制方式，主数据库服务器的逻辑日志缓冲区只要在逻辑日志缓冲区的数据拷贝到数据复制缓冲区之后就可以进行刷新了。这样做的缺点是在某些系统失败的情况下，可能会有一些数据还没有来得及通过网络传送到备份数据库服务器；优点是主数据库服务器的性能不受影响。

对于Oracle DATA GUARD的工作原理，大致上与IBM HADR 和INFORMIX HDR的工作原理类似。

Oracle9i DATA GUARD 通过使用称为备份的数据库来防止数据灾难的出现。它通过将源数据库的重做日志传输并应用到备份数据库中，来使备份数据库与源数据库同步：

可以将重做日志直接从源数据库同步的写到备份数据库，来完成零数据损失的灾难保护，这会给源数据库的性能带来一定的性能损失。

可以将归档的重做日志从源数据库异步的写到备份数据库，来使源数据库在极少的损失性能的前提下，最小化地减少数据的丢失。

如果重做日志数据到达备份数据库后就快速应用到备份数据库，则在源数据库出现问题时便可以快速地切换到备份数据库。然而，如果延缓一定时间后再应用重做日志数据，就可以避免源数据库的错误快速地传播到备份数据库。

DATA GUARD同样也有同步和异步复制两种方式可以选择。

5.2 HACMP高可靠性灾备方案

HACMP容灾系统在世界范围内广泛应用，具有以下鲜明的特点：

简单易用，7x24小时集群应用技术

显著减少停机时间，允许不间断的进行集群升级和系统维护 提供多种数据备份和恢复途径，以满足灾备的需求

HACMP经过十多年的发展，从5.1版本开始，增加的一项新的功能HACMP/XD支持ESS/PPRC和基于IP连接的远端故障切换。

5.2.1 A.HACMP方案 a)介绍

HACMP对关键应用提供良好的保护，提供可信赖的高可靠性服务、监控能力和对应用的失败监测，切换应用环境到备份主机。借助于HACMP/XD功能，也可以将应用切换到远端备份机器。在集群中，HACMP使用冗余的硬件配置以保持应用的正常运行，在需要时将应用切换到备份主机，最多可以有32台服务器组成HACMP集群。HACMP也可以监测应用的错误，但这些错误应当不足以影响到系统的正常运行，如进程失败、系统资源消耗过大等。对这些错误事件，HACMP监控、发现并采取相应的措施以保证系统的运行。HACMP可配置为响应几百个系统事件。

事实上，使用HACMP可以防止一些计划中的停机，如在停机维护的过程中，用户、应用和数据可以转移到备份主机。HACMP可以满足复杂的、各式各样应用的可靠性及其恢复的需要。

b)优势

HACMP充分利用了AIX操作系统的优点，并拓展了AIX系统和网络的管理功能，提供了横向和纵向的灵活性。c)功能增强

IBM HACMP在5.1的版本中，功能进一步增强，这些新的功能包括： 1)使用快速硬盘接管技术，减少切换时间，限制在10秒钟之内

2)使用流水式配置界面，仅仅需要六次输入就可以配置一个简单的 HACMP集群 3)基于硬盘的新的非IP心跳信号保护技术，不需要额外的硬件支持 4)增强的安全机制，剔除了对.rhosts的要求

5)增加快速的集群配置确认和同步技术，提高管理的效率 6)在集群的监控中提供更多的集群状态信息

7)增加灾难恢复技术，保证在灾难发生时系统是可控制的

5.2.2 B.HACMP/XD

在灾备方案中，如果需要在异地做数据镜像，HACMP/XD（Extended Distance）是必选的功能。对中小企业而言，HACMP/XD的高可靠性解决方案是极具吸引力的，从成本上看，也是可以负担的。在关键的商业应用中，高可靠性是最基本的功能。

HACMP/XD提供了多项技术以满足远距离的数据镜像、切换和信息同步：

a)支持IBM企业级存储服务器ESS的PPRC，即HACMP/XD over PPRC。这允许HACMP集群自动的切换PPRC镜像组（PPRC pairs）中的硬盘，可以设计基于ESS PPRC的强大的容灾方案。HACMP/XD结合PPRC，可以保证集群环境中关键数据始终可用。

下图为HACMP/XD PPRC方案的示意图：

b)HACMP/XD基于IP的镜像，提供远端数据镜像，没有距离限制，集成使用HAGEO 的技术。基于IP的镜像技术，允许HACMP集群中的pSeries UNIX服务器放置在任意位置，每台服务器都维护一份精确的应用和数据拷贝。HACMP/XD提供数据的同步、切换和恢复。HACMP/XD基于IP的数据镜像是基于存储介质的逻辑层来实现的。也就是说，本地的数据可以使用RAID或本地镜像保护。

HACMP/XD, HAGEO技术环境是一个分布式的集群，可以分布在两个足够远的地方，通过冗余的点对点的TCP/IP网络连接，提供应用数据的恢复功能。下图为HACMP/XD:HAGEO的集群示例：

对关键的商业应用和数据，每一个场所都维护一份实时镜像。因而，如果某一场所遭到破坏，HACMP/XD:HAGEO将自动切换和同步，可以保证生产系统在较短的时间内恢复运行。使用HACMP/XD功能，需要具备以下条件：

i.HACMP V5.1.0(cluster.es.server.rte 5.1.0.0)或以上版本 ii.结合使用ESS/PPRC镜像：

操作系统AIX 5L Java 运行环境1.3.0.15, 或以上版本 IBM ESS 微码 2.1.1, 或以上版本

IBM 2105 命令行接口（Command Line Interface，ibm2105cli.rte32.6.100.13）或者IBM 2105命令行接口（ibm2105esscli.rte 2.1.0.15）

注意：假定以上命令行接口命令安装在其缺省的目录下/usr/opt/ibm2105cli IBM 2105 子系统设备驱动程序（Subsystem Device Driver），ibmSdd_510nchacmp.rte 1.3.3.6, 或以上版本 iii.使用基于IP的镜像：没有特殊要求

5.3 基于磁盘系统的PPRC数据级容灾解决方案

本节介绍的基于磁盘系统的PPRC（Peer-to-Peer Remote Copy）数据级容灾解决方案，是灾难恢复方案的7个级别中的第六个级别，可以保证少量或无数据丢失，实现最高一级数据的实时性，适用于那些几乎不允许数据丢失和要求能快速将数据恢复到应用中的业务。此种解决方案提供数据的一致性，不依赖于应用而靠大量的硬件技术来实现。

目前业界有两种基本的基于磁盘系统的远程拷贝形式：

同步PPRC远程拷贝(synchronous writes)：来自主机的数据被写往本地连接的磁盘系统，该系统将数据转发给远地点连接的磁盘系统。只有当两个系统都拥有数据的拷贝以后，本地系统才会向主机返回一个I/O完成指示。同步远程拷贝能够在远地点提供最新的数据，但应用程序会因等待写I/O操作的完成而被延迟。由于距离的限制这种方式也叫做―同城镜像(Metro Mirror)‖

异步PPRC远程拷贝(Asynchronous Write)：来自主机的数据被写往本地连接的磁盘系统，该系统立即向主机返回一个I/O完成指示。数据在很短的一段时间(在实际中通常在数秒钟到一分钟左右)以后被送往一个远程磁盘系统。异步远程拷贝对应用程序性能的影响最小，但远程磁盘系统在数据的更新程度上与本地系统相比会有一个延迟。

单纯的异步拷贝由于线路距离较远等原因，本地磁盘和远地磁盘可能会有逻辑卷读写顺序上的差异。这种方式也叫做―全局拷贝(Global Copy)‖

在全局拷贝(Global Copy)的情况下，比如本地磁盘系统提供给主机5个逻辑卷，某一时刻主机对这些逻辑卷发起了A，B，C，D，E，5个写盘请求，本地的磁盘系统的写顺序是A，B，C，D，E。但是由于线路等原因，远地的磁盘系统在接收写请求时，收到的顺序可能是A，C，B，D，E。写盘的顺序也是A，C，B，D，E。我们假设灾难发生在这5个写操作D，B的中间部分，那么这时远地的数据C很有可能是没有意义的，甚至是无理的。

为了解决本地磁盘和远地磁盘可能存在的逻辑卷读写顺序的差异，有的磁盘系统提供带有一致性组的异步远程数据拷贝。在这种方式下，远地的磁盘系统会将先收到的写请求缓存起来(比如上面的数据C)，等到它前面的数据(A,B)到达后，再按照顺序写盘。这种方式也叫做―全局镜像(Global Mirror)‖。见下图:

IBM异步PPRC远程拷贝提供带有一致性组的异步远程数据拷贝。下面，分别针对两种方案在IBM ESS中的实施方案予以介绍。

5.3.1 同步PPRC数据级灾难备份方案

IBM的PPRC提供了实现灾难备份的方案基础。PPRC全称Peer-to-Peer Remote Copy，是以存储为基础的实时且与应用程序无关的数据远程镜像功能。PPRC的实现较为简单，是无数据丢失且具有完全恢复功能的灾难恢复解决方案。

PPRC基于IBM ESS企业级存储服务器，以逻辑卷为基本单位，通过光纤通道将本地ESS上的数据同步镜像到远端的ESS上。

为了在保证数据的即时性、完整性和系统性能之间达到平衡，PPRC提供了多种工作方式。

同步方式下:点对点远程拷贝(PPRC)是一种同步远程镜像的工具，可用于相隔距离达103公里的两个ESS系统中指定的逻辑卷。这一距离可以通过第三方提供的通道扩展器加以延长，ESS可以为所有连接的主机支持PPRC功能。

PPRC将确保如果备份卷不能被更新，那么即使源卷更新成功，整个写操作也会返回失败---保证源卷和目的卷的数据彻底一致。同步方式可以保证数据不会丢失，更重要的是数据的一致性在这种方式下能够得到很好的保证---数据的不一致意味着相关数据的丢失，此时数据库的数据安全机制无法保证数据的安全，严重时有可能造成数据库无法启动。

PPRC的同步实现机制如下图所示：

PPRC同步工作过程为：

1、应用程序将数据写入磁盘--在生产系统中的应用程序将数据写到生产系统的磁盘。

2、生产系统中的磁盘数据传输到备份磁盘--对每一个在生产系统的写操作都要将这个写操作送到备份磁盘。

3、备份机磁盘数据复制--备份磁盘复制生产系统的数据。

4、将写完的操作信息返给生产磁盘--当生产系统收到备份系统传回的已写信息之后，生产机的磁盘系统通知主机该写操作已完毕，在此之后生产系统的应用将继续执行。在同步PPRC的建立过程中，卷具有不同的状态，以保证数据的完整性。

5.3.2 异步PPRC数据级灾难备份方案

PPRC + FlashCopy数据备份方案

为了提高PPRC数据备份方案的效率，可以考虑结合IBM公司企业级存储服务器ESS的FlashCopy功能软件，采用异步方式实现PPRC数据备份。在异步工作方式下，PPRC能够在远端更新没有完成的情况下，只要本地更新成功，就可以向主机返回―写成功‖的信号。好处是：在主备机房之间的数据链路带宽成为瓶颈时，采用异步方式可以不影响主机房生产系统的性能。坏处是：

1、数据将有可能丢失；

2、在异步同步不能最终成功完成的情况下，数据的一致性无法得到保证。所以当采用异步方式时，IBM建议先采用IBM ESS的快速拷贝功能FlashCopy备份需同步的数据，再进行数据同步。

ESS的FlashCopy的使用

ESS的FlashCopy提供了一个―时间点‖（Point in time）的拷贝服务功能，从源卷到目标卷快速地复制数据。逻辑拷贝通常可以在数秒内完成，然后就释放源卷，进行正常工作，而物理拷贝操作在后台进行。在物理拷贝的进行过程中，拷贝和被拷贝的数据都能被用户使用。

IBM ESS的FlashCopy支持两个选项，它提供NO COPY选项来支持灾备的应用需求。以下的内容讨论了在移动灾备的应用环境中是如何使用这些选项的。

FlashCopy COPY选项

第二篇：异地容灾方案

某金融机构数据级 异地容灾案例

一、概述

备份与容灾是存储领域两个极其重要的部分，二者有着紧密的联系。一般来说，备份是指用户为应用系统产生的重要数据制作一份或者多份拷贝，以增强数据的安全性；容灾是用户为业务系统建立一个或多个冗余站点，达到业务不间断的目的。因此，我们可以把备份称作是“数据保护”，而容灾称作“业务应用保护”。备份与容灾中都有数据保护工作，备份大多采用近端方式，成本低；容灾则采用远程方式进行数据保护，成本较高。

大体上讲，容灾可以分为3个级别：数据级别、应用级别以及业务级别。数据级别容灾的关注点在于数据，即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏。数据级容灾较为基础，其中，较低级别的数据容灾方案仅需利用磁带库和管理软件就能实现数据异地备份，达到容灾的功效；而较高级的数据容灾方案则是依靠数据复制工具，例如卷复制软件，或者存储系统的硬件控制器，实现数据的远程复制。数据级别容灾是保障数据可用的基础，当数据丢失时能够保证应用系统可以重新得到所有数据。本案例容灾级别为数据级容灾，日后在此基础上可以进一步部署更高级别的容灾方式。

二、实施前状况及需求分析

本案例实施单位为某全国性金融机构的分支单位，在此简称A分支。该金融机构已经实现了全国性的数据集中管理（数据大集中），重要的生产数据已经集中在总部统一存储管理。而且A分支对于重要的业务中间数据在本地也有IBM 3584大型带库进行存储备份。所以说A分支针对于生产数据的备份和冗灾都有了较高级别的保障。

但对于A分支内部一些前置机数据虽然在本地也进行了备份，对于数据安全有一定的保护，但在数据容灾方面较为薄弱，由于备份数据与生产环境在同一楼内，数据较为集中，一旦发生火灾等大型灾难则对数据影响较为严重。

因此用户考虑针对于这些前置机数据部署远程的数据容灾系统。容灾地点定在25公里以外，线路采用租赁长波裸光纤，每天的数据量约为（110G），容灾级别为数据级容灾。

三、系统方案

系统结构示意图如下：

前置机IBM X3650 备份管理服务器p5TSM备份软件lanp5前置机光纤链路IBM SAN 交换机IBM SAN 交换机p5lanIBM T3200 磁带库IBM DS3400 存储DS4100前置机TotalStoragep51011121314SAN存储备份区域A分支异地容灾区域A分支机构区域A分支异地数据容灾系统结构示意图A分支异地容灾系统线路采用长波裸光纤，带宽可根据需要在线路两端架设网络设备的速率而定，根据A分支每日数据备份量（约为110G），若按100M网络线路负载80%计算，每天传输时间约为3小时。所以A分支的数据容灾系统可以采用直接将存储备份设备及备份管理服务器放置在远端的方式进行数据备份和管理。

硬件方案：在备份服务器上，本案例选用的是IBM X3650服务器，针对于备份管理服务器对运算方面要求不高，所以服务器配置单个4核2.0 CPU，为了增加本地数据存储量服务器配置了6块300G热插拔硬盘，另外服务器配置了IBM RAS II远程管理卡可以方便的进行远程控制管理，解决了服务器远程管理维护的问题。

存储及备份设备选用IBM DS3400（光纤通道）磁盘存储和TS3200（光纤通道）磁带库建立了SAN存储区域。这样为日后存储系统的扩展和备份系统实现统一管理建立了良好的平台。

备份管理软件选用IBM Tivoli Storage Manager,由于A分支的远程容灾数据为本地已经的打包好的数据不涉及数据库，所以在备份模块上只使用了最基础的文件备份模块，而且将服务器端和客户端同时装在X3650服务器上进行备份操作。

如上图所示，需要备份数据的前置机先将数据在本地打包，然后发送到远端的IBM DS3400存储上，然后再根据策略将需要永久保留的数据备份到磁带库中的归档存储池中，将只需要保存一份最新版本的数据循环保存到磁带库的循环备份存储池中。在DS3400存储上也保留了数据的最新2到3个版本，用脚本按时间对存储上备份的数据进行清理。

在远程管理方面，在远程服务器上安装远程监控软件（LINUX 系统采用VNC远程管理软件，WINDOWS系统采用远程桌面即可），再安装上IBM ServeRAID 管理软件就可以对本机和IBM DS3400存储的阵列和磁盘进行远程管理了。同时也可以使用IBM TSM备份管理软件和磁带库的管理软件对磁带库进行远程管理。这样整个系统基本上都可以在远程监管的范围内了。结合IBM RAS II远程管理卡可以进一步对服务器进行远程开关机及设置BIOS信息等操作，使远程管理更为方便。

用户使用评价：

项目使用了TSM软件结合LINUX 脚本实现了自动备份，达到了远程数据级容灾的目的，使得数据更可靠，同时也减轻了系统管理员的工作量。系统实施后达到了预先期望要求，对工程很满意。

第三篇：容灾备份建议书（推荐）

医院信息系统容灾备份建议书

一、概述

二十一世纪的医院已经逐渐发展为现代化的综合性医院，为了实现医院管理的科学化、现代化、数字化，与国际、国内信息化建设的新技术接轨，适应现代化医院的医疗、科研、教育和管理的要求，现代化的医院所建立起的信息系统(HIS)主要以一体化的临床系统、LIS系统、PACS系统，EIS系统、PIS系统等为基础，实现数据全面共享，共同形成全面的医院信息管理系统。庞大的系统必然产生海量数据，对于软件系统而言数据就是根本，任何操作、分析、结算等等都从数据库中提取。从某种意义上说，数据安全成为了现代医院信息系统安全的重中之重。一旦数据丢失，对任何一家医院来说都会产生重大的影响。

二、项目立项的必要性及市场需求分析

近几年，国家各部委对数据信息安全都有相关的明确规定！颁布了如下一系列条例，如《国家信息化领导小组关于加强信息安全保险工作的意见》，《计算机信息系统安全保护条例》、《信息安全等级保护管理办法》、《2006―2020年信息化发展战略》、《信息系统灾难恢复规范》、《保险业信息系统灾难恢复管理指引》、《银行业信息系统灾难恢复管理规范》、《民用航空重要信息系统灾难备份与恢复管理规范》、《重要信息系统灾难恢复规划指南》。在2010年11月，北京卫生局联合公安局等部门下发了《关于开展信息安全等级保护安全建设整改工作的实施方案》的通知，该通知中也明确提出了数据备份的安全等级保护，并要求需要在重点单位发挥试点示范作用。由此可见各行业已经开始注重容灾备份的重要性了！

对于关乎国计民生的医院行业，政府更是大力监管，在2011年推出的“《三级综合医院评审标准（2011 年版）》（卫医管发〔2011〕33号）”文件中的第五大点第四条就明确规定了“实施国家信息安全等级保护制度，实行信息系统操作权限分级管理，保障网络信息安全，保护患者隐私。推动系统运行维护的规范化管理，落实突发事件响应机制，保证业务的连续性。” 该部分就已经包含了容灾备份及业务连续性管理的要求，从等级保护的要求而言，二级及以上的等级保护也是要求要做备份及业务连续性管理的，还需要有应急的制度、程序流程和灾难演练。

医院信息系统运行中可能出现的突发性故障和问题

１、系统硬件故障

如数据/系统磁盘的损坏将导致数据不能访问，并进而可能导致应用进程终止或系统停机，甚至系统不能重启动；网卡的损坏可使终端用户无法访问系统服务；CPU或内存的失效则会导致系统的死机；

2、应用程序或操作系统出错

由于操作系统或应用程序中可能存在不完善的地方，当碰到某种激发事件时，应用程序非正常终止或系统崩溃；

3、人为错误

一些人工的误操作，如删除系统或应用文件，终止系统或应用服务进程，也会导致数据丢失或者系统服务的无法访问；

4、电脑病毒/黑客入侵

由于目前的大多数计算机系统直接或通过U盘等硬件设备间接地连接在网络上，若缺少有效的防范机制，很容易遭受病毒的感染或黑客的入侵，轻者数据被损坏，重者系统瘫痪；

5、自然灾害

由于一些意外的不可抗拒的因素，如雷击、火灾、洪灾等导致的计算机系统破坏，将会使一般系统的恢复非常困难和耗时，导致业务系统长时间的中断。

6、正常的停机

主要指计划内的系统升级、安装软件等过程。

三、相关领域国内外技术现状、发展趋势及现有工作基础

备份的历史可以追溯到上世纪50年代，那时候国外一些公司就开始对自己的重要数据进行备份保护。但那时候重要数据以纸质媒体为多，电子数据只有一小部分，他们将其副本放置在另一个相对安全的地点存放，防止灾难事故对数据的损坏，这便是容灾备份的雏形。

70年代的时候随着电子数据越来越多，这种类似的数据容灾保护形式越来越普遍。到了80年代，美国市场上已经有了上百个专业公司。一些视数据为生命且数据量巨大的金融公司开始广泛的采用这些公司提供的异地灾备中心存储解决方案。

1983年，政府开始对数据安全进行足够的重视。美国联邦货币监管中心要求金融机构起草了有关数据灾难备份及恢复的指导性文件，主要强调数据库的备份和恢复，通过运送备份磁带到专门的存储地实现安全。此文件一直使用到1989年，联邦货币监管中心有了更详尽更成熟的一套数据安全相关资料

进入九十年代，计算机的迅速发展和普及在大大的提高了生产效率的基础之上也给再灾难行业带来了新的市场和机遇，更过容灾备份厂家和产品有了用武之地。

九十年代的中后期（2000年前后），出现了业务连续性的概念，并开始逐渐取代单纯的灾难恢复。与灾难恢复相比，业务连续性不只局限于传统的IT系统，而是涵盖了包括人为操作失误、网络故障、流程中断等。

2000年以后，随着国内各行业信息系统的快速发展，特别是银行、证券、保险和政府等行业业务大集中速度的加快，企业的技术风险也相对集中。一旦发生灾难，则将导致政府和企业所有分支机构、营业网点和全部的业务处理停顿，或造成企业客户数据的丢失。如何防范技术风险,确保数据安全和业务连续性，已成为企业急需面对的课题。

虽然国内的信息化建设足足比国外晚了近五十年，但是一直是用一种飞向的速度在追赶。基于此国家相关部门借鉴国外的容灾备份理念，对加强信息安全保障工作十分重视，先后出台了多项有关信息安全保障措施。如中国人民银行于2002年8月下发了《关于加强银行数据集中安全工作的指导意见》，指出：“为保障银行业务的连续性，确保银行稳健运行，实施数据集中的银行必须建立相应的灾难备份中心。” “业务连续性计划应报中国人民银行备案。”。

2003年8月,中办发[2003]27号文件——《国家信息化领导小组关于加强信息安全保障工作的意见》规定：各基础信息网络和重要信息系统建设要充分考虑抗毁性与灾难恢复，制定和不断完善信息安全应急处置预案。“谁主管谁负责，谁运营谁负责”。

2004年9月，信安通（国家网络与信息安全协调小组办公室）发[2004]11号文件——《关于做好重要信息系统 灾难备份工作的通知》：提高抵御灾难和重大事故的能力，减少灾难打击和重大事故造 成的损失、确保重要信息系统的数据安全和作业连续性，避免 引起社会重要服务功能的严重中断，保障社会经济的稳定，要求“统筹规划、资源共享、平战结合”！

同年2004年9月，开始起草《信息系统灾难恢复指南》初稿；

2004年10月22日，成立了由国信办领导、8大重点行业和5个政府单位专家及 万国数据服务公司组成的《指南》工作组；

2005年4月，国信办以文件的形式下发了《信息系统灾难恢复指南》；

2006年5月，信安标委专家讨论，按照国家标准的要求调整《指南》的内容，形成征求意见稿；

2006年6月20日，召开信息系统灾难恢复国家标准工作组会议。根据意见，《信息系统灾难恢复指南》更名为《信息系统灾难恢复规范》；

2006年9月12日，信安标委召开WG7工作组标准项目投票工作会议，一致通过 成员单位投票，经过对《规范》的再次修改，形成《规范》的送审稿修改稿。

2007年7月30日，《信息安全技术 信息系统灾难恢复规范》发布；2007年11 月1日实施，将灾难恢复能力分为七个等级，成为国标。

由此可见，信息系统安全和灾难备份已经引起了国家、社会、企业的高度重视，灾难备份业务的发展是客户保持业务连续运作的需要，同时也是社会的需要和政策法规的要求，是市场发展的必然。

在这个大环境下，国外的厂商蜂拥而入。Veritas、CA、Falconstor(飞康)、Bakbone、Commvault这些软件公司巨头很快的占据了国内容灾备份市场的半壁江山。而更早进入中国市场的硬件巨头们，眼馋这块大蛋糕，也很快的伸出刀叉，通过自主研发或者兼并收购等模式很快的扩充了自己的产品线，提供软硬结合的产品，通过软件为硬件增值，通过硬件为软件铺路。如IBM的TSM（Tivoli Storage Manager）系列；HP的DP（Data Protector）系列；EMC收购Legato以后推出的Network系列。这些99%来自美国的产品，很快的瓜分了国内的容灾备份市场。如此这般，国内数据安全的命脉竟几乎全部掌握在了国外产品的手中，我们的使用者竟心安理得，殊不知这种潜在的威胁将是致命的。当年美伊战争时，伊拉克从法国买的防空系统打印机都被美国植入了木马芯片，以至于在后来的“沙漠行动”中，美国飞行员像在家里玩电子游戏一样自由自在地来来去去。

历史总会重演，如果我们不引起足够的重视，下一个目标可能就是我们。何况美国现在在抵制我国的华为、中兴产品，认为这些产品威胁到了他们的信息安全，而我们却还在疯狂的购买iphone，肆无忌惮的使用国外的软件来备份自己的核心数据，这会让我们一不小心就成了卖国贼。

也许有人会说，是因为国内的软件不争气，我们才使用国外的产品。但这只不过是一种推脱责任的借口。想我中华泱泱大国，民间高手无数，且近几年在核高基政策的支持和扶持下，软件产品飞速发展，已经产生了一大批的高新企业和优秀软件。榆林三院信息系统容灾备份现状

我院信息系统建立在Windows 2008操作平台上，现有两台台服务器，其上运行了HIS、PACS等系统。这些服务器只作了单一的本地数据存储，并在指定的时间通过数据命令将数据备份在另一台PC机中。操作系统是Windows 2008R2 64bit，数据库系统是Oracle。比如医院HIS和PACS服务器每天晚上10：00通过ORACLE EXPORT将HIS数据导出成一个DMP文件。如果本地服务器出现硬件故障（CPU、LAN、POWER、FAN等），都将导致医院部分日常业务中断，对于依赖计算机管理水平高的医院来说，很多的业务将无法开展。当ORACLE数据库出现故障时，对于时间要求严格、病人数据大的医院出现短暂的停顿都无法忍受。如果采用上面所说将DMP文件也入回数据库中，首先要修复硬件，重装操作系统，至少需要数个小时甚至几天才能恢复，并且要丢失好一天的业务数据。

四、项目计划目标及主要研究内容

理想的容灾解决方案通常都具备以下内容

第一、数据的实时备份。RPO(恢复到目标)=0，确保数据零丢失；

第二、数据持续回退，且保证回退点数据完整可用。以便找回误删除的数据及在数据不完整时能恢复数据到最近的完整状态；

第三、本异地容灾。将数据实时备份到同城以及异地机房，降低本地机房出现大的事故时候对医院的损害。

第四、业务连续性管理。原系统不论什么原因出现故障停止对外服务时，备份系统可以在很短的时间接替原服务器对外提供服务，让系统恢复正常，即RTO(恢复时间目标)≈0,以免影响医院信息系统业务。

根据对医院环境和应用特点的分析，我院通过整合存储架构、采用群集高可用系统、核心数据的集中备份和异地备份、系统容灾快速恢复等多种数据安全保护方式，完全消除上述隐患，并可做到系统平滑升级和在线扩容。

具体而言，我院的信息系统的主要需求在以下几个方面：

1、高性能和高可靠的集中存储系统：由于有大量的并发访问，需要对目前的单机存储架构进行改造，构建一个高效安全的专用存储网络，可以把我院的信息系统整合为FC SAN存储架构。存储设备采用具备高性能和高可靠性的光纤接口的磁盘阵列，实现数据的集中存储。磁盘采用高可靠的SAS磁盘或FC磁盘。

2、存储和备份空间容量要求: 针对上述所有应用系统的服务器实现集中存储管理，考虑到3-5年的数据增长，集中存储设备的容量要求达到：医院需要3TB的存储容量；集中备份需要至少5TB的可用空间。

3、数据的高安全性：由于HIS、PACS等数据是绝对不能丢失的核心业务数据，因此需要对核心业务数据做冗余的在线和离线数据保护，构建一个完整的数据统一备份系统，将整个网络中的所有关键数据库数据进行集中备份，建立统一的备份策略，自动备份数据。针对上述的数据库服务器的数据实现在线备份（包括对SQL、Oracle等主流数据库的在线备份），数据集中备份到虚拟磁带库中，这样在主存储设备中的数据出现损坏或丢失的情况下都能够迅速从虚拟带库中得以恢复；另外，对于需要长期保存的数据，可以通过备份到与虚拟磁带库直接连接的一台物理磁带库中，实现离线的归档。整个数据的备份和恢复，以至于将来可能的数据迁移、数据复制等一系列数据管理操作，都是通过备份软件来统一管理。因此需要采用技术领先，具备图形化操作、全中文管理界面，以及支持断点续传（尤其是数据库的断点续传）和真正合成全备份的备份软件。系统设计目标

为上述应用系统建设集中存储和备份网络，以及异地的数据容灾中心，实现数据的统一安全管理，针对不同应用类型和数据类型提供多重的数据安全保护

手段，在此基础上确保核心应用的7*24小时连续运行。

存储系统建设目标：使用高性能、高可靠性的大容量存储设备，进行存储整合，通过建立FC SAN存储基础架构,使数据集中存储，建立一个高效、稳定、可靠的存储网络、数据存储中心和安全的管理平台。备份系统建设目标：构建一个完整的企业级数据备份平台。将整个存储网络中的重要数据进行集中备份，建立统一的备份策略，备份作业自动化，实现数据的在线备份和离线归档。在备份设备中使用高速的备份介质，减少日常备份/恢复作业对系统可用性及性能的影响，实现快速的备份/恢复机制。系统设计原则

1、存储系统的设计原则

 提高存储空间利用率，节省总体数据存储成本，有效提高投入产出比。

 数据整合，进行统一的管理与应用，降低管理员的工作量以及人力开支成本。 磁盘阵列的读写速度与稳定性要高。 支持灵活安全的在线扩容。

 采用多种RAID模式使设备更加可靠，保证有磁盘损坏时不影响数据。

 专用的外置存储设备支持控制器、电源、锂电池、风扇等关键部件的热插拔，故障部件可以在线更换；  可以实现分级存储功能；

备份系统的设计原则

 可以采用专用的备份网络，避免业务系统网络和备份网络的互相干扰。

 针对特别的应用，可以提供零窗口和LAN-Free的备份方式。 支持介质复制的断点续传，减少网络带宽，提高网络带宽的利用率。

 数据的备份采用D2D2T策略，通过在线的磁盘阵列，近线的虚拟磁带库，离线的物理磁带库，共同完成信息生命周期的数据安全基础架构。

集中存储系统具体描述

对于医院的数据中心，本方案将构建一套FC SAN的存储架构，将用户的关键应用系统数据（如： HIS服务器，PACS服务器）集中存储在一台光纤磁盘阵列（作为一级存储设备）中，该磁盘阵列配置双机头，确保了存储设备的高可靠性。磁盘阵列可以实现FC磁盘和SATA磁盘的混插，数据可以保存在高稳定性的FC磁盘中，将来可以考虑上SATA磁盘，实现数据在一套设备内的分级存储。

在主机与存储的连接链路上，接入SAN的所有主机，可以配置2块HBA光纤适配卡，同时连接两台光纤交换机，确保任何一条光纤链路中断均不会影响用户的正常业务使用，完全消除了单点故障。统一的集中化存储

在本次方案中，根据我院目前的存储空间规划，以及我院未来三至五年内的需求，给我院配置3TB的存储可用空间用于SAN的数据集中存储，配置质量和性能都比较好的FC硬盘来存放数据。同时，为防止磁盘阵列自身出现严重的物理故障导致数据丢失，还可以另外选配两台磁盘阵列，两台磁盘阵列之间通过卷复制功能来实现两台存储设备之间的数据同步。

对于以后需要增加的其他应用服务器，将来可以通过增加光纤HBA卡的方式，接入FC SAN。SAN存储架构

SAN存储架构具备良好的扩容性，未来可以方便地升级与维护。当信息系统需要扩建时，只要把新的设备，接入到SAN架构中，便可以使用集中存储提供资源，所以，SAN架构，可以作为一个基础的设施来建设，它可以充分地保护投入的成本，为日后系统的扩容，升级打下了良好的基础。SAN存储架构的特性：

1.可实现大容量存储设备数据的共享。

2.可实现高速计算机与高速存储设备的高速互联。3.可实现灵活的存储设备配置要求。4.可兼容以前的存储设备。5.提高了数据的可靠性和安全性。6.避免了数据的“信息孤岛”效应。数据备份与恢复的跨平台性和可靠性

现在的备份软件已经比较成熟，如CommVault,Symantec,NetStor Backup Express等等

数据备份恢复软件的跨平台性表现在：

 能把备份UNIX文件恢复到不同版本的UNIX系统；

 能把UNIX的备份文件恢复到Windows、FreeBSD、HP-UX、IRIX、Linux、Solaris、Tru64操作系统上。

 能把备份文件恢复到不同版本的Windows系统，即在NT、2000、XP、2003之间实现跨版本恢复。

 能把Windows的备份文件恢复到SOLARIS、FreeBSD、HP-UX、IRIX、Linux、Solaris、Tru64异构平台的操作系统上。数据备份恢复软件的可靠性表现在：

 能实现备份、恢复及备份数据转存的中断再继续（断点续传功能）。 能对Oracle进行断点续传备份，确保备份成功率。

 支持并发数据流，加速备份过程，充分利用多磁带驱动器的磁带库设备。

 能对增量备份、差量备份实现智能的、快速的“一次过”恢复，确保一次性读入要恢复数据的最新版本，极大提高恢复效率

本方案采用现在最先进的FC-SAN架构，实现了高速计算机与高速存储设备的高速互联，实现了信息的集中存储，避免了信息孤岛的形成，同时，为以后医院信息化的建设打下了基础。

完整的备份系统，可以保证数据的最大安全性，从数据的产生，数据的备份，到长久数据的归档，D2D分级存储架构完成了一个信息的生命周期。同时，数据实现自动备份，减少人工参与，降低医院的管理成本，有效地保障了医院数据的安全

五、技术、经济效益、市场风险分析

在现代医院越来越依赖计算机来对医院的业务的开展和管理的今天，数据的安全无疑是重中之重，而数据的安全又是建立在存储系统的基础上，所以，一个架构完整、合理、科学的存储系统，是实现现代医院信息化过程中必须走的重要的一步。

高效的容灾备份系统和主-备服务器的快速切换模式可应用于所有类型数据备份系统，有效提高数据服务器的工作效率，大大降低数据信息丢失的风险成本。全自动化模式提高了备份系统的稳定性，同时降低了医院管理成本。

六、申请单位简况

榆林市第三医院是市委、市政府批准成立的一所综合性、非营利性公立医院。医院位于东沙城区金阳小区旁边，环境优美、交通便利、设备先进、功能齐全、技术力量雄厚、服务热情周到，是充分体现“以人为本”的综合医疗服务机构。

医院现开放床位302张，设置有综合内科、综合外科、骨科、妇产科、儿科、手术麻醉科、急诊科、康复理疗科、中医科、皮肤科、眼科、口腔科、耳鼻喉科、感染科等14个临床科室；影像科、检验输血科、药械科、功能科（B超室）、病理科、心电图室、脑电图室、消毒供应室、内镜室、门诊部等10个医技科室。现有干部职工280人，其中专业技术人员243人，特聘专家13人，副高以上26人，中级35人，本科78人；行政及后勤管理人员37人。

拥有全进口美国GE16排螺旋CT机、美国GE DR、美国GE数字胃肠机、腹腔镜、富士激光相机、西门子全自动生化分析仪、血液分析仪、飞利浦高端彩色B超机、德国进口高端呼吸机、麻醉机等大型医疗设备。

医院始终坚持贯彻执行党的卫生方针、政策，坚持“看病明白、检查准确、合理用药、花钱清楚、一切为了患者”的服务理念，着力打造特色服务品牌，不断提升诊疗技术水平。我们以精湛的技术、创新的理念、全新的面貌，竭诚为患者提供安全、高效、便捷、严谨的医疗服务，今天的榆林三院将以新起点、高标准、跨越式的发展创造辉煌的业绩，为人类健康事业的发展而努力奋斗！该项目由榆林市第三医院信息科负责实施。

七、必要的支撑条件、组织措施及实施步骤

暂定项目预计于2015年11月至2016年2月之间完成项目所需的网络环境与硬件设备及项目实施场地的建设。于2016年2月至2016年5月之间完成项目的关键技术，达到项目技术指标；同时完成项目实施内容记录与所有相关技术问题的扩展总结

八、计划实施进展、预算及来源渠道

项目总投资19万，拟申请政府补助10万，单位自筹9万。其中硬件采购17万，项目实施费用2万

详细配置参数列表

序号 采购内容

HBA卡

技术规格或性数量

能指标 ★HBA卡：每台配4个 套HBA卡：2个，光纤线3M LC-LC2条 ★售后服务：提供原厂3年保修服务,中标方须在签订合同前提供原厂商服务承

报价

12000

诺函 备份服务器(X3650M4)

CPU：E5-2603 1台 @1.80GHZ

1.80GHZ(2处理器）

内存：8GB 网卡：Intel I350 Gigabit Network

Connection(4块)

硬盘：2TB SATA（3块）★HBA卡：每台配套HBA卡：2个，光纤线3M LC-LC2条 可管理和维护性：光通路诊断，集成IMM(可选的Virtual Media Key支持Remote Presence)系统

支持的操作系统：MS Windows Server 2008、Red Hat Linux 和 SUSE

Linux、Vmware ESX Server、标配windows2008 服务

★售后服务：提供原厂3年保修服务,中标方须在签订合同前提供原厂商服务承诺函

35000 3 磁盘阵列(DS3500)

★品牌：与服务1台 器同品牌产品 控制器：配双控制器，4个6Gbps SAS主机接口，Cache具备断电保持数据完整功能。

支持SAN：支持SAN光纤通道交换机、支持1GBps/2GBps/4GBps

★主机接口：≥8个，8Gbps FC 主机端口

★数据Cache：每个控制器≥1G ★存储容量：本次硬盘配置数量≥10块，300G以上 3.5" SAS 15k rpm 最大驱动器数量：≥96个 图形化管理软件：配置图形化管理软件 多通路容错及动态负载均衡功能：支持 安全访问控制：防止LUN被未授权主机访问。支持Cache分区技术：支持 快照：支持 支持的操作系统：Microsoft Windows 2003, Sun Solaris, IBM AIX, Linux, Novell Netware。

99000

高可用性：完全的硬件冗余：处理器、电源、风扇、适配卡等都提供冗余，并保证在某硬件出现问题，能够进行自动切换，不出现单点故障。4 5 备份软件（Symantec Backup Exec Leo 11D Win）系统集成 要求 ★服务要求：提供3年7×24小时原厂上门保修维护

Back Exec沿袭最初在赛门铁克Veritas NetBackup中使

用的针对虚拟环境的获奖技术，通过单一管理控制台为VMware Infrastructure、Microsoft Windows Server 2008 Hyper-V以及传统的物理系统提供全面的数据保护，同时降低成本，并提高多重虚拟和物理系统的管理。

工作内容

1、说明:数据文

件大小在20G左右进行平滑迁移。★

2、进行数据模拟迁移（根据设计的数据迁移方案，建立一个模拟的数据迁移环境，它既能仿真实际环境又不影响实际数据，然

套30000

硬件总价*10% 1 后在数据模拟迁移环境中测试数据迁移的效果。数据模拟迁移前也应按备份策略备份模拟数据，以便数据迁移后能按恢复策略进行恢复测试）

3、测试数据模拟迁移（根据设计的数据迁移测试方案测试数据模拟迁移，也就是检查数据模拟迁移后数据和应用软件是否正常，主要包括：数据一致性测试、应用软件执行功能测试、性能测试、数据备份和恢复测试等）

4、准备实施数据迁移（数据模拟迁移测试成功后，在正式实施数据迁移前还需要做好以下几个方面工作：进行完全数据备份、确定数据迁移方案、安装和配置软硬件、制定应急方案等）

5、正式实施数据迁移（按照确定的数据迁移方案，正式实施数据迁移）测试数据迁移效果（按照数据迁移测试方案测试数据迁移效果，并对数据迁移后的数据库参数和性能进行调整，使之满足数据迁移后实际应用系统的需要）

6、移植系统应用软件(将实际应用系统的应用软件移植到数据迁移后的数据库系统上，并使之正常运行)

7、正式运行应用系统(在正式实施数据迁移成功并且数据库参数和性能达到要求后，就可以正式运行应用系统，并投入实际使用)

8、数据库升级到Windows+Oracle 11g。

9、数据库迁移时间控制在2～3小时内，不能超过4小时，须提供详细的升级、迁移方案。

10、数据库迁移时能继续支持医院业务的正常运行，包括门诊业务(如门急诊收费、门诊药房、门诊诊间、皮试系统等),及重要的住院业务(如住院收费、医嘱等)，须提供详细方案来满足迁移要求。

第四篇：容灾备份解决方案

2010-8-11 容灾备份系统简介

一、项目背景

随着计算机技术的快速发展，每个企业都在大量的使用计算机处理自己的核心数据，这些数据往往是企业生产经营必不可少的部分。依赖这些数据的计算机系统的停机往往会造成企业生产经营活动的停顿，给企业造成巨大的损失。所以，可以说，这些数据是企业的生命核心。企业的IT管理员为了保证生产经营活动的持续运行，不断的加强对系统和数据的保护，如使用基于双机的高可用技术，磁盘阵列系统的RAID技术等。然而，人们依然无法回避由于磁盘故障，人为失误，应用程序的逻辑错误，自然灾害等原因带来的系统停机或者数据丢失。所以，数据备份作为数据保护的最后一道屏障，必不可少。

二、功能介绍

实时保护：连续捕获、实时备份数据变化，全过程保护数据安全。实现真正的持续性数据保护（CDP），无需设置任何备份时间点，居国内外同类产品领先地位。

完善备份：同一软件可实现“数据库双机热备＋接管”、“本地实时灾备”、“异地实时灾备”，全方位保证数据库安全。

任意回退：可按任意操作步数或时间点进行数据回退。主数据库遭到破坏时，备份数据库可将主数据库回退到损坏前最后时刻的状态，且能保证事件的完整性。快速恢复：主数据库或表损坏，从站自动检测，提示回退的步数。恢复1个G数据库在3－5分钟。

增量备份：只备份变化部分，在保障备份数据安全的同时减少备份的工作量。

错峰机制： 在系统负荷极大时暂停备份以免系统瘫痪，当系统负荷下降时备份暂停期间的数据，并重新开始实时备份。

低耗资源：对主数据库压力小，系统采用消息机制，只有灾数据库发生变化时才触发，只传数据库的变化部分，不同于文件拷贝，和数据表的轮询。

操作简单：自主开发设计，着重考虑国内用户使用习惯，安装、设置非常简单。

维护方便：启动或连接中断后重连时，自动校验主从站数据，保证数据准确。

加密传输：底层通讯采用自主研发的通讯平台，所有数据都是用加密数据包进行数据交换，充分保证数据安全。

高性价比：在各项性能领先的同时，价格远远优于国外软件。当选择不接管的热容灾备份方式时，从站可采用低档Server或高稳定性的PC（有足够的存储空间即 2

可），从而实现极低的总体成本。

通用性好：不对数据库中的应用做任何修改。与数据库中表的结构无关，且无任何限制。对数据库备份完整：如TABLES（表）、DIAGRAMS（关系图）、VIEWS（视图）、USERS（用户）、ROLES、RULES等。

三、解决方案优点

能够实现双数据库的实时同步，能够保证双份数据库的实时一致性，如果主生产数据库失败，备数据库库服务器随时可启用为主数据库服务器。不再需要介质恢复的过程。

多节点存储冗余体系

热备方案要求最少有双份数据库，不但心生产数据库崩溃，磁盘硬件崩溃，而造成数据库不可用问题．多份数据源才是真正的冗余体系，真正消除了数据库系统管理人员为存储单点故障的后顾之忧!不存在物理介质恢复时间问题

因为双数据库的实时同步，保证双份数据库的一致性，如果主生产数据库失败，备数据库库服务器随时可启用为主数据库服务器．不存在介质恢复时间．这与双机热备比较，完全消除掉备份恢复这一个过程。

同步时间完全实时

主数据库与从数据库可以做到实时同步，消除了备份软件中的间隔备份丢失数问题．同时提供了完全不丢失数据模式和丢失秒内业务数据校正方式。

解决了数据误删除恢复问题

与HA,CDP软件比较，当数据库管理人员遇到意外误删除求助，热备系统可以提供事务级别的按步数或者时间点的回退动作，确定记录，恢复记录.不需要像传统备份软件为了一个记录而恢复整个数据库。

数据库异地容灾问题

完全支持异地数据同步，支持断点续传，数据一致性校验。

四、解决方案

（一）1、备份方案

（一）示意图：容灾标准版（一主一从）

备份方案：

说明：

1：在1号Server系统中安装，设置成主站。2：在2号Server上安装，设置成从站

3：正常运行后，2号Server能够实时备份1号Serve中的数据库的数据 4：在1号Server宕机的情况下，2号Serve能接管主服务器的IP和机器名，对外提供所有的服务，保证业务不间断

5：当1号Server修复后，能快速将2号Server上数据恢复到1号Server中。

能实现的效果及主要功能：

1)将主服务器上的数据实时智能的备份到从站备份服务器里

2)如果数据库遭到病毒破坏或者误删除可用数据回退进行解决；回复的任意时间点的数据

3）主站宕机或者磁盘柜损坏，备份服务器可接管主站服务器对外服务，保证客户端的正常运行

2、备份方案

（二）示意图：容灾（一主两从）版本

S2备份服务器S1主数据库服务器 终端 S3备份服务器办公楼 XX楼

说明：

1)2)3)4)主站服务器（S1）安装标准版软件设置成主站；

从站备份服务器（S2）安装标准版软件设置成从站1，作为备份服务器1； 从站备份服务器（S3）安装M标准版软件设置成从站2，作为备份服务器2； 正常运行后，从S1能够同时实时备份主站或磁盘柜中的数据库数据到S2、S3；

能实现的效果及主要功能： 5)在S1或磁盘柜损坏的情况下，S2能接管S1对外提供服务，保证客户端的正常运行，当S2亦出现意外事故时，S3能接管S2对外提供服务，保证客户端的正常运行；

6)当主机房损坏设备完全修复后，能快速将S2或者S3上数据恢复到S1存储中。3)将数据中心的SQL数据库中的数据实时的备份到从站服务器中； 4)如果数据库遭到病毒破坏或者误删除可用数据回退进行解决； 5)如果主站宕机或者磁盘柜损坏，备份服务器可接管主站服务器对外服务，保证客户端的正常运行。

3.方案

（三）方案示意图：集群版（两主一丛）

针对双机磁盘柜的异地容灾：

主数据服务器双机环境 磁盘柜 终端 双机 集群 备份服务器１号２号 实时备份 数据回退 接管 异地容灾 ３号server

说明：

1、在1、2号server组成的集群系统中安装 FOR CLUSTER版设置成主站；

2、在3号server上安装 FOR CLUSTER版设置成从站；

3、正常运行后，3号server能够实时备份集群磁盘柜中的数据库数据；

4、在集群中的1、2号机器同时宕机或磁盘柜损坏的情况下，3号server能接管集群对外提供服务，保证客户端的正常运行；

5、当主数据服务器被损坏设备修复后，能快速将3号server上数据恢复到集群存储中。

能实现的效果及主要功能：

1）避免了双机集群的磁盘柜的单点故障，有双份数据安全。2）数据库遭到病毒破坏或者误删除可用数据回退进行解决；

3）主站同时或者磁盘柜损坏，备份服务器可接管主站服务器对外服务，保证客户端的正常运行。

4.方案

（四）方案示意图：集中备份（多对一）

数据服务器 业务数据 办公server备份中心 办公数据 业务server１号２号财务server实时热备接管回退管理server异地备份集中备份ＸＸ server 管理数据 ３号Ｘ号 XX数据

说明：

1、在各个主数据服务器系统中安装，设置成主站；

2、在备份中心的备份服务器上安装，设置成从站；

3、正常运行后，备份中心能实时备份数据服务器的数据库数据；

4.任一主服务器的数据丢失后，都可以从备份服务器迅速的给主服务器恢复数据。

能实现的效果及主要功能：

1.可以把各个业务服务器数据库的数据实时智能的备份到数据中心的服务器里，当任何一个主业务服务器的数据丢失时，都可以从数据中心的服务器里进行快速的恢复。

5.方案

（五）方案示意图：集中备份（本地做一对一，异地做多对一）

说明：

1：在各主服务器SERVER 1-N中安装设置成主站，在SERVER1’ –SERVERN’中安装设置从站，主从站通过数据库保镖进行实时备份，当本SERVER 1-N出现问题后，对应的SERVER1’ –SERVERN’可以进行接管或恢复。

2：SERVER作为集中备份服务器，将SERVER 1-N中的数据实时集中备份到SERVER内，即使本地数据丢失，也可以从数据中心取回。

能实现的效果及主要功能：

1.可以实现本地的数据实时备份和接管，当主服务器出现宕机时，可以迅速的用备份服务器接管主机提供对外的服务，保证业务不间断。

2.当主服务器本地出现意外灾难，数据全部丢失后，可以通过远程的中心服务器恢复数据，保证了数据的安全。

五、容灾容灾备份系统能实现的效果和功能

1．能实现对主服务器上的数据库里的数据进行实时智能的备份，保证了数据的安全，一旦出现数据丢失或破坏，可以迅速的从备份机上把数据恢复回来。第一次做个全备份，把数据全部备份到备份机上，以后每次只做增量备份，把变化的数据做实时的备份，节省了备份空间，提高了备份效率。在备份时对服务器的性能没有影响。

2．当主服务器出现意外宕机时，备份机可以立刻接管主服务器的IP，提供对外的所有服务，保证了核心业务连续性，可以提供365天7*24小时的业务不间断的保护。

3．整个备份系统具有高容灾性和可扩展性，以后随着数据量的增加也可以增加磁盘阵列等。

4．可以做到异地备份，真正的做到了有备无患。

第五篇：数据中心容灾备份方案

数据保护系统

医院备份、容灾及归档数据容灾

解决方案

1、前言

在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化 HIS、LIS 和 PACS 等系统是目前各个医院的核心业务系统，承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。

随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于 15 年；住院电子病历保存时间自患者最后一次出院之日起不少于 30 年。

2、医院备份、容灾及归档解决方案

针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾

2.1 数据备份解决方案

针对于医院的 HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。

备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。

客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件 标准客户端,通过这个客户端完成每台服务器的 LAN 或 LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。备份介质层（内置虚拟带库）：主流备份介质有备份存储或虚拟带库等磁盘介质、物理磁带库等，一般建议将备份存储或虚拟带库等磁盘介质作为一级备份介质，用于近期的备份数据存放，将物理磁带库或者光盘库作为二级备份介质，用于长期的备份数据存放。

2.2 应用级容灾解决方案

实时保护，可实现对医院信息系统中核心业务系统的持续数据保护。在核心业务系统应用数据写入被保护服务器自身存储的同时，写入存储设备中，颗粒度到秒级，最佳情况下可实现零数据丢失，通过镜像功能保证连接的磁盘阵列中的数据与被保护的数据完全一致。同时，利用截获每个写I/O 功能并进行记录，并且可基于时间点的快照进行回滚，此功能能够在被保护服务器发生逻辑错误时，快速有效地进行每 I/O 节点或快照点的挂载，避免逻辑错误造成的数据损坏。当存储系统宕机等灾难发生时，采用快速挂载功能，可以最快在分钟级别内迅速恢复前端应用或数据库服数据功能，保证业务的连续性。

分流器：截取主机写操作(块级别), 主机每次对被保护磁盘的写操作均被镜像写入到镜像数据写入过程在主机的主存储读写路径之外。

数据卷：保存主机分流器写入的所有数据。

记录卷和一致性代理：保存主机分流器写入的 I/O 记录根据应用特点 , 通过技术中的一致性代理实现对 ORACLE、MS SQL 等数据库在保存应用数据一致性快照使数据能够快速恢复到任意 I/O 记录。2.3数据系统长期归档解决方案

可通过高级备份功能，把电子病历、PACS 影像等数据备份到内置空间后，归档一份到光存储中，通过光存储的可长期保留特性，实现数据的长期保留（最长可到 100 年以上），满足法规要求。

2.4数据系统容灾解决方案

数据保护系统内置灾备功能，可实现数据及应用级别的容灾，可支持一对一，多对一等多种拓朴架构，系统可互为源端及目标端，完成异地备份、恢复功能。

1）数据级容灾：

备份数据保存在设备中，各备份点的数据可独立管理，可实现异机恢复，提高数据的安全性。

2）应用级容灾：

数据保护系统的 CDP 功能把数据持续保护在本地设备时，并可把本地CDP 数据复制一份到异地，CDP 的卷可以直接在异地直接挂载使用，结合虚拟机功能实现应用级容灾。

3、方案优势

数据保护系统提供的数据备份、CDP 及归档功能一体解决方案，满足医院信息系统的数据安全、应用级容灾及法规要求（电子病历数据长期保存的要求）的业务需求，解决方案优势如下：

1）软硬一体化结构，数据保护系统是多功能于一体的数据保护设备。包含了备份、CDP、存储（FC、ISCSI 及 NAS）及数据归档等多种功能，更加经济实用。并且部署简单，插入网线后进行简单配置后即可开始使用。

2）支持 FC、千兆及万兆网络等链路，灵活部署。

3）在同一台设备支持部署定时备份、CDP 功能，针对不同应用级别提供不同的保护方式。

4）具备远程复制功能，两台以上的设备可以实现远程复制，任意两台设备都可以作为发送端与接收端进行相互的远程复制，实现异地容灾，使数据更加安全。

5）具有高级备份功能，能实现 PACS 等大量的非结构化数据的不打包备份，可实现 100TB 级别以上的非结构化数据的光盘库出库归档，同时采用高级备份时光盘库恢复可通过备份系统和光盘库直接恢复等多种方式恢复方式，更加安全可靠。

6）运维简单，本方案采用一体化部署，提供统一的运维界面，用户操作简单，备份归档自动化完成。同时也提供完善的系统报告，方便客户使用。