内容简介
随着时代的发展，人类对于灾难的防范意识和要求越来越高。灾难的概念范畴非常广泛，本书针对于企业环境，对业界当前讨论的热门话题-- 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 - 业务连续性而不仅仅是 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关注在中断期间和之后维持机构的业务功能。业务功能的一个可能的例子是工资的支付处理或客户的信息处理。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基础设施架构的可用性
* 业务流程的可用性（应用的可用性+外部相关条件）
在规划灾难保护的功能级时必须包括所有外在因素，如不同企业间的相互协作等。