IBM容灾白皮书

来源：互联网发布：怎样把网络视频下载编辑：程序博客网时间：2024/04/29 19:08

第一章信息—企业的财富与麻烦 前言 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 - 业务连续性而不仅仅是 Disaster Recovery - "灾难"恢复。因为过去的"灾难"恢复计划并没有强调全局性及对整个市场的影响，而如何维持业务的连续运作将成为企业运营风险评估中至关重要的一环。事实证明，只有对数据存储备份制定完备、持续且可执行的容灾计划，特别是业务连续计划，才能为人们提供万无一失的数据安全保护。

严格的说，容灾计划包括一系列应急计划，如业务持续计划(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关注在中断期间和之后维持机构的业务功能。业务功能的一个可能的例子是工资的支付处理蚩突У男畔⒋怼CP可以专门为某个特定的业务处理编写也可以涉及到所有关键的业务处理。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数据丢失率，被认为是灾难恢复的最高级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储和完全的网络切换能力，当发生灾难时芄惶峁┛缯镜愣涸仄胶夂妥远低彻收锨谢还δ堋?/p>

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.2七层灾难恢复解决方案

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

3.2.1恢复的7个层次

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

图8. 三者的平衡关系

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

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

图8. 三者的平衡关系

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

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

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建立可靠的系统

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

1 流程方面的预防

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

2 物理方面的预防

从场所的建造就开始为灾害做准备，包括为建筑物配备特殊设备。如为不同的设备配置火灾保护。这些特殊的考虑包括：计算机区域设置，火灾侦测装置和灭火装置，记录保护，空调设备，热敏和通风设备，电子供应系统和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）将确定的方案提交给评估组

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

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

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选项

对于一般的客户应用，需要生产数据实时的时间点物理拷贝。这样的应用示例包括：日常重要卷的备份、日常报表生成、数据仓库和数据挖掘的应用等。FlashCopy COPY选项能够在磁盘存储设备中产生一份生产数据的真实时间点拷贝。该选项可以满足以下的应用需求：

1.在磁盘存储设备中保存生产数据的一份时间点拷贝的业务需求。这方面的例子是日常工作系统的备份。
2.生产数据的时间点拷贝将被多个应用重复使用，特别是对每日的结束处理和报表生成。
3.生产数据的时间点拷贝将被某些统计分析类应用，如MIS或数据挖掘应用的频繁使用。

无论是什么原因，只要是需要生产数据的物理拷贝，就可以使用FlashCopy COPY选项来进行支持。对于该选项而言，所需要的磁盘空间容量是需要拷贝的源磁盘容量的总和。

下图对FlashCopy COPY选项进行了说明。请注意，生产数据的一份真实拷贝是为其它应用的使用而产生，这些应用通常是办公MIS类应用，如报表的生成。

FlashCopy NO COPY选项

对于IBM ESS独有的NO COPY功能，在异步灾备中有极大的作用。NO COPY也需要实时生产数据的时间点拷贝，但并不需要真正的数据拷贝，即在FlashCopy完成以后，不存在源数据的单独的物理拷贝。这一点可以通过FlashCopy NO COPY选项来实现。使用NO COPY选项的应用通常不需要频繁访问被拷贝映像。NO COPY选项不需要所有的镜像磁盘空间，但是需要一些磁盘空间进行磁盘索引和写I/O缓存的操作。所需磁盘空间的容量取决于FlashCOPY的使用时间（即从建立到删除的时间）和被拷贝卷的更新速度。

在异步灾备的方案中，本地可以用Flashcopy的NO COPY的选项进行时间点的COPY，以保证数据的完整性，再用PPRC进行远程灾备。

PPRC/XD数据备份方案

PPRC/XD为非同步、长距离的拷贝选项，它较适合于数据迁移、数据库日志的传输及定期的异地数据备份，这个功能是集成在ESS的PPRC选项当中的。当ESS运行在非同步方式时，被修改的数据持续的传到备份端，修改主ESS端的I/O的操作在被修改的数据传往备份ESS端之前结束。由于是非同步的操作，这样可以最小的影响主ESS端应用的响应时间，当客户需要时，还可切换至PPRC的同步方式。

级联PPRC数据备份方案

ESS拷贝服务版本2推出了一种被称为级联PPRC的功能，这一功能允许您将同步PPRC和PPRC/XD组合在一起，从而提供了另一种灾难恢复方法。

PPRC版本2包括了PPRC版本1的全部功能，还包括了级联功能。它非常适宜于实现基于数据的定期时间点拷贝、远程数据拷贝、远程数据移植、远程备份以及非活动数据库日志传输等灾难恢复解决方案。PPRC版本2支持异步级联功能，这一功能可用于为开放系统和IBM eServer Z系列服务器提供一个长距离的远程拷贝解决方案。这一功能可以在远程站点提供一份完整且一致的数据拷贝，并支持强大的城域和长距离的业务连续性以及灾难恢复功能，可以为使用同步PPRC的两个站点配置这一功能--将主拷贝和中间拷贝存放在同一本地ESS上，同时使用异步PPRC/XD连接到一个远程站点；或在一个三站点的配置中使用这一功能，这样可以实现长距离零数据丢失。

利用级联PPRC，可以轻而易举地突破性能、数据完整性和传输带宽的限制，实现高效率、低成本的容灾方案：
   面向开放系统和大型主机的远程数据同步方案，两站或三站式，采用三站式方案可实现“零数据损失”
   本地中心和同城中心实现同步PPRC，对性能的影响微乎其微，并确保数据完整性
   同城中心位于同步PPRC的实施距离内，本地中心的事故不会波及同城中心
   可在距本地/同城中心的任意距离设立远程中心

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

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

6.1.1应用环境基本需求

1. 硬件环境配置
本地生产中心：
   IBM xSeries 445(4 CPU, 2GB内存) 1 台
   Qlogic 2310光纤通道卡 2 块
   IBM 2109-F16光纤交换机 2 台
   IBM ESS800 企业级存储服务器 1 台
   客户端PC机若干

远程备份中心：
   IBM xSeries 445(4 CPU, 2GB内存) 1 台
   Qlogic 2310光纤通道卡 2 块
   IBM 2109-F16光纤交换机 2 台
   IBM ESS800 企业级存储服务器 1 台
   客户端PC机若干
   软件环境配置
   Microsoft Windows Advanced Server(Service Pack 3)
   Qlogic 2310: Bios level 1.35 驱动程序 8.2.2.61
   ESS SDD 1.5.0.1
   ESS 800 微码版本: 2.3.1.124
   ESS Flashcopy 版本2
   ESS PPRC 版本2
   IBM 2109-F16固件版本：3.0.2f

3. 网络环境配置

本环境中的网络部分由两部分组成：

第一部分为公网部分，主要承担应用环境中，服务器与服务器之间，服务器与客户机之间的网络通讯；该部分使用10.1.1.X网段，子网掩码为255.255.255.0。

第二部分为管理网段，主要承担应用环境中存储服务器ESS800、光纤交换机的通讯，这里我们命名为ESSNet。该部分使用172.31.1.X网段，子网掩码为255.255.255.0。

4. SAN环境配置

本环境中在本地生产中心和远程备份中心各配置有独立且冗余的光纤交换机。本地生产中心和远程备份中心的每台服务器都至少配置有两块光纤通道卡。本地生产中心和远程备份中心的存储服务器IBM ESS800配置有4块光纤卡，其中两块光纤卡用于服务器与ESS800的连接；另外两块光纤卡分别应用于本地生产中心和远程备份中心的ESS800之间的专用光纤数据链路。本地生产中心和远程备份中心的光纤卡都通过冗余的方式连接到光纤交换机上。本地生产中心和远程备份中心的光纤交换机采用光纤电缆级联起来，构成一个统一的光纤网络。

6.1.2基于磁盘系统的PPRC数据容灾及恢复过程

利用上述典型应用环境，可以实现对相应的生产系统数据进行容灾备份。

PPRC进行数据恢复非常简单，由于数据在远程同步保存着同样的数据，因此主机部分的容灾操作仅需要在远程重新启动主机，而恢复过程则可以反向执行初始化操作。具体过程如下（只考虑主机、存储部分）

a. 灾难发生
(1) 确认灾难，如果需要切换则执行下一步（可自动，但最好由人工控制）；
(2) 在远程备份中心停止复制操作（数据复制已经停止，只是释放此数据卷）；
(3) 启动远程备份中心主机，主机、数据恢复过程完成。
b. 灾难恢复
(1) 确认原生产中心正常；
(2) 反向建立数据复制对；
(3) 开始同步数据；
(4) 暂停容灾中心业务，然后停止同步过程；
(5) 在生产中心重新启动业务，切换网络，业务恢复；
(6) 建立正向数据同步复制对，容灾业务恢复。

中文                                                英文
活动状态的备份中心       Active Secondary Center
高级对等网络                  APPN，Advanced Peer to Peer                                                Networking
美国电话电报公司        AT&T, American Telephone and                                           Telegraph
异步传输模式                 ATM，Asynchronous Transfer Mode
业务连续计划                 BCP, Business Continuity Plan
边界网关协议版本4        BGP-4，Border Gateway Protocol -                                            4
基本输入输出系统        BIOS，Basic Input/Output System
底线                             Bottom Line
业务恢复计划                 BRP, Business Recovery Plan
业务连续性                     Business Continuity
业务影响分析                 Business Impact Analysis
层叠                             PPRC Cascading PPRC
危机通信计划                 CCP, Crisis Communication Plan
首席信息官                   CIO，Chief Information Officer
命令行接口                   Command Line Interface
运行连续性计划              COOP, Continuity of                                                             Operations Plan
信用事件                         Credit event
客户关系管理（软件）   CRM, Customer Relationship                                                    Management
数字数据网                   DDN，Digital Data Network
"灾难"恢复                      Disaster Recover
降级操作                         DOO, Degraded Operations Object
灾难恢复计划                  DRP, Disaster Recovery Plan
增强版内部网关路由协议EIGRP，Enhanced Interior Gateway                                            Routing Protocol
电子链接                          Electronic Vaulting
电子链接                          Electronic vaulting
企业系统连接                   ESCON，Enterprise System                                                       Connection
企业级存储服务器           ESS, Enterprise Storage Server
故障切换                          Failover
光纤连接                          FICON，Fiber Connection
地理分布并行系统           GDPS，Geographically Dispersed                                           Parallel Sysplex
高可用性集群多处理软件 HACMP, High Availability                                                         Cluster Multi-Processing
高可用性灾难恢复            HADR, High Availability Disaster                                            Recovery
IBM的一种灾备软件        HAGEO，High Availability                                                           Geography
热交换中心                        Hot Center
国际数据中心                   IDC，International Data Center
事件响应计划                   IRP, Incident Response Plan
管理信息系统                   MIS，Management Information                                                Systems
没有异地数据                   No off-site Data
网络恢复目标                   NRO, Network Recovery Object
场所紧急计划                   OEP, Occupant Emergency Plan
开放最短路由优先协议       OSPF，Open Shortest Path First
PTAM卡车运送访问方式       Pickup Truck Access Method
快照                                   Point-in-time Copies
PPRC镜像对                        PPRC Pairs
对等远程拷贝                   PPRC, Peer-to-Peer Remote Copy
距离扩展的对等远程拷贝 PPRC/XD, Peer-to-Peer Remote                                            Copy/Extended Distance
应用版本的一致性             PTF
磁盘冗余阵列　                 RAID，Redundant Array of Disks
恢复时间点 RPO,               Recovery Point Object
一种串行通信端口             RS232
恢复时间                            RTO, Recovery Time Object
存储区域网络                  SAN, Storage Area Network
小型计算机系统接口       SCSI，Small Computer System                                                Interface
一家商用软件供应商        Siebel
系统网络结构协议             SNA，System Network                                                                 Architecture
光谱共同基金                   Spectra mutual fund
备用服务器                         Standby Server
存储系统级别                   Storage Device Level
子系统设备驱动程序        Subsystem Device Driver
外宕机                                System down
层次                                    Tier
两数据中心，两个阶段的数据传输承诺                                                                                 Two-Site Two-Phase Commit
虚拟磁带服务器                 VTS, Virtual Tape Server
0数据丢失                            Zero Data Loss

容灾备份异地容灾数据容灾容灾系统数据同步复制采集归档检索集中分发容灾方案异地容灾备份远程容灾容灾技术异地容灾方案oracle容灾容灾方案异地容灾数据容灾容灾是什么容灾系统异地容灾备份oracle容灾容灾备份数据容灾系统异构容灾方案下载EMCSRDF容灾技术和业务连续性服务方案,IBMPPRC,HPBusinessCopy,HDSTrueCopy,VERITASVVR；DSGRealSync,QuestSharePlex等,HDS数据中心容灾解决方案,飞康公司的持续数据保护(CDP)抽取共享升级迁移优化灾难恢复备份恢复数据保护器FalconStorCDP,StoreAge容灾方案,SEPATON容灾解决方案oracle数据库备份oracle自动备份oracle数据备份oracle冷备份oracle备份表证券税务财政社保公安电力交通保险银行工商石化电信联通移动网通企业管理金宏钱金税金关金财金卡和金审社会金盾金保金农金质和金水热备异构热容灾方案备份软件工具方案技术磁盘磁带oracle备份与恢复oracle定时备份oracle备份命令oracle热备份oracle的备份与恢复oracle如何备份oracle备份还原oracle备份方式oracle逻辑备份oracle9i备份oracle联机备份DSG公司DSGRealSync数据库复制容灾软件抽取共享升级迁移优化灾难恢复备份恢复oracleexp备份oracle备份rmanoracle的备份oracle远程备份oracle的rman备份oracle备份方案oracle备份脚本oracle数据备份语句oracle备份工具oracle增量备份oracle备份技术oracle物理备份oracle冷备份脚本异地容灾备份oracle备份表空间SnapAssure高速备份恢复软件pb备份oracle数据库oracle备份级别oracle容灾备份oracle容灾方案oracle容灾技术招标oracle容灾备份oracle容灾dataguardoracle容灾产品电信级容灾系统建设boss容灾系统分布式数据容灾系统数据同步复制采集归档检索集中分发容灾系统的实现原理数据库容灾系统上海移动boss容灾系统证券税务财政社保公安电力交通保险银行工商石化电信联通移动网通企业管理金宏钱金税金关金财金卡和金审社会金盾金保金农金质和金水热备异构热容灾方案备份软件工具方案技术磁盘磁带RealMigrates数据库异构平台实时迁移软件建设银行容灾系统异地容灾系统结构pptvvr容灾系统容灾系统级异地容灾方案veritas异地容灾方案远程容灾方案vvr容灾方案iscsi容灾方案oracle容灾方案应用级容灾方案数据同步复制采集归档检索集中分发数据容灾方案远程异地容灾方案电信容灾方案数据备份方案双机热备份方案数据库备份方案服务器备份方案oracle备份方案oracle数据库备份方案异地备份方案异地容灾备份veritas备份方案doc磁带机备份方案企业数据备份方案案企业数据备份方案北京天津河北山西内蒙辽宁吉林黑龙江上海江苏浙江安徽福建江西山东河南湖北湖南广东广西海南四川重庆贵州云南西藏陕西甘肃青海宁夏新疆大连厦门青岛苏州应急平台容灾中心查询平台OLTP VS OLAP数据抽取复制报表分离负载均衡数据集中数据广播应用数据实时同步实时数据仓库及决策支持系统应用