第一篇：政府行业系统灾备建设白皮书
政府行业系统灾备建设白皮书
目 录
政府行业灾备建设特点及案例剖析..............................................69 6.1
政府行业灾备建设特点及案例剖析...........................................................69 6.1.1
行业概览..............................................................69 6.1.2
行业现状与需求........................................................72 6.1.3
应用场景与解决方案....................................................74 6.1.4
典型用户案例..........................................................78 6.1.5 小结...............................................................80
灾备市场与行业趋势...................................................................137 7.1
灾备市场概况........................................................................................137 7.1.1
市场高速增长.........................................................137 7.1.2
市场多元发展.........................................................138 7.2 未来五年（2020-2025）趋势...............................................................139 7.2.1
信创推动核心技术自主研发.............................................139 7.2.2
合规性仍是推动行业发展主因...........................................140 7.2.3
平台化推进灾备产业化发展.............................................141 7.2.4
灾备人才和用户群体持续增长...........................................142
政府行业灾备建设特点及案例剖析 数字化转型加速了行业的信息化建设，如何保障信息化建设安全，国家已经从法律层面制定了一系列的法规条文，并明确了信息运营主体的职责。在这个大背景下，灾备建设落实到具体的建设工具，无外乎数据的容灾备份、迁移、恢复等技术产品。但每个行业的信息系统和数据特点不同，也造就了不同的灾备解决方案。譬如，政务行业的私有云架构，不仅要考虑内外网特殊情况，还要考虑数据中心建设一期和二期软硬件的异构问题等。
为了更真实地展现重点行业的灾备建设特点，本章节涉及的行业概述、应用场景和典型案例，主要来自英方软件近百位一线技术工程师的实践。这些内容几乎全面覆盖了各个行业的灾备特点和需求，在具体的应用场景和方案剖析中，也可以作为大家参考的重要的实践内容。
本章节共列举了政府、金融、医疗、教育、电信、能源、制造等行业的灾备建设特点，这些行业所涉及的内容如下表所示。
行业 内容 政府 指各级政府部门及各种机构，如公检法、公积金、大数据局、环保、消防等部门。
金融 指经营金融商品的特殊行业，包括银行、保险、信托、证券、会计、审核及相关设 备制造商、系统集成商。
医疗 指与人们身心健康相关的产业的统称，包含了传统意义上的卫健委机构、医院等。
教育 指各地教育局和各大中专院校及中小学等教学主体。
电信 指各个电信运营商以及运营商机构依托各地 IDC 进行的云灾备建设。
能源 指天然气、石油石化、国家电网、南方电网及各地下属电网公司等。
制造 指机械和电子制造业、轻纺工业、资源加工工业，如航空发动机、半导体芯片、机械、汽车、五金、食品、服装等。
表 6-1 灾备重点行业涉及领域 6.1 政府行业灾备建设特点及案例剖析 6.1.1 行业概览 电子政务是指政府机构通过运用信息化手段，实现办公自动化、24 小时咨询服务、网上申报和审批等各种政府职能。电子政务应用包括政务信息查询、公共政务办公、政府办公自动化等。本内容涉及的电子政务的建设主体是各级政府部门及各种组织机构，涵盖各级党组织、政府部门、公检法、委办机构等，譬如各级人民政府、人民检察院、人民法院、公安部门、消防、工商、税务、环保等。本章节所涉及的电子政务的数据安全和业务连续性的内容，也是以为百姓提供日常服务的政府及组织为主。
新基建、数字中国、智慧城市、互联网 + 政务等新型城市的建设浪潮，都离不开作为电子政务底座的新型基础设施—政务云。当前，各地政府大力兴建的政务云，也不负重托，通过新型电子政务的方式，在数字政府、智慧政务、智慧民生等应用领域，逐步实现人民政府提出的“让数据多跑路，让百姓少跑腿”的郑重承诺。为此，通过先进的数据复制、容灾备份等技术构建一个安全可靠的政
务云，已经成为各级政府组织信息化建设的重要内容之一，也是建设人民满意的数字化服务型政府的必要条件。
（1）等级保护和分级保护 政府电子政务的建设和发展关乎国计民生，也关于国家安全和经济发展。由于当前的信息安全保密问题日益突出，勒索病毒、网络攻击、机密文件泄露等事件愈发频繁，给国家安全和政府外交工作带来重大的挑战。为此构建新时代电子政务的信息化应用，必须做好关键信息和数据的安全管理及保护工作，必须加强对政府信息数据和国家机密保护的宣传工作，必须确保各类信息不泄露、不丢失和重要系统不出现重大故障。
强化信息安全，法度利器先行。国家层面已制定了相应的一系列法律法规，强制性要求各类数据中心的运营机构必须遵守各项信息安全规定，提升整体的信息安全防护措施，而政府及组织在这方面起到了带头示范的作用。在国家已颁布的一系列法律法规中，等级保护和分级保护的影响范围最广。
等级保护，即信息安全技术网络安全等级保护要求，是我国信息安全保障的一项基本制度。2003 年由中办、国办转发《国家信息化领导小组关于加强信息安全保障工作的意见》，正式提出实行信息安全等级保护和建立国家信息安全保障体系的明确要求。2007 年和 2008 年颁布实施的 《信息安全等级保护管理办法》和《信息安全等级保护基本要求》，统称“等保 1.0 ”；2019 年 5 月发 布《信息安全技术网络安全等级保护基本要求》，统称“等保 2.0 ”。在等级保护分级中，按重要程度共分为五级：
一级（自主保护）
二级（指导保护）
三级（监督保护）
四级（强制保护）
五级（专控保护）
除了等级保护，国家也对涉及国家机密的信息系统进行了分级。2005 年 12 月，国家保密局下 发了《涉及国家秘密的信息系统分级保护管理办法》，同时，《保密法》修订草案也增加了网络安全保密管理的条款。分级保护分为：
秘密级 机密级和机密级（增强）
绝密级 等级保护和分级保护的制定，从国家法律层面规范了公民、法人和机构组织对信息系统分等级 实行安全保护。各级政府电子政务的建设，涵盖几十个不同等级的应用系统，如何区分这些系统的等级和分级，政府政务管理机构已经组织专家团队做了全面的评估和评定，对政府应用的系统进行了等级划分。
一般而言，面向社会提供服务窗口的网站及 Web 应用系统对国家安全影响有限，可以划分为一二级等级保护，对外公开的气候、经济统计、灾害预防等信息也不属于国家秘密。但是，一些重要的网站、内部流转的机密公文及测绘、国防等信息系统，就属于较高等级或秘密的保护范畴。故从数据管理和灾备角度分析，电子政务信息系统应根据其信息安全保护等级和业务连续性要求，选择建设相对应的灾备系统，以防止因系统终止提供服务而对市民的正常生产生活带来影响，甚至造成严重的社会影响；电子政务信息系统也应根据其数据的重要性程度制定数据备份策略，以防止因数据丢失而造成损失。
（2）政府电子政务发展的法律法规 国家在大力推进电子政务快速发展的同时，不同主管机构和部门下发和颁布了一系列的政策法规。例如：
《中华人民共和国网络安全法》第七十二条规定：国家机关政务网络的运营者不履行本法规定的网络安全保护义务的，由其上级机关或者有关机关责令改正；对直接负责的主管人员和其他直接责任人员依法给予处分。
《国务院办公厅关于印发进一步深化“互联网+ 政务服务”推进政务服务“一网、一门、一次” 改革实施方案的通知》（国办发〔2018〕45 号）要求“加强数据共享安全保障”，依法加强隐私等信息保护；提高国家电子政务外网、国家数据共享交换平台和国家政务服务平台的安全防护能力； 推进政务信息资源共享风险评估和安全审查，强化应急预案管理，切实做好数据安全事件的应急处置。
《国家发展改革委关于印发“十三五”国家政务信息化工程建设规划的通知》指出，“构建一体化政务数据平台”是规划的主要任务之一，即按照“数、云、网、端”融合创新趋势及电子政务集约化建设需求，依托统一的国家电子政务网络加快建设综合性公共基础设施平台，形成互联互通、安全防护、共享交换、云计算、数据分析、容灾备份等综合服务能力，实现电子政务关键公共基础设施的统建共用，支撑政务业务协同和数据共享汇聚。
本章节整理了对政府电子政务发展起到积极推动作用的法律法规及文件，各级政府及组织可根据机构规模、属性、等级进行相应的数据安全和业务连续性的建设。
“加快电子政务信息系统的发展” 《国务院办公厅关于促进电子政务协调发展的指导意见》（国办发〔2014〕66 号）
《国务院关于促进云计算创新发展培育信息产业新业态的意见》（国发〔2015〕 5 号）
《国务院关于印发政务信息资源共享管理暂行办法的通知》（国发〔2016〕51 号）
《国务院关于加快推进“互联网 + 政务服务”工作的指导意见》（国发〔2016〕55 号）
《国务院办公厅关于印发 <2017 年政务公开工作要点 > 的通知》（国办发〔2017〕24 号）
《国务院办公厅关于印发政府网站发展指引的通知》（国办发〔2017〕47 号）
《国务院办公厅关于印发< 政府网站集约化试点工作方案> 的通知》（国办函〔2018〕71 号）
“关于保障电子政务信息系统安全的发展” 《关于加强党政部门云计算服务网络安全管理的意见》（中网办发文〔2014〕14 号）
《关于加强党政机关网站安全管理的通知》（中网办发文〔2014〕1 号）
《公共安全业务连续性管理体系指南》国家标准（GB/T 31595-2015）
《国家网络空间安全战略》（国家网信办 2016 年 7 月）
《中华人民共和国网络安全法》（2017 年 6 月 1 日）
《信息安全技术网络安全等级保护基本要求》（GB/T 22239-2019）
《网络安全审查办法》（国家网信办 2020 年 4 月）
随着我国经济体量的持续壮大和国际地位的显著提升，境外敌对势力通过网络渗透攻击我国重要部门的网络系统，以及通过黑客技术加密重要文件的事情时有发生。据新闻报道，从 2014 年开始，某机构安全大脑通过整合海量安全大数据，发现了多起境外 APT 组织使用“在野”0day 漏洞针对 我国境内目标发起的 APT 攻击，并发现境外针对中国境内目标的攻击最早可以追溯到 2007 年，至 少影响了中国境内超过万台电脑，攻击范围遍布国内 31 个省级行政区。
这些攻击对象包括国防、航天、政府、重要企业的网络系统，由此可见各级政府及组织加强电子政务信息系统和数据安全的保护迫在眉睫。
6.1.2 行业现状与需求 提高工作效率，建设人民满意的数字化服务型政府，离不开政务电子化所需要的各种信息化技术和设备。我国电子政务建设，以 1999 年政府上网工程启动这一标志性事件为界 , 之前为政府信息化的前期 , 之后为政府信息化大规模建设阶段。我们总体上将其划分为三个时期：
（1）网站建设时期 这一时期的电子政务建设，更多关注政务信息和流程的公布，与群众线上交互等。同时，通过政府部门的带动，培养群众对新技术、新方式的接受和适应能力。
（2）信息化时期 这个时期主要是在第一阶段的基础上，实现协同办公、不见面审批、网上执法、网络化管理等。这个阶段所面临的挑战是实现孤立部门间流程的统一和协同化。
（3）大数据时代 这个阶段政府的网络建设观念逐渐淡化，更多强调对大数据、人工智能、容器云、区块链等新兴技术的应用，实现对数据的挖掘、交互、分析、保护，同时也更强调数据和业务的安全性，强调部门协同打破数据孤岛，保障数据价值的时效性，加快数据流动，最终为供给侧提供需要的数据价值，从而为老百姓提供更高效便捷的政务服务。
时至今日，电子政务也从前端网站建设转向基础设施集约建设，政务云和大数据中心已成为数字政府建设的当务之急。政务云也是电子政务 IT 发展新 10 年，在云计算时代，电子政务 IT 基础
设施将从分离重新走向融合，用户通过云操作系统，将数据中心多厂家异构的计算、存储、网络资源进行统一融合，对外提供开放与标准化的IT 服务接口，实现数据资源与应用资源的融合。为此，在众多的子系统与数据库中，需要一个平台来传递可靠的、与平台及语言无关的数据，且能够把数据透明化。这时，数据复制技术将在接口调用过程中发挥重要作用，通过不断的收集、调用、分析数据，满足 IT 业务的需求，并协助业务模型决策做出更智能的预测。
硬币都有两面性，云环境下的电子政务在获得集约建设、资源利用最大化的同时，也意味着风险共担。政务云建设需要评估资源间的依赖关系，适当对 IT 资源进行解耦，减少 IT 资源的关联风险，以及对关键 IT 资源进行容灾备份，确保构建在政务云上的系统安全持续运行。
不将所有鸡蛋放在一个篮子，是各地政务云建设应当遵循的一个标准。当前，政务云建设分为内外网，以及两地三中心或异地容灾的建设模式。即通常情况下，在同一个政务云的数据中心，管理者会将政务内网系统和外网系统划分为两个区域，它们之间的 IT 资源相互独立，同时同城采用主备模式，在同城 50 公里左右的地方构建备用政务云数据中心，当生产数据中心的系统发生故障，要么在本地数据中心进行系统切换，要么整体切换到备用数据中心，实现系统应用的容灾保护。最后，为了避免区域性灾害如地震、火灾、洪灾、战争可能造成的毁灭性破坏，对于重要系统和数据库数据，还需要在异地建立灾备中心，用于关键系统和数据的恢复，符合等保要求。
图 6.1-1 电子政务架构图 在这种“一朵云二张网三中心”的运营管理模式下，电子政务在业务方面，划分为两类：一类是以省-市州-区县-乡镇为四级行政机构的电子政务模式，专注于政府便民服务、政策发布执行和公文传输等；一类是以省厅-市州局-区县分局-乡镇营业所（行业称呼略有差别）的模式，专注细分业务的对外服务、政策执行发布和公文传输等（如公检法）。
不同的领域和单位，有不同的数据安全和业务连续性需求，等级保护和分级保护要求也不一样，综合分析，主要存在以下需求：
业务数据本地备份、CDP
本地数据库读写分离和容灾本地应用系统的容灾高可用关键系统的异地跨平台容灾
政务云虚拟机迁移和云灾备内外网两地三中心容灾备份 综上，随着电子政务的落地发展，构建政务云之间的灾备体系将是下一步的建设重点，防范网络入侵和病毒攻击将是首要任务，同时系统故障带来的对外服务窗口的关闭，如政务挂号系统故障、发布防洪资讯的网站访问不了，都会带来一定的社会影响。为此，需要制定完备的容灾机制，确保数据不丢、业务不停。
6.1.3 应用场景与解决方案 实现电子政务的数据安全和业务连续性建设，需要捋清楚电子政务的系统网络建设情况，特别是政务内外网、多种异构平台情况、二层与三层网络应用等。
目前，我国电子政务网络系统分为政务内网和政务外网，内网是为政务系统自建的私有网络，外网一般指互联网，政务内外网通过信息安全交换系统，实现信息的交换，两者是相互隔离又相互补充的关系。
政务内网：以满足政府内部办公的需求为主，通过独立的软硬件设备达到物理隔离的目标，对上与国家电子政务内网互联。政务内网为了安全覆盖范围尽可能少，主要用于传送电子公文，以及不适合通过外网传输的信息，比如政务信息、视频会议等信息。
政务外网：以政府公共服务网为主，组织机构及民众可以通过政府公共服务网查询相关的政务信息。政务外网与互联网通过网络安全系统逻辑连接，是政务机构人员与外面进行信息交流的通道，是政务公开和为民办事的主要窗口，各单位通过网站对外提供网上服务、受理申请等，典型代表为各类政府信息门户网站。
互联网出口：在异地灾备建设过程中，互联网出口是系统故障完成切换后，政务系统继续对外提供服务的网络端口。通常情况下，按照规定政府机构的下属单位上网，应该统一上联到政府信息中心的互联网出口，但业务的不同，会存在个别政府单位因为工作需要或其他原因，可以搭建独立的互联网出口。
异构平台系统：政务数据中心有一个显著的特征，是供应商错综复杂，品牌繁多，不同的数据中心，存在虚拟化平台异构、服务器异构、存储系统与硬件异构、数据库异构等问题；此外，结构化与非结构化数据也对政务大数据平台、数据湖、容灾备份等应用带来挑战。
网络层容灾切换：政务系统内外网的通信，以及在两地三中心或异地容灾的情况下，会涉及不同网络层的应用。在故障发生时，英方软件通常采用的故障切换接管方法，分为在二层网络环境下，会采用 VIP 漂移技术，实现故障的切换；在三层网络环境下，可以采用负载均衡方式，实现故障切换；在广域网环境下，支持与 DNS 服务器无缝结合，实现故障切换。
综上，针对不同场景不同网络环境下的政务系统，电子政务主管部门根据各个系统安全等级保护的要求，需要做出相应的调整，当本地数据中心发生故障或出现重大灾难时，可以马上进行容灾切换及数据恢复。而对于数据安全和业务连续性的建设，采用同城或异地的主备数据中心、两地三中心等方案，不仅可以实现省级（直辖市）的政府及组织电子政务云平台的容灾备份，还可以实现地市级（区县）政务系统的容灾备份。
英方软件在电子政务领域拥有丰富容灾备份的项目实践经验，可以为用户提供政务系统的跨平台迁移、本地容灾备份、异地数据库数据实时同步和系统容灾、云容灾、两地三中心灾备等解决方案。由于政务机关分门别类较多，难以逐一陈述，下面我们挑选几个有代表性的场景进行介绍。
图 6.1-2 政府及组织电子政务云整体架构
（1）海量虚拟机跨平台迁移和容灾 场景特点：虚拟机数量大；虚拟化平台及版本异构。
用户需求：本地或云端到云端的系统热迁移；虚拟机的备份和故障快速切换接管。
图 6.1-3 跨虚拟化平台系统热迁移 应用实践：在本地或异地数据中心，通过 i 2 M o ve
系统在线热迁移软件，在不影响日常政务服务的前提下，可以将系统从 V M w a r e
虚拟化平台迁移到 K V M
+
O p e n S t a c k的异构平台上，同时增量数据及 IP 地址可一起迁移到新的平台上，整个迁移进程自动化，迁移成功率高。与此同时，由于平台型故障对虚拟机集群可以造成致命打击，为此需要通过 i 2 A v a il a b ili t y
实现重要虚拟机系统的容灾，保障业务连续性。
（2）政务云两地三中心灾备 场景特点：虚拟机规模大、内外网环境；等级保护和分级保护要求不同。
用户需求：建设两地三中心灾备，保留互联网出口；重要系统同城容灾，数据异地备份；数据库数据的实时同步和读写分离。
图 6.1-4 政务云两地三中心灾备 应用实践：两地三中心的模式下，灾备建设遵守内外网相互隔离的原则，并根据用户需求决定是否在灾备端保留互联网出口；在本地生产中心到同城灾备中心异构虚拟化平台的过程中，通过 i 2 A c t i ve
数据库语义级的数据实时复制和同步软件，实现数据库读写分离和容灾；同时通过 i2Availability 实现异构平台核心业务容灾接管；最后通过 i2CDP、i2FFO 进行本地到同城，同城到异地的数据同步和备份，可以有效防范逻辑错误、勒索病毒的攻击，保障数据和业务的安全。
（3）公安厅警务系统异地容灾与数据库双活 场景特点：等级保护和分级保护要求不同；各个平台的异构问题突出。
用户需求：数据库数据的实时同步和读写分离；建立同城或异地容灾中心；实现跨平台的容灾接管。
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
图 6.1-5 公安厅警务系统异地容灾与数据库双活
应用实践：在专网环境下的本地和异地数据中心，通过 i 2 A c t i ve
数据库语义级的数据实时复制和同步软件，将 O r a c l e
R A C
实时同步本地灾备服务器，然后在实时同步到异地灾备中心；然后通过 i 2 A v a il a b ili t y
高可用软件实现对本地业务系统的异地容灾，确保业务应用系统发生故障时，可以秒级进行切换接管。
（4）
公检法海量 NAS 文件异地灾备与数据库双活 场景特点：机密性强、等保要求高；海量小文件，平台异构。
用户需求：NAS 下海量小文件的灾备；本地或同城的系统容灾。
图 6.1-6 公检法海量 NAS 文件异地灾备与数据库双活
应用实践：在专网环境下的本地和异地数据中心，通过 i2NAS 海量文件同步软件，将 NAS 存储下的服务器变化的数据，汇集到本地 i2NAS 服务器，然后定时或实时将变化的数据同步到容灾中心；通过 i 2 A v a il a b ili t y
实现对本地业务系统的容灾高可用，确保关键系统发生故障时，异地容灾中心可快速接管应用；通过 i2Active 数据库语义级的数据实时复制和同步软件，将 Oracle RAC 实时同步到本地或异地容灾中心。
（5）
大数据管理局数据库容灾及
CDP
保护场景特点：数据集中管理，非结构化数据多 用户需求：数据库系统的容灾和数据备份；异构数据库在大数据平台的数据流通；数据库数据CDP 保护。
应用实践：在本地大数据中心，通过 i2Active 将 Oracle RAC 同步到备端 Oracle 数据库单机服务器，然后通过 i2CDP 实现数据库数据的持续保护；针对 Oracle、MySQL、SQL Sever 等数据库到大数据平台的应用需求，可通过 i 2 S t r e a m
数据流复制管理软件，采用抽取、转换、装载的方式，实现异构数据库平台之间数据的传输及数据到 Kudu、Hadoop 等大数据平台，打破数据孤岛，i2NAS i2NAS 的
实现数据互联互通。
6.1.4 典型用户案例 图 6.1-7 大数据管理局数据库容灾及 CDP 保护（1）某公安厅跨平台异地容灾 项目亮点：在硬件及虚拟化异构的情况下，实现重要数据库数据异地约 400 公里的跨平台实时同步和容灾，以及重要警务系统的高可用异地容灾和灾备服务器数据的实时同步备份。
项目需求：结合公安信息化发展现状和实际需求，新疆公安厅计划按照国家标准化管理委员会颁布的相关等级保护要求，建立一个集中、统一、高效的异地灾备系统，以提高公安厅重要信息系统和数据的安全等级，实现异地容灾和数据库的双活。
图 6.1-8 某公安厅跨平台异地容灾架构图
Oracle
XML SQL CSV TXT JSON
Oracle RAC
i2CDP
i2COOPY
解决方案：
1.
在本地环境下，通过 i2Active 实现 Oracle RAC 到 Oracle 灾备数据库的实时同步，然后再通过 i2Active 实时同步到异地灾备中心； 2.本地虚拟化平台搭建各类警务系统，通过 i 2 A v a il a b ili t y
高可用软件对本地业务系统的异地容灾，确保应用系统发生故障时，可以秒级进行切换接管； 3.在本地的数据中心，通过 i 2 C D P
实现各类警务系统的重要数据，持续备份到本地的灾备服务器，然后通过 i2COOPY 实时同步到异地灾备中心。
（2）遵义市住房公积金中心异地容灾与互为灾备 项目亮点：确保了公积金中心核心业务系统、综服管理系统、结算系统的应用容灾，以及海量非结构化数据库的数据同步备份、CDP 和文件保护，构建了遵义市公积金中心到盐城市公积金中心的异地容灾模式，首创两市公积金中心“互为灾备”的新模式，在确保重要数据异地备份、系统容灾的同时，突破传统异地容灾成本高、可用性低、数据备份窗口大等难题，是“互联网 + 政务服务” 的创新实践。
项目需求：实现公积金中心核心业务系统、综服管理系统、结算系统的异地容灾，确保数据和业务的安全；同时通过互为灾备的模式，减少异地灾备中心的投入。
解决方案：
图 6.1-9 遵义市住房公积金中心容灾架构图 1.在生产中心通过虚拟化技术，将服务器资源分配给相应业务系统，然后通过 i 2 A v a il a b ili t y字节级数据复制高可用软件，应用程序与灾备中心应用服务器进行一对一的应用高可用容灾；数据库与灾备中心数据库服务器 i 2 B o x-C
进行一对一的应用高可用容灾；当生产中心某台虚拟机出现故障时，灾备中心相应的服务器可秒级接管，继续对外提供服务。
2.
通过虚拟化技术将灾备数据库服务器 i 2 B o x-C
针对生产中心 A I X
小型机系统下的核心业务数据库进行集群，通过 i 2 A c t i ve
数据库语义级同步软件，将集群实时同步到灾备数据库服务器 i 2 B o x-C
上，实现核心数据库集群从 A I X
小型机到 X 86
服务器的高可用容灾；最后业务系统通过 i2A v ail ability
高可用软件，在灾备数据库服务器 i2Bo x-C
上实现一对一高可用容灾。
i2Box-C i2CDP
3.
针对生产中心 A I X
小型机上的应用程序和凭证数据，通过 i 2 B a c k u p
备份到灾备 A I X
小型机应用服务器上，确保重要应用和数据的备份保护。
4.
通过内嵌的 i 2 C D P
灾备一体机 i 2 B o x D-A，对存储了生产端重要数据库的灾备中心数据库服务器 i 2 B o x-C
进行持续数据保护，当数据库数据出现损坏、丢失、中病毒等情况时，可以通过 CDP 数据恢复到任意时间点的数据。
6.1.5 小结 电子政务系统是政务和群众之间沟通的重要渠道，是提高政务办公效率的重要工具，也是信息化社会发展的基础。建设人民满意的数字化服务型政府，离不开电子政务平台提供的技术支撑，而保障电子政务应用系统和数据的安全，离不开数据复制核心技术和容灾备份等产品方案。在政务云数据中心领域，适合云和大数据应用场景的数据复制技术，将帮助用户解决各类应用场景的灾备需求，满足不同平台、不同网络层和不同等级保护的需求。
7.1 灾备市场概况 第七章 灾备市场与行业趋势 2020 年受新冠疫情的影响，以餐饮、旅游和娱乐为代表的行业，受到了严重的冲击。上半年，全世界主要经济体的 GDP 更是遭到重创。但是我们也可以看到，机构数字化转型的速度并没有受到太大的影响，反而在应对疫情造成的社交困境时，线上业务展示了非常强大的灵活性和韧性，这也极大地促进了文件同步、数据流动和业务连续性在安全合规方面的发展。
2020 年国际安全形势也是推动市场发展的原因之一，包括以国家安全为借口对业务合规性的审查，蓄意挑起地区冲突，利用网络技术渗透攻击机构的重要系统和数据，以及对关键技术和制造业资源的争夺，都促使相关机构加大对数据和业务安全的保护——将重要数据和系统进行多重保护，以备机系统构被攻击时，可以有最新的数据进行业务的恢复。譬如，以半导体芯片为例，一些机构就加大了生产系统和业务数据的异地备份的保护力度。
从中国第三方灾备技术服务商的市场营收分析，市场强劲的需求一直存在，但是第一季度因疫情采取的社交限制，确实给一线的销售带来挑战。不过随着疫情被控制，第二季度以后，销售的拜访及营销活动走出 V 字型的反弹。
这表明中国灾备市场也具备强劲的发展韧性，而推动市场需求发展的两大因素：一个是中国经济的高速发展，市场主体充满活力，特别是今年提出的“新基建”战略，极大地提振了科技企业、资本和市场研究机构的信心，继续推动企业的数字化转型；一个是中国长期坚持的将信息安全纳入国家安全战略，并出台了“网络安全法”、“等保 2.0”、“数据安全（草案）”等一系列的法律，以国家实行网络安全等级保护制度明文规定所有运营主体，需要对所辖的信息系统严格按照要求进行保护。
7.1.1 市场高速增长 各类研究机构对中国灾备市场的增长预估都非常乐观。智研咨询的报告显示：中国灾备行业市场规模从 2010 年的 49.8 亿元，增长至 2018 年近180 亿元的市场规模，预计至 2022 年中国灾备 行业市场规模可达 300 亿元以上。
前瞻产业研究院的报告重点提到云灾备将成未来主流趋势，其中云灾备市场规模从 2013 年的亿元快速增长到 2018 年的 10 亿元，预计到 2022 年我国云灾备市场规模可达 70 亿元。
信息技术研究和分析机构 Gartner 预计，到 2020 年存储安全（尤其是云存储安全）支出将继续攀升。如今复杂的地缘政治环境将法规遵从性推到了企业的首要任务，2019 年整体安全支出增长10.5%，预计未来 5 年云安全将增长 41.2%。同时，Gartner 也预计到 2021 年，使用备份而非归档方式来管理企业长期数据的比例将从 2017 的 30% 上升到 50%。
根据白皮书内容编委的调查，在中国经济高速发展的三十多年中，特别是从 2010 年互联网开始进入高速发展阶段，中国灾备产品和市场也得到大力发展，中国灾备市场头部企业的融资金额也一轮比一轮高。灾备产品从传统的存储数据备份发展到物理机、虚拟机系统的备份和容灾，数据库同步和容灾也逐渐发展壮大，并成为灾备市场重要的应用场景之一。根据公开的资料整理，2010 年
我国灾备行业市场规模约 49.8 亿元，2015 年达到 136.8 亿元，近几年中国灾备市场规模大体情况
49.8 55.1 60.3 73.9 88.7
如下：
400
300
200
106.5 127.8 151.8
177.4 207.8
240.5
280.3
329.1
0 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022
图 7-1 2010-2022 年中国灾备行业市场规模 国际灾备市场也同样发展强劲，根据 DataCore 发布的 2018 年度 SDS 白皮书《The State of Software-Defined Storage，Hyperconverged and Cloud Storage》内容，有 20% 的用户计划将存储预算的 25% 用在第二存储（灾备）上。
G a r t n e r
公开的数据分析报告提到：
2016
年市场规模已达 20
亿美金，预计 2021
年的市场规模将达到 37.3 亿美元。
M ar ketsandM ar k ets的相关数据也显示，全球备份和恢复市场总额将从 2017
年的 71.3
亿美元上升到 2022 年的 115.9 亿美元。相比备份与恢复市场，云灾备即服务（DRaaS）全球市场呈现出快速增长的态势。
Gartner 的调研报告显示，预计 2021 年的 DRaaS 市场规模将达到 37.3 亿美元；到 2022 年全球云安全市场规模将达到近120 亿美元；Gartner DRaaS 魔力象限中的 10 个国外玩家市值总和
超过 1000 亿美金。
7.1.2 市场多元发展 灾备脱胎于传统的存储厂商——为了解决存储冗余的问题，用户在寻找灾备方案时，首先想到了存储厂商，为此很多传统存储厂商，同时也是传统灾备方案的提供商。但是，随着整个信息技术产品的不断迭代，灾备应用场景也从同机房的本地备份容灾，向同城、异地及云端等更宏大的场景延伸，用户数量更大，产品也更加丰富。
从传统的备份产品开始，灾备产品正在不断拓展边界，目前主要涵盖了传统的系统备份、容灾和恢复；数据同步、分发、脱敏、副本管理；大数据管理和应用；数据库读写分离和容灾；文件管理、共享和保护等。
灾备技术也从传统的存储复制技术，延伸到基于主机操作系统、数据库、文件和网络等五大数
据复制技术。在中国，基于上述五种数据复制技术的灾备企业，每家企业的产品侧重点不同，其中
于灾 有专注于传统的备份厂商，有专注于虚拟机容灾的厂商，有专注于文件共享备份的厂商，有专注于数据复制副本管理的厂商，也有专注于数据库容灾的厂商。英方软件是国内集多种复制技术于一体，核心技术自主研发的基础软件厂商，能够提供全域、多层次、多策略、多副本数据管理的全栈解决方案。
7.2 未来五年（2021-2025）趋势 7.2.1 信创推动核心技术自主研发 信创在网上公开的定义是信息技术应用创新产业，信创涉及的行业包括IT 基础设置：CPU 芯片、服务器、存储、交换机、路由器、各种云和相关服务内容；基础软件：数据库、操作系统、中间件； 应用软件：OA、ERP、办公软件、政务应用、流版签软件；信息安全：边界安全产品（如网络）、终端安全产品（如灾备）等。
图 7-2 信创概念图 信创是一项国家战略，是当今形势下国家经济发展的新动能，发展信创是为了解决“卡脖子” 的安全问题，即通过自主创新把核心技术变成我们自主可控、可发展、可生产的技术。信创产业发展可以助力关键企业突破卡脖子技术，提升关键产业链的发展，促进社会经济的数字化转型，保障国家战略安全。
信创产业从技术体系构建，强化产业基础研究，加强资金政策保障能力等方面着手，促进信创产业在关键领域和重点地区的落地生根，并带动传统信息技术产业的转型，构建自主可控的信息技术应用产业集群。
灾备技术是为确保信息系统和数据安全的关键技术，以核心的数据复制技术为基础，广泛应用备、数据保护、云数据管理等领域，帮助各类用户打破数据孤岛，实现数据互联互通，助力数 字经济的发展。信创产业的发展，将极大推动字节级复制、数据库语义级复制、变长块等核心技术的自主研发，实现数据复制卡脖子技术的不断突破和创新应用，为国防、金融、政务、医疗、电信、能源、交通等行业保驾护航。
英方作为基础软件企业，在信创产业方面，拥有“卡脖子”技术，并在创始团队的带领下，不断发挥自身在基础软件、技术创新、国产化生态体系等方面的优势，与各个生态伙伴一起形成发展
合力，积极参与各地各行业的信创产业发展。
从创始之初，英方就积极布局国产化数据复制技术，并聚焦核心数据复制技术的研发和推广。截至目前，英方已掌握十多项先进的核心发明专利，从字节级数据复制技术，到数据库语义级复制技术，再到变长块级数据复制技术，并以核心数据复制技术为基础，先后推出 i 2 A v a il a b ili t y
应用高可用、i2Active 数据库容灾、i2Stream 大数据同步、i2Distributor 数据分发、i2CDP 持续数据保护、i2CDM 数据副本管理等重磅产品，并在政务、国防、公检法等行业获得广大用户的高度认可。
同时，英方始终与国产软硬件厂商保持互通，实现多方产品兼容适配，并持续跟进其版本迭代和新产品的兼容情况，全面扩展英方灾备软件的适配性，构建完善的灾备和数据复制生态体系。截至目前，英方灾备软件已完成国内主流云厂商（浪潮云、曙光云、华为鲲鹏云等）、芯片（如兆芯、龙芯中科、飞腾、华为鲲鹏等）、操作系统（中标麒麟、普华、红旗、华为 F u s i o n S p h e r e
等）、数据库（山东瀚高、人大金仓、达梦、南大通用等）等重要国产化企业产品的兼容适配，拓展国产化生态战略合作。
此外，英方在近几年先后通过了国家信息安全产品认证、涉密信息系统产品检测认证、信息安全管理体系认证、公安部计算机信息系统安全专用产品认证等，并成为全国信息安全标准化技术委员会成员、国际灾难恢复协会（DRI）指定服务商、灾备技术国家工程实验室合作单位、灾备技术产业联盟会员单位、国家高新技术认证企业等。
在地方信创产业布局以及各行业国产化进程中，英方作为灾备国产化厂商，在政务云、大数据局、公检法等领域的国产化产品替代方面发挥了重要的作用。如：成都政务云通过英方 i 2 M o ve在线热迁移解决方案，在不影响全市政务服务的基础下，实现 2000
多台虚机从 V M w a r e
平台到 KVM+OpenStack平台上的迁移；南京栖霞区大数据管理局基于英方 i2CDP 和 i2Active 的灾备解 决方案，在实现数据库间实时备份和连续数据保护的基础上，大大降低了带宽压力、系统灾后恢复时间、后期运维工作等；海南省交通警察总队通过 i2Active 实现全省各地分发库的联动，实现生产 库读写压力的分流，有效提升生产库的性能。
作为灾备及数据管理领域的头部企业，英方不仅不断加大数据复制核心技术的研发投入，确保灾备及数据管理领域的卡脖子技术自主可控，还积极参与高精尖信息化技术人才的培养，以及各地、各行业和各生态伙伴的信创产业活动，在技术标准、人才培养、体系建设方面贡献力量。
7.2.2 合规性仍是推动行业发展主因 信息系统和数据安全的合规性，是指系统的运营主体或责任人要制定安全保障机制，通过网络安全、容灾备份、物理安全等技术方案，实时保障系统和数据的安全，并符合国家等级保护要求和分级保护要求。
频发的安全事件时刻挑动信息系统运维人员的敏感神经，从网上公开的资料显示：
2020 年 2 月 23 日，微盟公司员工恶意破坏公司线上生产环境及数据，导致系统服务不可用，给商家经营造成了严重的影响，并带来了广泛的社会舆论。根据各方预测，此次微盟数据库删除的直接损失大约在 40 亿元左右。在删库事件以后微盟集团在港股连续大跌，三天内市值跌逾 30 亿港元。这是典型的内部权限管理带来的安全问题，是建立内部合规性管理机制要重点关注的范畴。
2020 年 8 月，由于 IT 失误，全球会计巨头毕马威的 1.45 万个微软 Teams 用户的聊天记录被
永久性删除，且微软确认这些聊天数据不可恢复。这是典型的弱 IT 行业在应对数据安全方面的反面教材，值得所有国家的公司提高警惕，并相应改善数据安全的保护措施。
2020 年 8 月，Maze 黑客团伙声称，通过 Maze 勒索软件攻入韩国半导体巨头 SK 海力士。Maze 黑客团伙官网的屏幕截图显示，有 5% 的 SK 海力士数据被泄露，并以此作为黑客成功入侵 SK 海力士的证据。这是典型的针对知名机构发起的勒索病毒攻击的违法行为，并且与传统的勒索软件加密文件系统相比，Maze 为勒索软件找到更能攻击受害者软肋的方法，那就是先公开泄露窃 取的少数信息，如不缴纳赎金，黑客们可能会公开所有的包括敏感信息在内的数据。
综上三个公开的案例信息，针对信息系统和数据安全的合规性保护，仍将是信息技术行业不可回避的话题。中国在近年加大了包括系统等级保护、数据安全和个人隐私等领域的立法工作，并在政务、金融、医疗等行业取得显著效果。譬如，政务云的两地三中心建设过程中，信息系统应用级容灾及数据多重备份，为信息化政务的业务连续性管理提供安全可靠的支撑，确保当潜在的威胁事件发生时，业务恢复的 RTO 和数据恢复的 RPO 能够达到最小，将经济性损失和非经济性损失降到最低。
7.2.3 平台化推进灾备产业化发展 维持一个产业的可持续发展，需要构建以政策、法律、资本、人才和技术产品等为核心的产业体系。作为合规性方面的重要终端安全产品的技术方案，灾备保护的系统和数据越来越复杂，大型组织机构针对灾备产品的运维开始力不从心：运维人员要解决不同产品、不同系统、不同技术服务商在灾备方面的运维难题，包括产品的操作习惯和不兼容、没有统一的管理平台、备份系统可用性验证人力化等。
如何解决上述问题，灾备平台化以及依托平台进行智能化运维是一个可靠的方案。我们针对金融、医疗、政务和大型企业的深入调研分析发现，实现灾备平台化智能运维，可能会集中在以下三个方面：
一是云灾备平台化。云灾备包括了云平台本身提供的基础版的云备份和云容灾方案，通过分布式架构划分高可用区，为租户提供基于自身基础架构的云灾备服务。从传统的灾备架构分析，虽然可以通过不同云数据中心划分高可用区向外出租，但是作为非主营业务，灾备产品投入的产出比，还是处于艰难维持的阶段，更多是处于自身高可用方案的完整性和安全性做出的投入，发展动力是不足的，并且相比于第三方技术方案商，同等投入情况下，云平台在数据级灾备的 RPO 值更大。
另外一种更具灵活性的云灾备平台方案，是云平台联合第三方技术方案商，云平台可以弹性地提供各种云资源，技术方案商提供云灾备平台，包括涵盖数据同步和系统迁移工具，跨平台的容灾产品，定时或实时备份和 CDP 保护，用于灾备演练的独立网络等产品方案。此外，云灾备平台也向更灵活的灾备即服务方向发展，例如英方软件与运营商结合打造的 i 2 C l o u d
云平台，可以根据用户的需求，不仅可以为每个租户分配管理账号，个性化保护指定的业务系统和数据，还可以通过设 置网络带宽大小和灾备时间灵活地使用灾备产品，做到与云计算一样的按需使用和付费。
二是 CDM 超融合数据管理平台。灾备是数据复制技术典型的应用场景之一，高效的数据复制能力带来更广阔的综合应用场景。为此，复制数据管理（C o p y
D a t a
M a n a g e m e n t，C D M）是近年快速发展起来的产品，作为备受 G a r t n e r
推崇的数据管理产品，C D M
将传统的数据复制进行融合，将分散的数据集中起来，通过自动化策略，对复制数据进行集中管理，不仅可以助力企业加速
双模式 IT 运作的落地，同时可以改进数据保护的性能，缩短应用开发的周期，对业务产生直接价值。简单地讲，CDM 为用户解决了数据灾备的同时，也可以为用户提供用于测试、演练所需的真实的 业务数据，直接提高了备份数据的附加值。
经过近几年的快速发展，CDM 产品逐渐成熟，并形成基于 CDM 的超融合数据管理平台。以 i 2 C D M
超融合数据管理平台为例，该平台将数据管理的生命周期划分为四个部分：生产环境异构——从服务器到操作系统到数据库到虚拟化平台的异构；容灾环境——从字节级复制到数据库语义级复制到块变化实时复制技术，整合现有的数据复制技术，实现初始全量数据 + 持续增量数据的复制；超融合数据管理平台——提供单一黄金副本，然后虚克隆出多个任意数量、任意历史时间、可读可写的虚拟副本，节省存储资源；应用场景——应急恢复、数据迁移、开发测试、数据恢复、培训环境等。
三是统一数据管理平台。灾备解决的是系统和数据的安全问题，但是随着数据量的不断增加和数据价值进一步被挖掘，用户希望基于数据复制技术的灾备产品可以提供更多的功能，比如跨平台跨区域的结构化和非结构化数据实时同步，跨异构数据库的数据同步和跨大数据平台的数据流动管理，打破数据孤岛，实现数据的互联互通，并最终为商业智能提供可快速利用的数据报表。
以证券行业为例，一个大型的证券机构，其各种业务和管理 IT 系统多大两三百个，这些系统每天新增的各种结构化和非结构化的数据多达几个 TB，且呈现加速之势。这些数据包括客户的账户数据、交易数据、产品与服务数据、市场相关的数据、风控数据，以及机构本身的管理数据和 IT 运维数据等，通过统一数据管理平台（如英方软件 i 2 U P），可以为证券机构提供全域多层次多策略的统一数据管理，满足用户各类数据实时同步、CDP（持续数据保护）、各类数据库实时同步、各类虚拟机保护、两地三中心，异地容灾、多副本快速交付、多应用数据全面统一管理等需求。
7.2.4 灾备人才和用户群体持续增长 经过十几年的发展，灾备技术从传统的存储分支（第二存储）独立发展至今，逐渐形成了一大批专业的技术和营销人才。从技术人才构成看，分为传统型人才和新型技术人才。传统人才主要以传统的存储容灾、数据库容灾、IT 运维等技术人员为主，他们拥有资深的行业背景，对用户的 IT 运维场景非常了解，能够针对用户的灾备需求，快速提供不同层次、不同策略的灾备解决方案，在传统的本地灾备向云灾备过渡过程中，发挥了关键的作用。
新型人才以应届毕业生为主，同时随着灾备行业的快速发展，也吸引了一批其他泛 IT 行业的人才的加入。他们普遍年轻化，拥有较高的文化水平，学习和接受新事物的能力更强，以及拥有更多可以获得专业知识的网络渠道。他们的加入，给整个行业带来了活力和创造力。他们欠缺的是行业经验和知识，为此，技术服务商提供的专业工程师认证培训服务，是提升这批新型人才专业技能非常好的平台。例如像英方软件举办的工程师认证培训和 DRI 在中国举办的 CBCP、MBCP 认证等，都为中国灾备行业培养了大量的专业技术和管理人才。
伴随专业人才队伍的扩大，用户群体也越来越庞大，他们之间以正相关的关系，螺旋式推动灾备产业向上发展。目前，在政务、金融、医疗、教育、电信、能源、制造、交通等行业，凡是涉及信息系统和数据安全合规的领域，都离不开等级保护和分级保护的建设需求。为此，灾备用户是一个相当大的群体，但是由于长期由于人力成本的问题，大部分机构并没有专职的灾备管理人员，更多是通过运维人员兼职的形式，实现灾备项目的管理。但是从近几年的信息系统安全事件可以发现，专业性不够是造成很多灾备用户在发生安全事故时，仍然造成数据丢失和业务停止的主要原因。未雨绸缪，防微杜渐，随着数字化转型的加速，所有机构都应该从人员思想和习惯上培养员工的安全防范意识，做好相应的管理权限分级工作，逐步完善企业灾备人才队伍和机制体系的建设。对于重要的行业机构，更应该将灾备工作提升到二把手工程或一把手工程，并最终实现灾备与数据管理应用合二为一的目标。
第二篇：灾备建设的四大误区
灾备建设的四大误区
来源：中国计算机报
2010年08月24日11:44 我来说两句(0)复制链接 打印
大中小
作者：郭涛
企业只要投巨资建设了灾备系统，以后就不会再出现业务中断和数据丢失了吗?其实，灾难备份/恢复与业务连续性有很大的差别，不能将两者混为一谈。“对灾备的错误认知是导致灾备建设失败的重要原因。”EMC公司资深业务连续性咨询顾问许瑀表示。
容灾不等于业务连续性
一些企业领导的固有思维是：容灾与业务连续性是一回事，只要拥有了灾备系统，就不应该再出现业务的停顿。其实，灾难备份主要用于应对较大的灾难事件，而不是针对局部的事故。业务连续性的概念更宽泛，无论是局部的故障，还是重大的灾难，都不能使业务中断。
许瑀表示：“灾难备份是业务连续性的基础，是企业多层次信息保护体系的重要组成部分。为确保业务连续性，企业应优先考虑建设基本的灾难备份和恢复系统。在„9·11‟灾难事件中，美国世贸中心里数百家没有灾难备份系统的公司彻底消失了。这充分体现了灾难备份作为企业信息架构基础组成部分的重要性。在建立了完善的灾备系统后，企业可以考虑构建多层次的信息保护体系，进一步提升业务连续性水平。”
由于投入的资金数量不同，信息基础设施的状况不同，灾备建设的思路不同，不同行业的用户在建设灾备系统时，很难遵循一个统一的策略。不过，企业在建设灾备系统时应遵循这样一个原则，即无论采用何种技术手段，都必须保证数据的安全。这是灾备建设的底线。
重异地灾备 轻本地保护
“实际上，导致信息系统出现中断，97%的原因是物理设备故障和系统的逻辑错误，只有3%的业务中断是由大灾难引起的。”许瑀分析说，“本地数据保护与异地灾难恢复都非常重要。有的用户认为，只要建设了异地灾难恢复系统就能抵御所有的灾难，因此忽视了本地的数据保护。这其实是一个误区。”
许瑀举例说：“某用户的磁盘出现故障，由于换盘时的错误操作导致了核心数据库的损坏。该用户利用本地备份系统恢复数据，恢复时间长达一周，而且丢失了两天的数据。”有用户盲目追求过高的异地灾难恢复RTO和RPO指标，要求RTO小于4小时，RPO小于15分钟。但事实上，该用户在进行本地数据恢复时，RTO大于1天，RPO为24小时。用户投巨资建设灾备系统，却不能减少因本地故障带来的损失，这其实是本末倒置。许瑀认为，只有将信息系统的本地数据保护和异地灾难恢复相结合，才能构成完善的业务容灾体系。本地数据保护与异地灾难恢复防范的风险不同，因此采用的技术手段、机制和措施也不一样。有些需要面向公众提供服务的系统，对灾难恢复的时间要求十分严格。但是大多数信息系统对灾难恢复等级的要求并不太高，通常可以接受几小时的灾难恢复时间。对于大多数用户来说，最重要的不是恢复时间的长短，而是数据能够100%被恢复。
RTO、RPO指标过高
在建设灾备系统的过程中，RTO和RPO是两个非常重要的指标。那么，RTO与RPO的数值是不是越小越好呢?“某银行针对其网上支付业务建设灾备系统时，提出系统恢复时间小于30分钟(即RTO小于30分钟)，只能丢失5分钟的数据(即RPO小于5分钟)。”许瑀表示，“我看到用户的RTO和RPO指标要求时，第一感觉就是这不现实。因为银行的系统出现故障后，为了恢复数据，技术人员通常要根据日志对活动账号进行分析，而所有的日志分散在多个业务系统中，处理这些日志可能要采用手工方式。完成上述一系列步骤，银行至少要花费一两个小时的时间。”
企业在制定灾备恢复的目标时，一定要从业务的实际需求出发，不能盲目追求过高的RTO、RPO指标。过高的RTO和RPO指标不仅会增加灾备建设的成本，而且会让用户迷失在数字游戏中，对业务的保护无益。
忽视日常的运维管理
“2007年，某公司的核心业务系统发生意外宕机，多个关键业务数据库瘫痪。公司领导决定启用同城灾备系统。但是在进行恢复时，技术人员发现，容灾端数据严重滞后于生产端数据，灾备系统根本无法启用。”许瑀举例说，“事后，人们在追查原因时发现，由于系统管理员在进行灾备端测试时中断了灾备数据的复制关系，测试完成后又忘记了恢复灾备数据的复制关系，从而导致灾备系统无法启用。”
在某些企业中，灾备系统完全成了摆设。平时，这些企业的技术人员不对灾备系统进行定期检查，而且忽视了灾备演练。因此当灾难发生时，灾备系统很难发挥作用。中金数据系统有限公司高级副总裁陈天晴告诉记者，他们曾经按照合同要求为某客户提供灾备演练服务，但是客户的相关人员总以工作忙为由推脱，造成服务合同迟迟不能履行。许瑀表示：“企业在建成灾备系统后，应该定期进行灾备演练，并建立完善的业务连续性计划(BCP)，包括详细的灾难恢复计划及本地恢复计划等。
(责任编辑：王亚红)
第三篇：政府行业备份容灾解决方案
政府行业备份容灾解决方案
随着政府信息化建设进入高速发展白热化阶段，信息系统数据中心资源的整合和虚拟化正在不断发展，各级政府信息化建设的步伐也明显加快，政府电子政务建设已从服务上网向内部系统建设转型，这就要求政府必须建设一套安全易用的备份用在系统。信息系统备份容灾解决方案要求专业，高效，安全，简单易用。中科同向为政府信息系统建设建立的备份容灾解决方案属于绿色型：高可用，节省成本，安全易操作，为政府协同办公，建立友好信息环境。
政府行业信息系统表现出以下特点：
1、数据复杂。政府网与电子政务网不但是高级政府单位建设，基层也建设了完善的电子政府系统，而且全国统一搭建平台，互通，实现了全国联网统一。各部门单位数据中心统一存放，数据多样性复杂性可想而知。
2、数据中心管理人员业务繁多。作为信息系统管理人员，需要了解各方面的信息业务，包括操作知识，操作技能，各方面业务需要精通。否则遇到信息灾害时会无力回天，造成不可估量的后果。这就要求到软件的简单易用，管理人员易学易会，维护简单。
3、新旧系统连接。我国电子政务起步较晚，作为之前的大量数据需要留档。所以要求数据备份如何接洽之前的数据到存储保护恢复系统是一大技术难题。以前的数据格式可能多种多样，要求备份容灾软件需要接纳不同数据格式。
4、政府行业的特殊性。一些保密单位要求有保密级别，涉及到国家安全。数据的保护性要求更高，而且要求做到数据可以接管，做到应用级容灾。中科同向的政府行业数据备份容灾解决方案。
数据备份软件Heartsone Backup V8.0可以安装在windows、Linux、Unix等不同操作系统上，实现了跨平台安装备份。传输及备份压缩后精密算法(AES3DES)这就对数据的安全更增加了一层保护，需要主管人员用密钥打开压缩数据包。对恢复数据点击选择要恢复的数据，点击确定即可。
高度的数据备份安全需要做数据持续保护CDP。CDP技术中科同向实现了PTO=0，RPO=0，做到了零数据丢失，保证业务的连续性，在故障期间瞬间恢复数据。中科同向CDP数据保护采用了四步骤，被称为“四金刚”。
企业应用级容灾DR，对数据库日志进行抓取，分析，保持了同步数据备份容灾。对数据库、文件、系统可以做到实时增量备份，可以设置不同的备份策略，实现了局域网和异地容灾。
在未来的政府信息发展中，数据已经作为政府的关键性依据，中科同向将不断在技术上创新，和政府齐心协力，做好政府信息化建设，在数据备份容灾方面永创第一！
第四篇：工商银行上海数据中心灾备系统运维实践
工商银行上海数据中心灾备系统运维实践
一、“两地三中心”建设历程
工商银行于1999 年开启了数据中心集约化建设的先河，在北京、上海分别建设两大数据中心后，于2002年1 月在国内同业率先启动了主机灾难备份工程。经过多年的建设和持续投入，已经实现了高等级的核心系统灾备体系建设，完成了全行应用分等级灾备体系建设。为进一步提升信息系统灾难恢复能力，工商银行启动了 “两地三中心”工程建设。根据规划，2014 年将在上海嘉定建立同城数据中心，与上海外高桥数据中心构成同城双中心，同城双中心整体与北京异地灾备中心组成异地灾备模式(如图1 所示)。
“两地三中心”模式可以满足不同灾难场景下的恢复要求，实现更灵活的风险应对。在架构布局上，上海同城双中心具备基本相同的业务处理能力并通过高速链路进行实时数据同步，两个中心之间距离约55 千米，日常情况下可按主/ 备或双活模式运行。在发生区域级灾难某个中心失效时，可在基本不丢失数据的情况下进行双中心间的应急切换，保持业务连续运行。北京异地灾备中心用于同城双中心的灾难恢复，当出现因大范围自然灾害等原因导致同城双中心同时失效时，异地灾备中心可以用灾备系统接管全行核心业务。
二、“两地三中心”技术手段和实施策略
工商银行通过技术攻关，完成了“两地三中心”模式下的信息系统业务连续性架构设计和方案研究，提出了可以提供多层级业务连续性保障水平的解决方案。信息系统可以给银行业务应用提供A/A、A/Q 和A/S 等多种部署模式，最终以业务影响分析结果作为应用部署模式选型的决策依据。
在具体实施中，工商银行坚持“全面覆盖基本保障能力、重点针对关键核心应用部署高等级灾备保障技术”原则，做好资源分等级和差异化配置。如ATM、POS、柜面业务、资本市场等核心业务系统是银行的关键应用，与其相关的应用系统就具有较高的业务连续性等级。自2010 年工程启动以来，项目进展情况良好，完成方案规划设计和验证评审，在数据库复制技术全面推广、智能网管改造、55 千米磁盘同步镜像等关键技术领域取得了突破;完成了核心主机并行系统投产，即双园区模拟同城双活的试运行，目前主机并行系统主要运行可分离查询交易，分流了部分核心生产系统的负载压力;完成13 个开放平台应用服务器双活改造，预计今年将完成近50 个开放平台应用的双活改造。同时，工商银行积极探索“两地三中心”运行模式，按照“一体化管理”原则，初步制定了“两地三中心”生产运行管理方案，并对组织架构和主要职能进行了规划。嘉定同城数据中心园区基建工程按计划推进，于2011 年底奠基，2012年4 月开工，2012 年底8 万平方米基建工程结构封顶，计划今年底机房楼交付使用，2014 年嘉定同城数据中心园区建成启用，实现“两地三中心”的数据中心布局。
三、“两地三中心”安全措施
1.建立全面、系统、可持续发展的信息安全管理体系
①以安全、稳定、高效、追求卓越为安全方针建立具有工商银行特色的ISO27001 信息安全管理体系。数据中心(上海)于2011 年通过了ISO27001:2005 信息安全管理体系认证，实现在信息安全组织、资产管理、人员安全、物理和环境安全、通信及操作管理、访问控制等11个方面130 余个控制点的全方位的信息安全管理体系。同时，建立起具有工商银行特色的支撑跨地域统一管理的ISO27001信息安全管理体系，主要包括信息安全制度管理、安全生产与运维管理、安全与防控技术管理、用户与人员管理、综合管理等五大方面共107 项精细化管理制度。
②建设信息安全组织体系确保信息安全管理有效开展。数据中心成立了信息安全领导小组，作为信息安全管理最高管理机构，确定信息安全方针、目标和控制策略，明确信息安全的管理职责。信息安全领导小组定期或不定期召开联席会议，分析信息安全形势，研究中心信息安全管理薄弱环节及应对措施，贯彻落实监管部门、上级机构信息安全管理要求等。中心建立了纵、横向联系报告机制，及时掌握并报告本区域重大信息安全事件、案件线索或案件，提示风险，有效防控风险。
③信息安全管理体系随着工商银行和中心自身的发展、内外部安全形势的不断变化，与时俱进持续改进。主要措施包括：定期对人员、硬件、软件、数据与文档等各类重要资产所面临的风险进行评估，结合现有技术能力和管理成本，制定相关的补偿控制措施;利用有效的技术平台，通过完整、系统、及时的问题整改跟踪管理，将内外部审计检查发现的问题进行分析汇总，在督促及时完成整改的同时，不断挖掘制度漏洞和流程缺陷，及时完善管理体系;主动对生产故障事件、外部信息安全重大事件等进行分析研究，深入剖析问题发生和防控失效的深层次原因，进一步细化制度执行要求、强化技术硬控制、优化生产运维流程;积极与外部审计监管单位、各行业先进企业进行沟通，主动学习借鉴国际先进标准和业界领先经验，不断完善优化中心的信息安全管理体系。
2.生产运维安全措施多管齐下，确保生产稳定运行
①努力降低变更引发的安全生产问题。变更前通过变更评审会和变更协调会对高风险度变更和跨多个部门的变更进行评估和协调;变更中严格按照双人复核提交方式进行变更操作;变更后及时开展技术和业务验证。根据应用等级和对外服务时间严格控制变更窗口，严格控制紧急变更。将环境搭建和版本升级准备等相关变更活动限制在与生产环境隔离的区域，进一步降低变更操作风险。
②持续完善应急管理。制定完备的应急和灾备演练计划，开展层次丰富的各类演练，及时总结演练过程发现的问题并加以改进，定期开展南北两地互相远程接管演练等。
③ 建立了涵盖主机、网络、平台、UPS、应用、安全等各领域的集中监控报警平台，统一了监控报警事件的处理流程，使得各类报警能得以快速处理。
④ 定期对生产事件进行总结分析，找到问题根源和解决方案，避免事件的再次发生和深层次安全隐患。建立完善的事件沟通机制，通过每日、每周及不定期专项会议将相关事件发生原因、处理过程、改进措施等进行分析总结，举一反三防微杜渐。
⑤高度重视性能容量管理，建立了覆盖操作系统、数据库、中间件、网络、存储、动力、应用等领域的较为全面的性能容量指标和监控系统及指标阈值和报警规则，并结合实际生产情况、版本变化定期进行全面的指标梳理。定期开展性能容量统计分析，根据分析结果进行相应扩容、改造或资源回收。
⑥进一步完善运行操作管理，提高批量操作自动化水平，减少人为干预。通过专业系统对操作步骤制定、修改、发布、执行过程记录等进行信息化、流程化、自动化管理。实现了管理严谨、操作有序的安全生产目标。
⑦以“知其所需、最小授权、唯一鉴别、有效控制”为原则，进行各类用户权限的划分和按需发放，通过细致的访问控制，降低操作类安全事件发生的可能性。
⑧进行严格的网络区域划分，实现生产与外部网、生产与办公网的隔离。在接入网和互联网区域网络边界部署入侵检测防护设备，实现对攻击事件、DOS/DDOS 事件的检测和防护。
⑨ 通过技术手段严格落实数据访问、数据变形、数据传输、数据恢复、数据清理、数据销毁等数据管理各环节的安全管理要求。同时建立完善的客户端安全技术防护体系，包括防病毒管理、系统补丁管理、软硬件管理、外发邮件管理、互联网访问管理、电子文件安全管理、信息泄漏防护管理、笔记本硬盘密码保护管理等，实现客户端的安全准入控制和数据安全管理。
⑩通过日志集中和安全审计平台建设，对各类生产系统的人员操作、系统安全事件等进行快速和全面审计，及时发现和通报违规操作、恶意攻击、高风险操作等现象。
四、未来发展规划
未来，工商银行数据中心要努力实现生产运行管理可控、可靠、可持续的目标。可控，即对日常运维和突发问题可以主动安排和快速把控;可靠，即能提供稳定可靠运作的基础设施环境，确保全行信息系统运行不因物理设备故障而中断。可持续，即在任何时候、任何情况下均不发生对外服务中断。为此重点要做好以下几方面工作。
一是树立“安全生产第一”和“第一时间恢复生产”的指导思想，落实各项生产运行管理措施。包括提升监控的覆盖率、准确率和时效性;提升应急管理效率，确保在应急情况下，能够立即切换，第一时间恢复生产;提升生产一线发生事件的处置能力;提升变更管理和应用版本投产管理质量;提升健康检查、性能容量分析水平，提前采取预防和改进措施，切实降低重大生产事件发生概率;提升对境外机构的生产运行管理和服务，强化中心针对分行管理的专业人员的配备，完善对分行生产系统的远程实时监控能力，抓好分行机房动力设施、网络通信线路的改造升级等。
二是进一步提升信息系统的高可用性和灾备能力。要积极推进以数据零丢失和“本地双活、异地灾备”为原则的“两地三中心”建设，高标准、高质量建设上海同城中心;要积极推动应用系统灾备体系优化，根据应用灾备等级划分的要求，加快推进开放平台应用系统的灾备建设，确保关键开放平台应用系统均具备异地灾备能力。
三是加强生产运维的自动化工具研发与投入，不断提升操作、监控、维护、资源配置的自动化程度。推动实现数据中心批量操作自动化比例达到98% 以上;要全面建立覆盖各应用系统的“端到端”业务级监控，推动数据中心运行维护和资源配置的自动化，从而全面提升数据中心例行化工作的质量和效率。
四是以风险管理为核心，建立覆盖全流程的信息安全管理体系，不断提升信息安全管理水平。通过风险评估的方法，建立、实施、运行、监视、评审、保持和改进信息安全工作的流程与规范。
五是建立科学合理的人力资源配置和激励机制，加快建设数据中心专业化人才队伍。要合理配置人力资源，加强行业领军人才和高级专业人才培养，建立人才梯队，稳定人才队伍。
第五篇：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选项
点击咨询 