HP BusinessCopy同城/异地容灾技术方案-CSDN博客

本文链接：https://blog.csdn.net/dsg_gulibin/article/details/1689828

1.1 什么是计算机业务系统的灾难

今天， XXXX 比以往任何时候都更加依赖于计算机系统，计算机系统在为 XXXX 迅猛发展提供技术基础架构的同时，由于用户业务处理的高度集中，以及不可预见的故障和灾难，导致整个系统存在很多灾难性破坏的隐患，有可能成为整体系统中的单故障点。因此，业务的拓展与灾难的防范是所有用户都必须同步重视的问题。那么，什么是计算机业务系统的灾难呢？通常的定义是指采用计算机系统处理的重要电子数据丢失至不可恢复或由此导致业务中断以至于延长到不可接受的时间。

1.2 国外计算机业务系统灾难备份应用情况

灾难备份计划在发达国家电信行业和金融行业得到了较早的实施，现已较为普遍。例如在美国，因一九八五年纽约银行计算机故障，联邦管理部门更加强了在这方面的监管力度。现美国计算机业务系统一般出于以下三方面来考虑灾难备份计划：

重要数据保护与业务连续运行的需要： 在美国，各行业内部竞争激烈；在计算机管理制度上较为完善；一旦因突发灾难而造成数据丢失或业务中断，将会造成重大乃至致命的打击。

审计的要求： 美国较大型的企业一般会由第三家独立审计公司来提供其资信业务、管理等方面咨询服务，而世界著名的六大审计公司在对企业的评估项目中均包含灾难备份计划一项；评估企业数据在灾难等威胁破坏下数据的完整性，一致性与安全性，及业务的可恢复性等，有些咨询审计公司还会参与验证所制订的容灾计划的具体过程和其可行性。缺少灾难备份计划及其危害性会在评估报告中被显示出来。

法律的要求 ：美国政府及州政府通过多项法律强制性要求电信、金融业等大型企业备有计算机安全及灾难备份计划。对于没有遵守这项灾难备份计划的企业，会遭受曝光及罚款等严重处理，同时亦可能对相关责任人采取罚款甚至监禁等处罚。已知的灾难例子有：日本神户大地震、美国佛罗里达州飓风（数百家企业实施了灾难备份计划）、台湾大地震等。

1.3 国内计算机系统的灾难备份计划的应用情况

随着我国入 “ 世 ” 的脚步越来越近，传统产业在进入新市场新方式的竞争中，企业的电子信息架构的搭建，成为最具有战略意义的资源投资。作为信息架构核心的数据，其安全备份和灾难恢复随着世纪交替 Y2K 问题的引发，逐渐引起人们的思考和重视。现代企业必须直面一个迫在眉睫的问题：如何对数据进行持续不断地存储，并通过有效地应用这些信息，提高企业的利润率和竞争力。所以，在当今企业运营电子化的进程中，存储将与网络、软件应用和系统 CPU 处于同等重要的地位，成为决定系统成熟与否的关键。

由于存在着各种数据丢失的可能，随着人们对网络系统的依赖日益增加，从硬件到软件对数据的保护和备份确实是不容忽视的环节。企业的 IT 专家们逐渐认识到，可能造成数据丢失的因素主要有三种：自然灾害的灾难性破坏造成数据永久丢失，最佳的解决方案就是异地数据备份；计算机和网络系统的硬件和软件故障，这种损失也只有通过完整的数据备份来弥补；另外，自然免不了黑客的破坏以及人员的操作失误。这些事故的发生都是防不胜防的，唯一能把损失降到最低的办法就只有依赖具有数据备份和灾难恢复功能的存储设备。近年来国内用户在计算机应用方面的飞速发展，计算机系统基础架构的建设、特别是计算机容灾系统的设计与建设正逐渐被用户所重视。不言而喻，如果用户的业务系统有一套完备的灾难备份 / 恢复体系，当突发性灾难发生后，业务系统关键业务数据的损失将减至最小。特别是随着中国加入 WTO 的日益临近和行业竞争越来越激烈 , 完善的灾难备份 / 恢复体系在不远的将来将是国内企业发展的可靠保障。

在国内，随着 Internet 的逐渐普及和电子商务热潮的兴起，企业需要整合越来越多的数据，而数据的合并、管理、分享、保护都需要一个强大的、高可靠性的数据中心；同时，随着国内企业经营者对企业数据信息的价值和数据安全备份的认识的提高，存储设备的投资也正在企业信息化建设的投入中占据着越来越高的比重。 IT 行业权威人士认为，在将来的一至两年中，数据存储系统要花费所有企业计算系统投资的 70 ％。

1.4 建设灾难备份中心的重要意义

随着计算机管理技术和网络技术的发展，为了提高企业业务管理水平、增强企业市场竞争能力，越来越多的企业开始使用计算机来处理内部日常事务和外部业务往来，从而使得这些企业越来越依赖于系统管理数据和业务信息。尤其是在企业业务不断增加、数据量成倍增长乃至出现数据膨胀现象时，由此引发的企业从数据膨胀、到计算机性能提高、再导致新一轮数据膨胀的循环不断加剧，进而在企业中引起新的数据安全恐慌，数据失效问题时有发生。建设灾难备份中心的目的就是在于防止一些灾难性的小概率事件可能对集中式信息系统造成的不可恢复的原始数据的丢失，这些灾难性事件可能包括为火灾，地震，电源故障及一些人为的操作失误等，如下图所示。

现代企业管理非常重视总体拥有成本（ TCO ）。所谓 TCO ，实际上是由实际成本、使用成本和风险成本三项组成。实际成本和使用成本在企业的建设与生产中往往容易引起人们重视，因而考虑得非常周到。而风险成本不仅是企业看不见、摸不着的东西，也是企业运作时很难预料和把握的内容。在使用计算机系统的企业中，风险成本包含用于管理关系到企业生命的各项数据与信息的安全、正常、可靠的高速运行的所需费用。所以，为将风险成本降至最低，同时使企业长期处于最佳状态，对企业业务和计算机管理与控制系统数据进行全面存储备份是一项绝对值得的、也是必要的投资。

我们知道，随着企业计算机系统建设计划的逐步实施， XXXX 的日常业务同计算机系统的联系越来越紧密。因此，业务主机系统的运行出现故障所带来的业务影响范围会被迅速扩大，而客户对企业计算机业务系统的连续运行，业务系统、用户数据的高可用性以及业务计算机系统抵御突发性灾难的能力的要求也必然急剧提高。

XXXX 建设灾难备份 / 恢复中心有如下的意义：

Ø 重要业务数据在灾难发生后得以有效保护

Ø 重要业务在灾难发生后可以在设定的时间内恢复，从而实现业务的连续运行

Ø 业务计算机系统抵御突发性灾难的能力和级别提高

Ø 进一步提高 XXXX 声誉，增强客户及潜在客户的信心

Ø 扩大对同行业竞争对手的优势

第二章灾难分析

可能发生的灾难因各城市 / 地域的地理、气候、社会治安、城市管理，如供水、供电、通讯条件等差异而有所不同。仔细地分析各种突发性灾害发生的可能性以及由此所造成的后果，对于制定和构建完整的和有很强针对性的灾难备份体系是有很大帮助的。

下表是一张分析表样本，可使我们对于可能发生的突发性灾难评估有较为清晰的概念。

可能的灾难	可能性：
	1	2	3	4	5
工作场所火灾
数据中心火灾
电源故障
气候灾难（台风，洪水等）
工业破坏
城市事件（罢工，动乱等）
硬件故障
软件故障
设备问题（如管道漏水等）
供水故障
通讯系统故障
计算机故意破坏（如病毒等）
爆炸威胁
工作场所的环境紧急事件（化学污染等）

第三章灾难备份设计目标

3.1 灾难备份的设计目标

采用何种容灾方式（逻辑数据复制／物理数据复制）实现灾难备份系统的设计目标主要应从以下四个方面来考虑：

具体数据类型与目标的灾难保护： 从用户业务系统正常运作的角度分析各种关键业务数据，作出重要性与可恢复性要求的评估，并由此制定系统的数据灾难保护政策。

灾难发生后的可恢复业务分析： 对用户各种业务与管理流程进行分析评估，并据此制定出用户核心业务系统的灾难备份 / 恢复策略。

灾难发生后的可恢复分析： 对于突发性灾难这样的重大事件，有时受灾地区并不苟求所有业务系统都能够可持续运营，故可按实际需求和比例进行分析，并由此配置相应的容灾设备。

灾难发生后的业务可恢复时间指标： 可以将灾难的发生分为两类，一类是可以预计具体时间的灾难，如损害性极大的台风等；另一类是不可预计具体时间的突发性的灾难，如地震、主机系统的非计划性 Down 机等。针对两种不同的灾难类型，要设定不同的业务恢复时间指标。一般来说，对第一类灾难的业务恢复时间要大大短于对第二类突发性灾难的业务恢复时间．

根据用户对系统容灾能力的不同要求以及投资方面的因素， HP 公司提供多种容灾解决方案，各有侧重不同，我们会从不同的角度介绍容灾系统的实现方法，以及系统的典型配置。

第四章灾难备份设计思路及模型

为了设计与实施 xxxx 的灾难备份系统，按照大型项目的管理方法和ＨＰ公司在项目管理方面所积累的丰富经验，在这里将整体项目的设计与实施分为五个阶段：

4.1容灾项目开始

Ø 明确 xxxx 灾难备份／恢复计划的必要性

Ø 明确灾难备份计划的负责人和实施队伍

Ø 制定项目实施时间表。

4.2灾难风险分析

Ø 确定对 xxxx 业务至关重要的系统、网络和用户

Ø 确定由于自然或人为灾难对这些造成的威胁和损失，并尽可能准确为具体的损失

Ø 收集各种业务和用户对系统中断时间等的要求

4.3制定恢复计划

制定当灾难发生，原业务主机系统或网络系统不可用时，提供第二主机（灾备主机）或网络（灾备网络）的选择策略。

4.4方案实施

开始实施灾难备份计划，如数据实时在线备份、应用系统切换、记录本地数据备份的磁带管理等。

4.5支持与维护

由指定的人员、部门或公司提供容灾系统的日常支持与维护服务，保证灾难备份／恢复系统的可持续，高可用运行。

以下为容灾方案实施各阶段的框图：

项目开始

灾难风险分析

方案实施

支持与维护

制定恢复计划

对于其中的核心部分－第三项“制定恢复计划”，根据 xxxx 的业务特点，这里分为以下几个步骤：

1 、制定业务主机系统集群系统热备份计划：包括对服务器、操作系统、应用系统、数据库系统、重要数据等的热备份计划。

2 、制定位于生产地的、与业务主机系统相关的前置服务器数据热备份计划：包括对其他机型的操作系统、数据库系统、应用系统、重要数据和通讯配置等的热备份计划。

3 、制定网络通讯备份计划：对网络设备、网络协议、网络参数设定、故障切换的逻辑过程、通讯线路的备份计划等。

4 、制定客户端备份计划：包括终端设备，终端用户的注册与权限管理的备份。

5 、制定磁带备份计划：包括系统备份、非系统数据文件备份、业务数据库数据备份，及与备份系统相关的其他全量备份、增量备份等，以构成完整的系统保护措施。

6 、制定灾难备份指示系统：此系统用来提供清晰全面的灾难备份指南，可以在灾难发生时在最短时间内找到灾难备份流程，与相关负责人和供应商的联系方式，以及应当采取的应急措施等。

如下为流程框图：

第五章 xxxx业务系统灾难备份／恢复体系设计

5.1 灾难备份／恢复体系总体设计

惠普公司为xxxx业务系统提供的灾难备份／恢复方案可以满足用户对于计算机系统、数据的最高保护要求，保证即使发生断电，火灾等严重灾难时，用户业务也可以7x24小时的连续运行，同时确保业务数据在主中心和备份中心得到及时的更新，保证用户数据最大的完整性。根据惠普公司多年来所积累的实施高可靠性灾难备份／恢复解决方案的成功经验，我们可以承诺用户在最小的投资范围内，按照惠普公司的项目实施流程，在最短的时间周期内达到整个项目的设计目标，并且通过惠普公司完善周全的售后服务体系，确保XXXX核心业务计算机系统的全天候、安全、稳定的运行。

由于用户数据中心的核心业务系统相对集中，因此在数据中心实现关键业务数据的规范化的本地数据备份是灾备系统建设的前提基础；

同时通过进行重要业务数据的远程同步实现用户重要业务数据的远程异地存储，为实现业务系统的远程正常运作奠定坚实的基础；

容灾系统的关键就是远程生产数据的自动复制，由于用户的应用均为基于数据库的联机事务处理（ＯＬＴＰ）业务系统，所以业务数据远程复制的关键就是确保数据库数据的完整性、连续性，实时性和可恢复性。而现在惠普公司基于用户不同的容灾需求所提供的灾难备份／恢复方案主要有以下四大类型：

1) 通过应用程序来进行远程数据复制（应用层次）；其主要原理就是通过修改应用程序或者使用BEA等公司的中间件产品，使得前端平台在向数据库服务器发送生产数据时，同时向主数据中心和备份数据中心均发送交易数据，主数据中心处理交易数据并返回处理结果，备份中心在正常情况下，只处理交易数据，当主数据中心无法正常工作时，备份中心服务器接替主中心服务器向前端平台返回处理结果。

2) 利用数据库厂家的软件产品完成远程数据备份（数据库层次）；现有的一些数据库厂家例如Oracle数据库可以提供STANDBY数据库功能，通过通信网络将实际数据库日志文件传至备份中心存储系统，备份中心的STANDBY数据库按照主数据库结构从日志文件中重新恢复数据库；又例如Informix数据库可以提供HADR(High-Availability Data Replication)功能，在初始化时将主数据中心的数据库中的所有dbspace进行一次零级备份，并恢复到备份数据中心的数据库中，之后主数据中心的数据库服务器可以通过通信网络将生产数据库的逻辑日志文件传送至备份中心的数据库服务器，备份中心的secondary数据库将这些逻辑日志恢复到相应的dbspace上．

3) 利用主机上安装的操作系统级镜像软件进行远程数据镜像（系统软件，如HP-UX MirrorDisk/UX，Veritas Volume Replicator等）；主中心存储设备与备份中心存储设备进行逻辑卷镜像，主机同时将数据分别写到本地和远程的磁盘设备上，实现业务数据的远程复制。

4) 通过惠普最新存储产品XP系列磁盘阵列（磁盘阵列硬件层次），可以实现主数据中心和备份中心的操作系统、文件系统、数据库、应用程序的实时远程拷贝复制。主、备中心ＸＰ磁盘阵列本身就可以通过阵列上的微处理器完成数据的实时同步功能，将灾难发生时关键数据的损失降至最低，而且不需要主机干涉或占用主机资源，可以做到灾难发生的同时实现应用处理过程的恢复。远程备份系统的重新启动可以做到象一般输入电源故障后的重新启动那么简单。

以下是对各种容灾实现方案的总体比较：

	数据量	应用复杂度	数据实时性	对主机性能影响	带宽投资成本
交易数据备份	交易数据	高（可能修改应用）	低	<10%	几十万
数据库日志备份	2-4 倍交易数据	数据库工具	可能至少丢失1个LOG	较高（10-20%）	几十万
镜像软件	4-8 倍交易数据	应用透明	高（I/O级），网络／镜像软件故障影响主机业务	高（10-30%）	几百万
磁盘阵列	4-8 倍交易数据	应用透明	高（I/O级）	无	几百万

5.2 应用层方式容灾结构简介

利用应用层容灾方式建立针对用户业务的灾难备份系统，其主要原理是通过应用程序或者中间件产品同时向主中心和备份中心传输未经处理的生产数据，主中心服务器和备份中心服务器同时处理数据。在正常情况下，只用主中心和业务系统联系，备份中心只在后台处理数据；当主中心瘫痪时，由于备份中心也存有生产数据库，也存有生产数据，所以可以迅速接管业务。由于是利用应用软件来实现数据同步及保证一致性的，因而对于硬件方面的影响较小。如图所示：

这种方案的主要优点就是：

a) 由于通过网络传输交易数据时未经数据库处理，所以传输数据量小，对传输数据的网络带宽要求不高；

b) 传输数据过程中，主中心和备份中心异步进行，由传输距离产生的延迟和通信带宽瓶颈不会对应用产生较大影响．

缺点是：

a) 对应用程序修改较大，增加应用软件商二次开发负担；

b) 由于主，备数据中心的业务处理过程为异步进行，如何保障数据的一致性非常困难，需要在应用中对数据的同步进行周密的设计；

这种容灾方式适合于传输距离极长（几千公里），且网络传输带宽和通信质量无法得到有效保证的用户环境．而对于存储设备则没有严格的限制，用户可以灵活的选择满足容量和速度要求的存储设备。

5.3 数据库方式容灾结构简介

5．3．1 原理

数据库方式由于只是传送数据库日志，与应用没有直接关系，因此无须对应用程序作大量修改。以下介绍主要以 Oracle 和 Informix 数据库为主。数据库方式容灾通过数据复制把数据定期、在线地复制到目的地的机器上去，以保持分布在不同地方的两个或多个数据库系统内容的一致性，来实现数据保护。但它将消耗大量的主机资源（至少要占用监控和复制两个进程）。复制的对象是数据库的处理单位，如事务日志（逻辑日志），实现方式也有同步与异步两种，严格来讲，这种方法很难有真正的同步方案。因为同步数据复制要求做任何一笔交易，都要实时地将结果发送到远程的站点中，等远程操作结束后，再执行下一笔交易；而在实际操作中，很难做到这一点，只能做异步的数据复制。所以一个实时应用系统中，一般采用异步方式。

备份数据中心通过网络连接到中央数据中心。在正常情况下，Oracle数据库运行在主数据中心的服务器上，数据存储于主数据中心的磁盘阵列中。利用 Oracle 数据库提供的 STANDBY 数据库功能，可以通过通信网络将实际数据库日志文件传至备份中心存储系统，备份中心的 STANDBY 数据库按照主数据库结构从日志文件中重新恢复数据库，以保持数据的一致性。一旦中央数据中心出现问题，用户可以立即启动备份数据中心的备份数据库以及相关应用。

Achive log的备份方式

这一实现方式的关键在于通过一个专用程序将主数据中心的数据库中的 Achive Log 定时通过通信网络传输到备份中心的数据库中。一旦主数据中心不能提供服务，备份中心首先通过 Redo Log 恢复数据，然后再代替主数据中心恢复应用。

基于数据库方式的容灾能够把变化了的数据定期、在线地复制到目的地的机器上去。对用户来说，这种复制方式的优点是能够较好地保证数据的一致性，但它将消耗大量的主机资源（至少要占用监控和复制两个进程）。

此方案可以做到在有限的投资范围内，充分利用现有机器设备，实现应用系统和重要数据的灾难恢复功能。作为惠普公司成熟的灾难恢复技术，此方案已经在国内许多用户中成功实施过。其中包括：上海浦东国际机场灾难恢复系统等。

建立远程容灾环境：

l 利用中央数据库的全备份（零级备份）建立灾难备份数据库

l 由专门进程负责传输中央数据库生成的日志文件到远地，这里可以通过定义日志文件大小及传输时机来控制灾难发生时的数据损失尽量降低，并可加快容灾应用切换速度，尽快恢复业务在备份数据中心系统上运行。

l 灾难备份数据库使用传输来的日志文件（ Archive log 或 Logical log ）不断更新备份数据库，这时数据库一直处于恢复状态（ Informix 数据库为 quiescent 状态），其数据不可被访问（对于 Informix 数据库，备份数据库中的数据可被用来进行读操作，但无法进行写操作）。

l 灾难备份数据库更新出错且无法解决时，应重新建立备份数据库。

l 灾难备份数据库应定期做激活测试，以确保其在关键时刻的可用性。

l 应用系统需考虑发生灾难时如何将联接切换到灾难备份数据库。

容灾切换：

l 将中央数据库的可取得的日志文件传至灾难数据库后，将灾难备份数据库更新到最近点，并开启数据库供应用系统使用；

l 立即对灾难数据库做数据库全备份；

l 对损失的数据进行修补；

l 以建立灾难数据库的同样方式建立中央数据库，并将运行系统切换回中央数据库，该次切换可做到数据无损失；

l 立即对中央数据库做数据库全备份；

l 重新建立灾难备份环境，恢复容灾系统．

5．3．2容灾环境维护（中央数据库结构发生变化）

日常管理中，需对中央数据库的归档日志（逻辑日志）目录定期进行备份和清理，亦需清除灾难备份数据库的归档日志（逻辑日志）目录中使用过的归档日志（逻辑日志）。

在系统运行过程中，可能发生改变中央数据库结构的情况，这时需要进行适当的操作使灾难备份数据库跟上更新变化，保持数据库结构的一致和同步：

1 增加数据文件

在中央数据库上增加数据文件将产生相应的日志，当被施用到灾难备份数据库时控制文件中会加入此数据文件名，此时如灾难备份数据库能在相应目录找到此数据文件，恢复操作继续；否则会停止，在继续恢复操作之前，需选择以下操作：

- 将此新数据文件拷贝到灾难备份节点的相应目录下；

- 在灾难备份数据库上执行命令Alter Database Create Datafile ‘filename’．

2 数据文件更名

对中央数据库的数据文件进行更名，需要刷新灾难备份数据库控制文件，或在对中央数据库作该操作时亦对灾难备份数据库作类似操作，即可确保中央与灾难备份数据库的同步。

3 修改联机日志文件设置

在对中央数据库的联机日志文件进行增加、删除等操作后，都不会影响灾难备份数据库。但在中央数据库上执行命令Alter Database Clear Unarchived Logfile，或以Resetlogs选项打开数据库，则会使容灾备份数据库失效，因为容灾备份数据库无法得到进行恢复操作所需的归档日志文件，这时需要重新建立容灾环境。

4 修改控制文件

若在中央数据库上使用Create Controlfile命令执行以下操作，将使容灾数据库的控制文件失效：

- 改变联机日志组或文件的最大数目参数

- 改变数据文件的最大数目参数

- 改变并发打开数据库的实例的最大数目参数

此时需要刷新灾难备份数据库控制文件。

在中央数据库上使用带Resetlogs选项的Create Controlfile命令将在下一次打开中央数据库时重置联机日志，日志序列回到1，从而导致容灾备份数据库失效。

5 数据库启动参数

建议使中央数据库与灾难备份数据库的参数配置相同，以免因参数不同影响容灾数据库的性能甚至恢复操作的实现。

6 刷新灾难备份数据库控制文件

当中央数据库控制文件发生改变时，依照以下步骤刷新灾难备份数据库的控制文件：

- 停止灾难备份数据库的恢复操作

- 关闭灾难备份数据库

- 在中央数据库上执行命令Alter Database Create Standby Database Controlfile As ‘filename’ 创建供灾难备份数据库使用的控制文件

- 在中央数据库上执行命令Alter System Archive Log Current归档出当前日志

- 将上两步产生的控制文件及归档日志文件传送至容灾节点

- 启动灾难备份数据库在Nomount状态，执行Alter Database Mount Standby Database使数据库处于Mount状态

- 进行灾难备份数据库的正常恢复操作

7 关于Unrecoverable操作产生的数据

中央数据库上用Unrecoverable选项操作（如Create Table…unrecoverable）产生的数据更新不生产日志，因此无法传送到灾难备份数据库，此时只能采用以下三种方法之一：

- 在灾难备份数据库中，使受该操作影响的数据文件处于Offline状态。灾难切换后，删除灾难备份数据库中相应的表空间。该方法在允许损失此整个表空间数据时才能使用。

- 重建容灾环境

- 在中央数据库上备份该操作影响的表空间，归档当前的日志，传送到容灾节点后，开启灾难备份数据库的恢复操作。

注意：如在中央数据库做了Unrecoverable操作，而未采用以上方法进行操作，仍在灾难备份数据库上进行正常恢复，将不会有错误信息提示，该错误信息将出现在数据库日记中（$ORACLE_BASE/admin/<sid>/bdump/alert_<sid>.log）。因此管理员必须定期检查数据库日记。

5．3．3 优缺点比较

用数据库功能实现远程数据复制的优点为：

a) 支持广域网协议，备份中心地点不受传输距离影响；

b) 硬件／软件投资较少；

缺点主要为：

a) 传输归档日志或逻辑日志需占用主机资源（ＣＰＵ，内存，网络等 , 具体指标未确定）；

b) 当灾难发生时，业务无法在备份中心得到迅速恢复；

c) 备份中心的数据无法快速恢复回主数据中心，从而应用无法快速切换回主中心运行；

d) 无法实现非数据库数据的远程复制；

此种容灾方式适合于只远程备份数据库数据，传输距离较长（几百公里以上），且网络传输带宽不大的用户环境．

5.4 镜像软件容灾方式结构简介

利用操作系统层的镜像软件 , 如 HP-UX MirrorDisk/UX ，实现本地主数据中心的逻辑卷和远端备份数据中心的逻辑卷之间的实时同步数据复制．当主数据中心发生突发性灾难时，用户可以通过在备份中心服务器上激活相应的卷组和逻辑卷，进而启动备份中心服务器上的数据库和应用系统，从而实现业务系统灾难恢复的目标．

正常情况下，业务系统运行在主中心服务器上，数据存储在主中心磁盘阵列中，同时在备份中心配置相同容量的磁盘阵列。主中心和备份中心的距离通常限制在 10 公里左右，主中心的服务器使用光纤通道卡通过光纤交换机和光缆分别连接两个中心的磁盘阵列，利用服务器端的镜像软件对数据镜像存储。

在发生灾难时最严重的损失就是数据本身的丢失，而磁盘镜像要求向磁盘进行的每个物理写操作都被复制到另一个地点的另一个磁盘。因为复制是向磁盘进行的物理写操作，所以它与应用程序无关。在主中心因故出现存储阵列损坏、瘫痪时，备份中心的数据仍然完好。主中心的服务器仍能正常的访问备份中心的数据。一旦主中心的磁盘阵列恢复后，可以在系统上使用磁盘重新镜像的命令将数据进行同步，从而备份中心的阵列中的数据会拷贝到主中心的存储阵列中。

镜像软件容灾方式优缺点比较．

优点：

· 可完全确保数据复制的完整性，一致性；

· 容灾结构相对简单；

· 对磁盘子系统透明，主／备数据中心可采用不同的磁盘阵列设备．

缺点：

· 远程数据复制操作占用主机较多资源（１０－３０％）；

· 主中心应用系统写操作性能受主／备中心传输距离影响较大；

· 网络连接和镜像软件故障将导致主中心业务系统的中止；

· 备份中心更新数据无法快速恢复回主数据中心；

这种容灾方式适用于对主机写操作性能要求不高，而且业务系统可以忍受因光纤传输线路的临时故障而导致业务中止的用户环境．

5.5 XP磁盘阵列容灾方式结构简介

惠普公司XP阵列由 Continuous Access XP/XP Extension软件提供完全的灾难备份/恢复功能。

主数据中心和备份数据中心的结构基本一致：采用 HP XP 系列磁盘阵列作为中心存储，所有主机通过光纤与磁盘阵列相连。磁盘阵列上运行 Continue Access XP 容灾软件。主中心与备份中心之间的 XP 磁盘阵列物理上通过两条光纤通道直联，采用 XP 磁盘阵列上的容灾软件 Continue Access 做到两地数据实时同步。两套磁盘阵列之间数据一致性依靠磁盘阵列本身的专用软件（直接运行在磁盘阵列上）来完成，完全不依赖主机系统，也不影响本地应用的响应速度。

当配置了Continuous Access XP/XP Extension软件的两台XP阵列分别处于两数据中心时，通过光纤线路进行连接，主数据中心的XP存储磁盘阵列可以随时自动将更新后的数据传送至异地的备份XP存储设备，以保持两台XP阵列数据的完全一致性。整个工作由XP阵列本身完成，对主机系统完全透明，不需占用任何主机资源。当主数据中心由于地震，火灾等各种意外原因导致整个主中心核心业务系统崩溃时，异地备份系统将完全接管全部工作，在极短时间内，恢复业务系统的运行。

客户端也是灾难备份恢复系统防护的对象，需要通过网络连接到灾难备份中心运行系统。灾难备份中心运行系统具有重构运行环境的能力，在灾难发生后替代生产中心行使运行系统职能，接受客户端注册和访问，其运行环境和业务数据由备份服务器和备份数据系统提供。

特点：传统的灾难备份系统主备机切换的过程为

1）主机发生故障

2）系统切换到备机

3）修复主机

4）关闭全套系统包括主机及备机

5）将系统从新切换回主机

其中在第4个步骤中，用户将不得不承受停机所带来的损失。

而惠普公司SureStore E Continuous Access XP/XP Extension软件将使用户避免这一损失，因为当系统从主机切换到备机后，备机将成为主机，修复后的“主机”成为备机使用。

此方案最大的优势就是对主机应用完全透明，所有数据复制工作由磁盘阵列硬件层完成，不需修改应用，而且可以保证大量数据复制的性能。由于磁盘阵列数据复制原理是利用磁盘远程镜像功能，所以可以保证主数据中心关键业务数据和备份中心关键业务数据的完全一致，而且容灾系统实现起来非常简便。还可以充分利用现有服务器设备，实现应用系统和重要数据的灾难恢复功能。作为惠普公司成熟的灾难备份／恢复技术，此方案已经在国内外许多用户环境中成功实施过。其中包括上海热线，大连电信，云南建行，湖南建行等灾难备份恢复系统。由于XXXX的容灾距离，用户环境和业务需求也十分适合于使用ＸＰ磁盘阵列实现存储硬件层的灾难备份恢复方案，因此ＨＰ公司也向XXXX推荐这种容灾方式．

而这种容灾方案的主要限制就是由于在磁盘一级进行数据复制，对应用系统完全透明，所以相比应用层和数据库层的容灾方式，复制的数据量较大，对光纤数据链路传输质量和传输带宽要求较高．

优点：

1、目前而言是所有异地容灾方式中最为可靠和成熟的技术；

2、有磁盘阵列自身来完成，完全不影响主机的性能，也不依赖于操作系统的平台，因此形式所有实现方式中性能最好，使用范围最广泛的一种；

3、通过磁盘阵列之间的专用互连完成通信，因此不占用局域网资源。

缺点： 投资较大

5．5．1灾难恢复系统硬件，软件配置说明

我们推荐数据中心的中心磁盘阵列采用 HP 的高性能全光纤通道交换式结构的磁盘阵列 XP512 。为了适应当前数据中心越来越明显的存储中心化趋势（即：存储作为整套系统的关键，各种平台的服务器作为存储的外设）， XP512 与传统的磁盘阵列相比已经不是单纯的硬盘堆叠，而是新一代的存储 + 服务器结构。 无论从它的硬件结构还是直接运行在 XP512 上的多种多样的软件都可以明显的感觉到这一点。系统的数据存储在主中心存储磁盘阵列XP512中。同时在异地备份中心配置相同结构的存储磁盘阵列XP。

由于XXXX的容灾环境距离为10公里左右，从数据复制的性能以及数据复制的完整性和一致性方面考虑，建议用户在主中心和备份中心之间构建单模光纤线路用于传输备份数据，并选用DWDM（密集波分复用）设备实现数据复制链路的多路复用，从而提高数据复制的传输带宽，并改善远程数据传输性能。

通过HP公司提供的灾难备份恢复软件(HP Continuous Access XP) 可以自动实现主中心存储数据与备份中心数据的实时完整备份。在主数据中心，按照用户要求，还可以配置磁带备份服务器，用来安装HP备份软件Omniback II，以及Sure Store E磁带库。备份服务器直接连接到存储阵列和磁带库，控制业务系统的日常数据的磁带备份。

为确保用户主数据中心的主机系统的负载分担，容错能力等功能，惠普公司提供了先进的，具有高度可靠性的群集结构。该结构可由两台或多台HP 9000/800 系列高档服务器组成，并通过LAN 和共用硬盘构成协调、高效的群集结构。当Cluster中的某个节点出现异常(服务器硬件,系统软件,应用程序和局域网故障等)时，MC/ServiceGuard可以及时发现故障节点，自动将故障节点的当前应用系统迁移到其它正常节点中，使之继续进行正常的业务处理，并可自动隔离故障节点以便于技术人员的故障排除工作，从而消除核心业务系统中的单故障点。

主数据中心的配置为：

部件名称	数量	说明
XP512 1 台：
高速数据缓存	4	4 块 x 4GB( 每块 ) =8GB
磁盘柜	1
73GB 光纤磁盘	88	22 组 x 4( 每组 ) x 73GB =6424GB
HOT SPARE 磁盘	2	22 组 x 4( 每组 ) x 73GB =6424GB
指令内存	2
主机接口卡	2
Command View XP	1	不依赖于平台的基于 Web 的控制管理软件
LUN Configuration XP	1	LUN 配置、管理软件
存储光纤交换机 2 台：
光纤端口	24

备份数据中心的配置为：

部件名称	数量	说明
XP512 1 台：
高速数据缓存	4	4 块 x 4GB( 每块 ) =8GB
磁盘柜	1
73GB 光纤磁盘	88	22 组 x 4( 每组 ) x 73GB =6424GB
HOT SPARE 磁盘	2	22 组 x 4( 每组 ) x 73GB =6424GB
指令内存	2
主机接口卡	2
Command View XP	1	不依赖于平台的基于 Web 的控制管理软件
LUN Configuration XP	1	LUN 配置、管理软件
存储光纤交换机 2 台：
光纤端口	24

5．5．2 XP CA软件容灾原理

XP (MCU)

RCP

XP (RCU)

服务器（主）

服务器（备）

Fiber Channel连接

CA磁盘卷组

拷贝方向

SVP

M-VOL

R － VOL

LCP

REMOTE CONTROL

(TCP/IP)

M-VOL

SVP

(TCP/IP)

（ 1 ） CA 磁盘卷组

CA 的磁盘卷组由不同的 XP 磁盘阵列装置内或不同 CLUSTER 内命名为 M － VOL 和 R － VOL 的 2 个逻辑磁盘卷构成。在具有 CA 磁盘卷组关系后，

M － VOL 被称为主磁盘卷。 M － VOL 可被读 / 写。

R － VOL( 远程磁盘卷 ) 被称为副磁盘卷。在 XP 磁盘阵列内部的控制装置的作用下， M － VOL 的内容和服务器来的写数据被拷贝到 R － VOL 。 CA 卷组建立后， R － VOL 为只读磁盘卷。在一个 XP 设备内部，既可有 M － VOL ，也可有 R － VOL 。这样可以实现双向的数据境像。

（ 2 〕 MCU 和 RCU

MCU( 主磁盘控制器 ) 和 RCU （远程磁盘控制器 ) 分别和 M － VOL ， R － VOL 相连， MCU 控制由服务器来的写向 M － VOL 的数据的写操作，还控制 M － VOL 和 R － VOL 之间数据拷贝的操作。并且提供 CA 磁盘卷组的状态和构成的管理。

RCU 执行由 MCU 发出的写命令操作。写操作的执行方法和执行服务器来的写操作过程相同。除此之外， RCU 还具有管理一部分 CA 磁盘卷组的状态和构成信息的能力。

对于任何一个磁盘卷组，都需要定义 MCU/RCU 。一个 XP 设备的磁盘控制装置在控制 M － VOL 时，可作为 MCU 使用，当控制 R － VOL 的时侯，又可作为 RCU 使用。

（ 3 ）远程备份的连接

MCU 和 RCU 之间由专用光纤 (ESCON) 来连结。当光纤直联，不增加任何设备时，两台 XP512 之间最远可相隔 3KM 。

在两台 XP512 之间加入 ESCON 的延长装置 (ESCONDIRECTOR 或 REPATER) 可使磁盘阵列间的距离最大延长至 43KM 。如果使用 E3 或 ATM 远程电信协议，在两台 XP512 之间将不会有距离的限制。加入 ESCON 延长装置的连接图如下图所示：

通过 ESCON 光纤通道， MCU 和 RCU 可相互进行数据传送和控制命的传送。在构筑 CA 时，考虑到消除单点故障的引患，两台 XP512 之间的 ESCON 光纤最低需要 2 根。这样当一根光纤出现意外不能使用时，利用剩下的一根可完成 MCU 和 RCU 间的通信。不至引起系统数据传输的中断。

（ 4 ） Remote control

Remote Control 可完成 CA 的构成设定，卷组的状态变更和表示。

5．5．3 高可靠性方案与高可用性方案的选择

当主运用端发生不可恢复的数据损失后，远地备份中心的镜象磁盘卷 R － VOL 里的数据与数据损失发生前的主中心磁盘卷 M － VOL 的一致性往往会决定系统损失大小以及把主应用恢复到正常状态所需时间。镜象卷组间数据完全一致时，只要将远地备份中心的数据拷回到主运用端起动修复程序便可恢复到正常业务处理。

但是由于数据传输是通过 ESCON 及 CNT 进行，并且路径较远，链路的中断等原因都有可能造成镜象卷组间数据不完全一致。在镜象卷组失去同步时，主运用端发生不可恢复的数据损失后，将会造成部分数据丢失。当然，链路故障与主运用端同时发生损坏的可能性非常低。基于用户系统是否有优先保证在任何时候镜象卷组都要一致的需要， CA XP 提供两种运行方案：高可靠性方案与高可用性方案。

· 高可靠性方案：

在此方案中，将日志文件和表数据的更新拷贝模式都设为“ DATA ”。在这种拷贝模式下，在 M － VOL 和 R － VOL 镜象卷组失去同步前， MCU 会据绝服务器对 M － VOL 发出的写操作并发出写错误信息。因此， M － VOL 和 R － VOL 镜象卷组的一致性得到保证。这种模式虽然提供了良好的一致性保证，但是对应用环境也有较高的要求。当两条 ESCON 链路全部断掉或者远地备份中心的 XP512 因停电造成运行中断等偶发性故障发生时， CA XP 镜象卷组的 M － VOL 的状态变为“ SUSPEND ”， MCU 检测出此状态后为了保证镜象卷组的一致性将禁止 M － VOL 的写操作即有可能中断主运用端应用的正常运行。因此，此方案要求系统具有忍受应用暂时停止的能力。

当由于 M － VOL 以外的地方发生故障引起主运用端应用运行的中断时，系统管理员又想继续应用的进行，可以用命令删除 CA XP 镜象卷组的逻辑关系，使 M － VOL 的状态该变为“ SIMPLEX ”，开放对 M － VOL 的写操作。此后，主运用对 M － VOL 的更新不会被反映到 R － VOL 端，即镜象卷组失去同步。镜像失去同步后建议增加对在本地 M － VOL 的在线 BACKUP 的频度。

高可靠性方案能够保证 M － VOL 和 R － VOL 严格同步。但即使主运用端不发生故障也有可能造成应用中断。此方案适用于优先磁盘卷组内容一致的系统运用，且此方案要求系统具有忍受应用暂时停止的能力。

· 高可用性方案

在此方案中，将日志文件与表数据的更新拷贝模式都设为“ NEVER ”。在这种拷贝模式下建立起来的 CA XP 镜像卷组即使在光纤或 R － VOL 故障引起 M － VOL 和 R － VOL 镜象卷组失去同步后，只要 M － VOL 没有遭到损坏， MCU 就不会据绝服务器对 M － VOL 发出的写操作。从服务器端来看， M － VOL 对 R － VOL 镜象卷的数据更新象在正常进行，服务器的应用也不会被中断。但是实际当光纤链路故障发生后，对 R － VOL 的更新会被停止， M － VOL 里被更新的磁道会被标上标记，并且 MCU 向服务器和 RETOME CONTROL 发出磁盘卷组异常信息的提示。

当出现光纤、 CNT 、远地备份中心 XP512 停电等故障时，因为不影响应用的运行，所以没有必要象“ DATA ”那样强制中断 CA XP 卷组。在此期间 M － VOL 的更新数据会被记录下来。故障修复后，可用激活命令执行 M － VOL 更新部分的拷备再同步磁盘卷组。镜像卷失去同步后建议增加对在本地 M － VOL 的在线 BACKUP 的频度。

此应用方案适用于优先保证主运用的系统和光纤线路状态不太安定的地区。但使用此方案前，必需有一个明确的认识，那就是在恢复 CA XP 卷组同步前，如果主运用端发生不可修复的灾害，将会造成数据丢失。数据丢失量与 R － VOL 变为“ SUSPEND ”的时间有关，即 M － VOL 停止向 R － VOL 更新的时间。

鉴于 XXXX 的业务为关键应用，由于一些次要因素的故障如线路故障等停止在线服务会对信誉，业务造成较大损失。因此我们建议用户使用高可用性方案。

5．5．4切换步骤

向备份中心切换

概要 :

(a) 主中心端 XP 的 MCU 因为灾难故障不能使用。

卷组状态

MCU

RCU

服务器

（主〕

服务器

（备用〕

步骤 1 ：分析 R － VOL 的一致性

- 从 RCU 看卷组状态及更新拷备模式

Delete Pair

步骤 2: 删除所有 CA 卷组

- 在 RCU 侧执行 Delete Pair 命令

- R-VOL 的状态变为「 simplex 」

MCU

RCU

服务器

（主〕

服务器

（备用〕

如果没有在备用服务器上再开新的应用 , 则到此为止。

MCU

RCU

服务器

（主〕

服务器

（备用〕

步骤 3: 使用前准备（如果在备用服务器上再开应用〕

- 执行 Vgchang -a e 命令

- 执行 Fsck 命令

- Mount R-VOL

(b) 由备份中心切换回主中心端

RCU

MCU

服务器

（主〕

服务器

（备用〕

步骤 4: 中止备用服务器上的应用，从服务器上将 M － VOL 解放 (unmount)

RCU

MCU

服务器

（主〕

服务器

（备用〕

步骤 5: 确任所有的 CA 磁盘卷组状态都变为 Duplex 。

（ CA 卷组处于同步状态〕

CA 卷组状态

服务器

（主〕

服务器

（备用〕

步骤 6: 在 RCU 上删除所有 CA 磁盘卷组。

- Delete Pair: 删除所有 CA 磁盘卷组

- Delete RCU

- 端口变更：将 RCP 改变为 LCP 。

Delete Pair

Delete RCU

变更 Port mode

MCU

RCU

服务器

（主〕

服务器

（备用〕

步骤 7: 按原来的方向建立 CA 磁盘卷组 ( 不执行初始拷贝〕， Mount M-VOL-> 恢复主运用的运行。

将 LCP 端口改为 RCP 端口

・ Add RCU

・ Add Pair

注： M ： M － ROL ， R ： R － VOL ， S ： Simplex 卷组

5．5．5 XP容灾方案性能分析

XP 阵列在用光纤构筑CA XP时，为了保证系统不会因单点故障，而出现数据传输中断的现象，要求至少配置两根光纤通道，CNT UWM间的一条光纤的传输速率为100MB/Sec，可通过转换FC波长实现最多８路光纤信号的同时传输，即可达到800MB/Sec的传输带宽．

根据XXXX核心业务系统现有的和未来一段时间发展的业务量统计，我们可以得出结论，XXXX需要实现的实时备份的每秒钟数据传输量小于以上线路的实际传输能力，所以不会引起远程数据复制传输的瓶颈现象，对于客户的系统数据有足够的传送能力。

对异步写的响应时间计算：

当然在衡量CA构成的合理性时，不能单单只注重数据的传送能力，还有一个非常重要的指标就是关于CA卷组的写操作的响应时间。虽然对于异步写操作而言，XP之间的数据复制不直接影响生产系统的正常写操作。但是在距离较远时，由于时延较大，两台XP如果在较长时间里得不到相互信息，将会影响到应用系统运行。关于CA卷组写操作过程的介绍中，我们知道完成一个写操作要有4个过程，其中影响写性能的部分有：MCU，RCU处理写操作的时间和由光纤引起的延迟2部分。

总时延=主机时延+4*CNT时延+数据块大小/带宽（FC）+2*传输时延

在XXXX的容灾环境中，由于传输距离约为10公里,经计算,传输时延约为0.05ms，CNT UWM时延为10ns(0.00001ms),因此对主机应用性能无明显的影响．

在实际情况中，为确保系统的正常运行，我们必须同广域网带宽租赁商具体确认数据传输延时（根据路由个数）。

第六章灾难备份恢复流程

灾难恢复流程是指在主数据中心发生计算机系统故障或灾难事件时，为了尽可能减少对业务造成的损失，而制定的抢救措施、故障隔离措施、恢复步骤和方法、与各有关部门和人员的联系方式等。灾难恢复流程是控制风险的一种有效方法，是灾难备份恢复的一个重要组成部分。灾难恢复流程的内容应尽量详尽，并易于操作。

任何灾难恢复流程的实施都需要有一个强有力的、训练有素的工作小组去操作，小组中的人员应熟知灾难恢复流程。平时应对小组人员进行培训和教育，以便使小组中每个人都明白在救灾和恢复过程中应担负的职责，提高灾难救护和恢复技能。另外，应定期对灾难恢复流程进行演习，使小组人员能够在灾难发生时做到从容不迫、紧张有序地开展抢救、隔离和恢复工作。

需要做好各个生产中心的相关数据和资料的收集整理工作，协调管理整个系统。各生产和备用服务器的数据库、操作系统和应用程序版本等都应该保持一致，并记录每个生产中心的系统，网络和应用环境参数。并建议编制一套应用程序，通过菜单界面来进行核心业务系统的切换。

灾难恢复系统可根据操作方式分为以下三种，其达到的效果各有所不同。

Ø 全自动恢复系统

它配合域区群集等高可靠性软件可在灾害发生时自动实现：主应用端的应用切换到远程的副应用端，并把主应用端的数据切换到远程的副应用端。并且它在主应用端修复后，把在副应用端运行的应用，返回给主应用端。在灾害发生时全自动恢复系统可达到不中断响应的切换，很好地保证了重要应用的连续性。这种方法大大地减少了系统管理员在灾害发生后的工作量，但是一些次要因素，如服务器死机、 escon 通信联络中断等故障，随时有可能引发主生产系统切换到副应用端的操作。

Ø 手动恢复系统

在这种应用中，如果主应用端全部被破坏掉，在副应用端得用手动方法把应用加载到服务器上，并且手动完成将主应用端的数据切换到远程的副应用端的操作，以继续开展业务处理。这种方法虽会产生一段时间的应用中断，但整个系统的安全性非常好，不会因为服务器或 lan 卡损坏等原因而发生误切换。

Ø 数据备份系统

在这种系统中，系统将主应用端的数据实时地备份到远地的存储器中。这样，一旦当主应用端的存储设备遭到损坏时，远地的存储器中会保留有事故前一刻为止写入本地存储器的所有数据，使丢失数据造成的损失降到最低点。当主应用端的存储器恢复正常，并将远地存储器的数据回装入本地存储器之后，应用可恢复到故障前的一刹那的状态。这个时间差异取决于服务器的缓存中丢失了多少数据。此方法与上述两种相比，恢复系统正常应用所时间最长。

用户可根据自己的现有应用状况灵活选择。

第七章培训测试及维护

经过各方面努力建立起来的灾难备份恢复系统， XXXX 必须通过内部培训和周期性的测试才能为各层次参与人员所了解、掌握。同时随着 XXXX 业务的不断完善和迅速发展，各方面的条件和情况亦会发生变化，因此还需要有稳定可靠的维护手段。

7.1 培训

Ø 成立专门的灾难备份计划小组；

Ø 选定一些对业务或技术非常熟悉的关键人员作为灾难备份小组参与人员。以保证在危机发生时处理的正确性、高效性。

Ø 制定培训计划；

Ø 让大家了解项目的背景，以及各人在灾难发生时的相应责任，应掌握的知识与技能；

Ø 计划培训进度与日程；

Ø 协调各相关部门负责人，保证培训时间；

Ø 管理培训质量。

7.2 测试灾难备份计划

测试灾难备份计划，不仅可以验证计划的有效性、完整性，亦可以帮助大家熟悉过程，做好准备工作。归纳如下：

Ø 验证计划过程与策略，发现疵暇之处

Ø 可以获得具体的恢复时间概念（如网络是如何被恢复的，速度如何）

Ø 可以测试备份主机系统与网络系统的效率

Ø 可以向领导、审计、管理、媒体等展示

Ø 可以使整个队伍熟悉其各自的角色与责任

7.2.1测试方法

测试的很重要的一个原则是不停生产机，采用独立或并行的方式进行。如果是并行则可以与生产环境比较结果。

测试的第二个原则是按模块进行，即将庞大的系统分解开来，按模块独立测试，而非一开始就动员全体综合测试。由于各模块的相对独立性，测试是可以分解成一个一个模块进行的，这样的难度较小，也易于组织与管理。

7.2.2测试的频率

测试目标是为了保持系统的现时性，即系统能跟上变化的步伐，但同时亦要考虑费用问题等。

7.2.3可能引起变化的因素

Ø 主要操作系统的升级

Ø 重要应用软件和改变

Ø 主要硬件改变

Ø 人员变动

7.2.4测试流程的制定

测试流程的制定是在测试中最为重要的一个环节，只有当测试是在可控的前提下，测试才具备检验系统安全性、锻炼应急队伍的意义。因此 XXXX 容灾系统测试流程的制订需要在最终用户、相关设备的供应商和灾备系统实施方三方共同协商确定，已确保原有系统的稳定运行。

7.3 维护

为保证灾难备份计划的稳定可靠运行，需要有明确的维护政策，技术保障人员及资金的适当投入。并通过定期的检查报告，使管理层可以了解其工作运行状态。

第八章成功案例介绍

8.1 国外成功案例

· 荷兰 PTT 电信公司

· 韩国三星证券 XP512+XP512, FC over CNT DWDM

· 比利时 Centea 银行

· 荷兰 Nationale Nederlanden 银行

· 荷兰 Dutch Tone 电信公司

· 美国 Priority Health 公司

· 新加坡电力公司 XP512+XP512,ESCON over Inrange DWDM

· 德国拜尔制药

· 意大利菲亚特汽车公司

· 英国空中客车公司

加拿大 Alkatel Carrier Networks Division

8.2 国内成功案例

· 上海 Online XP256+XP256,ESCON over CNT ATM

· 大连电信 XP512+XP256,ESCON over CNT ATM

· 江西电信 XP512+XP512,ESCON over CNT DWDM

· 云南建行 XP512+XP512,ESCON over FC

· 湖南建行 XP512+XP512,ESCON over FC

容灾备份异地容灾数据容灾容灾系统数据同步复制采集归档检索集中分发容灾方案异地容灾备份远程容灾容灾技术异地容灾方案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数据抽取复制报表分离负载均衡数据集中数据广播应用数据实时同步实时数据仓库及决策支持系统应用