容灾演练方案

xxxxxxxxxxxxxxxxxxxxxxxx项目

容

灾

演

练

方

案

第一章、总拓扑图 (4)

第二章、网络容灾演练方案 (5)

2.1 核心交换机 (5)

2.1.1 参加演练人员 (6)

2.1.2 演练流程 (6)

2.1.3 准备工作 (6)

2.1.4 演练步骤 (8)

2.1.5 预期演练结果 (9)

2.2 radware负载均衡器 (9)

2.2.1 参加演练人员 (9)

2.2.2 演练流程 (10)

2.2.3 准备工作 (10)

2.2.4 演练步骤 (13)

2.2.5 预期演练结果 (14)

第三章、应用服务器容灾演练方案 (14)

3.1 Vmware HA (14)

3.1.1 参加演练人员 (15)

3.1.2 演练流程 (15)

3.1.3 准备工作 (15)

3.1.4 模拟JJESX1故障 (16)

3.1.5 模拟JJESX2故障 (17)

3.1.6 预期演练结果 (17)

3.2 websphere (18)

3.2.1 参加演练人员 (18)

3.2.2 演练流程 (19)

3.2.3 准备工作 (20)

3.2.4 WAS故障 (24)

3.2.5 DMGR故障 (24)

3.2.6 ODR故障 (25)

3.2.7 WVE故障 (25)

3.2.8 预期演练结果 (25)

第四章、数据库系统容灾演练方案 (26)

4.1小型机故障切换 (26)

4.1.1 参加演练人员 (26)

4.1.2 演练流程 (26)

4.1.3 准备工作 (27)

4.1.4 演练步骤 (32)

4.1.5 预期演练结果 (32)

4.2生产端数据库平台整体故障切换 (33)

4.2.1 参加演练人员 (33)

4.2.2 切换流程 (34)

4.2.3 演练步骤 (35)

4.2.4 还原流程 (42)

4.2.5 演练步骤 (43)

4.2.6 预期演练结果 (46)

第一章、总拓扑图

通过部署两台IBM的企业级存储系统DS8700（一台部署在生产中心、一台部署在容灾中心），在本地生产中心的DS8700存储相应的业务数据，在生产中心通过数据复制技术将核心数据通过SAN网络复制到容灾中心容灾存储DS8700中。

本次数据容灾系统建设主要是构建同城容灾系统，生产中心与容灾中心距离<10KM,同时要求RPO=0，故两台DS8700采用同步复制技术MetroMirror方式构建数据容灾系统。

将现有数据中心两台IBM P570小型机搬迁到容灾中心，作为六合一核心数据库容灾服务器，处于Standby状态。实现当数据中心出现故障时，可以将数据库启动到容灾中心，恢复核心数据库的运行。

通过对数据中心外挂系统进行虚拟化整合后，部署服务器将闲置，为了提高现有资源的利用率，将闲置下的服务器搬迁到容灾中心，通过Vmware将闲置服务器部署为虚拟化服务器资源池，并安装相应的操作系统与中间件，外挂系统处于Standby状态，六合一应用系统与数据中心同时提高业务服务。

为了能够实现应用系统在生产中心出现相应的设备故障、电力系统等自然灾难时能够继续提供业务系统，Radware在应用系统平台架构部署上在本地生产中心部署1台Radware负载均衡设备，同时在容灾中心部署1台Radware负载均衡设备。将2台设备部署为相互热备，实现任一设备故障均可以实现自动切换，保障业务系统的联系性。

容灾数据传输网络是容灾传输的核心链路，实现数据中心心到容灾中心的通信连接，该网络的带宽要求应能满足容灾系统数据实时传输的要求。

IP数据专网可以依托公共通信网络平台，租用中国电信运营商的三条光纤专线线路，其中两条实现数据中心与容灾中心的联接，提高链路的稳定性，另外一条实现容灾中心核心交换机与市局的互联互通。

SAN数据专网同样租用两条裸光纤，将数据中心两台IBM SAN40B光纤交换机与容灾中心两台Brocade BR340光纤交换机进行冗余路径互连，提高链路的可靠性。

第二章、网络容灾演练方案

2.1 核心交换机

由于容灾端核心交换机仅仅只与生产端核心通过光纤直连，而各交警大队、中队及市局的链路均未连接，故当生产端核心交换机发生物理故障时，不能继续保证业务运作，无法进行容灾演练。

但每台交换机都配置了双引擎板，我们可以模拟单块引擎板损坏，以检验引擎板的故障切换功能。

2.1.1 参加演练人员

2.1.2 演练流程

2.1.3 准备工作

1、检查主备引擎板状态及IOS版本是否一致；

Router#sh redundancy

Redundant System Information :

------------------------------

Available system uptime = 1 year, 31 weeks, 2 days, 3 hours, 34 minutes Switchovers system experienced = 0

Standby failures = 0

Last switchover reason = none

Hardware Mode = Duplex

Configured Redundancy Mode = sso

Operating Redundancy Mode = sso

Maintenance Mode = Disabled

Communications = Up

Current Processor Information :

-------------------------------

Active Location = slot 5

Current Software state = ACTIVE

Uptime in current state = 1 year, 31 weeks, 2 days, 3 hours, 33 minutes

Image Version = Cisco Internetwork Operating System Software IOS (tm) s72033_rp Software (s72033_rp-IPSERVICES_WAN-M), Version 12.2(18)SXF16, RELEASE SOFTWARE (fc2)

Technical Support: https://www.360docs.net/doc/1d15000463.html,/techsupport

Compiled Tue 03-Mar-09 23:43 by kellythw

BOOT =

CONFIG_FILE =

BOOTLDR =

Configuration register = 0x2102

Peer Processor Information :

----------------------------

Standby Location = slot 6

Current Software state = STANDBY HOT

Uptime in current state = 1 year, 31 weeks, 2 days, 3 hours, 33 minutes

Image Version = Cisco Internetwork Operating System Software IOS (tm) s72033_rp Software (s72033_rp-IPSERVICES_WAN-M), Version 12.2(18)SXF16, RELEASE SOFTWARE (fc2)

Technical Support: https://www.360docs.net/doc/1d15000463.html,/techsupport

Compiled Tue 03-Mar-09 23:43 by kellythw

BOOT =

CONFIG_FILE =

BOOTLDR =

Configuration register = 0x2102

正确的状态应如下：

2、挑选几个特定地址ping，确认当前网络状态是正常的；

3、查看当前交换机配置并记录，以供切换后对比确认；

Router#sh run查看配置信息

Router#sh vlan查看vlan信息

Router#sh version查看版本信息

4、保存当前配置；

Router#wr保存当前配置

2.1.4 演练步骤

A、通过命令强行切换主备引擎板，在此过程中持续ping准备工作时指定的IP

地址；

Router #redundancy force-switchover强制切换主备引擎板

B、提示切换完成后，确认当前的冗余关系；

Router#sh redundancy 查看主备冗余信息

C、确认当前配置，与切换前的配置做对比；

Router#sh run查看配置信息

Router#sh vlan查看vlan信息

Router#sh version查看版本信息

D、确保ping的几个地址都是通的；

E、访问下六合一应用主页，确保网页能正常显示；

Http://10.119.147.71/trffweb

F、再次通过命令强行切换回主引擎；

Router #redundancy force-switchover强制切换主备引擎板

G、再次确保应用主页http://10.119.147.71/trffweb能访问正常，各IP地址都能

ping通。

2.1.5 预期演练结果

主备引擎板能在短时间内完成切换，所有配置信息不会发生丢失，网络连通性几乎不受影响。

预计演练时间：1小时

2.2 radware负载均衡器

两台radware为一主一备模式，其中生产端为主设备，两者配置自动同步，无法单独对备用机修改配置。

2.2.1 参加演练人员

2.2.2 演练流程

2.2.3 准备工作

Radware涉及地址如下，在模拟故障前均应保证能够ping通：

表2-1

除了六合一应用之外，还有一些外挂程序与radware farm地址有关联，汇总如下，在模拟故障前均须验证这些外挂程序能否正常访问：

表2-2

正常情况下，交警机房的radware为主设备，电信机房为备设备，在模拟故障前也应该予以确认。

查看方法：

1、通过WEB浏览器登录主radware管理页面：http://10.119.147.68

2、点击Redundancy→VRRP→Virtual routers

3、可以看到设备状态为master：

4、登录备radware管理页面：http://10.119.147.69

5、同样的方法查看设备状态为backup：

上述几点都确认没有问题后，方可开始模拟故障切换了。

2.2.4 演练步骤

A、模拟主radware设备故障，采取的方法是拔除连接核心交换机的两对尾纤，

相当于此时负载均衡器已无法访问；

B、等待备radware设备接管业务，在此过程中持续ping 表2-2中各地址，尤其

注意VRRP地址和六合一farm地址是否有异常，记录下切换时间；

C、备机切换完成后，开始测试六合一主应用及各外挂程序运行状况；

D、若出现业务访问故障或IP地址不通等问题，及时找出原因并解决，做好记录

工作，若短时间能无法解决，应立刻还原主设备；

表2-3

E、业务都通过了验证，证明容灾端工作正常，重新插好主设备的尾纤，还原网络，负载均衡功能仍旧由radware主设备处理。

radware备设备的模拟故障过程比较简单，按以下过程操作：

A、关闭Radware备设备，模拟Radware备设备宕机；

B、所有负载均衡功能仍由Radware主设备处理；

C、测试交警各业务办理，ping 虚地址10.119.147.71是否正常；

D、开启Radware备设备，还原网络。负载均衡功能仍由Radware主设备处理。

2.2.5 预期演练结果

Radware备设备能在主设备故障的情况下快速接管业务，六合一应用和外挂程序不受影响，当主设备从故障恢复后，能自动接管回业务。

预计演练时间：1小时

第三章、应用服务器容灾演练方案

3.1 Vmware HA

生产端和容灾端分别有2台IBM X3850服务器组成了vmware虚拟化平台，其配置信息如下：

生产端：

容灾端：

其中生产端外接了存储，因此配置了vmwareHA，支持ESX故障切换，而容灾端没有外接存储故没有配置HA，无法进行切换测试。

容灾演练的重点在于考察生产端vmwareHA的故障切换功能。

3.1.1 参加演练人员

3.1.2 演练流程

正常

3.1.3 准备工作

JJESX1和JJESX2上各自运行了以下虚拟机：

在进行故障模拟前，首先要确认这些虚拟机都是运行正常的。

3.1.4 模拟JJESX1故障

演练步骤：

A、关闭JJESX1，模拟一台ESX服务器宕机，ping部署在JJESX1上的几台虚拟机

的IP地址，观察网络连接情况；

B、所有部署在JJESX1上的虚拟机均自动迁移到JJESX2并启动，部分需要手动启

动的服务必须人工干预；

C、观察整个虚拟机迁移过程的ping包情况，只有在重启的时候无法ping通，

但时间非常短，不超过5分钟；

D、验证各虚拟机及其承载的业务系统运行状况，如有问题及时排错；

E、重新开启JJESX1，此时迁移到JJESX2的虚拟机并不会自动迁移回JJESX1，需

要手动vmotion，整个过程不中断业务。

3.1.5 模拟JJESX2故障

演练步骤：

A、关闭JJESX2，模拟一台ESX服务器宕机，ping部署在JJESX2上的一台虚拟机的IP地址，观察网络连接情况；

B、所有部署在JJESX2上的虚拟机均自动迁移到JJESX1并启动，部分需要手动启

动的服务必须人工干预；

C、观察整个虚拟机迁移过程的ping包情况，只有在重启的时候无法ping通，

但时间非常短，不超过5分钟；

D、验证各虚拟机及其承载的业务系统运行状况，如有问题及时排错；

E、开启JJESX2，此时迁移到JJESX1的虚拟机并不会自动迁移回JJESX2，需要手

动vmotion，整个过程不中断业务。

3.1.6 预期演练结果

单台ESX故障，虚拟机迁移正常，业务系统能在短时间内（5-10分钟）恢复正常，几乎不影响业务持续性。

预计演练时间：1小时

注意事项：

两台ESX上必须为HA故障切换留出一定物理资源，不能无限制的部署虚拟机，否则发生故障切换，单台ESX承载了远远超过其物理资源的虚拟机，有可能导致虚拟机性能低下，业务系统无法正常工作，甚至有ESX宕机的可能性。

3.2 websphere

在生产端和容灾端各有1套websphere WVE7.0集群，其具体架构如下：

生产端：

容灾端：

在radware的farm中，同时添加生产端和容灾端的IHS服务器，但平时只开放生产端服务器，禁用容灾端服务器，只有在灾难切换时启动。

3.2.1 参加演练人员

3.2.2 演练流程

3.2.3 准备工作

首先分别查看主备WVE集群的运行状况：主WVE节点同步状况：

再看ODR运行情况：

机房应急演练方案方案

1.应急响应机制 1.1.基本处理流程（1）值班人员平时应做好应急事件的监控工作，对于突发事件应认真分析、准确判定故障发生的数据域，负责跟踪该事件直至其结束。对于不在运维中心的故障，应在第一时间内通知负责人去现场处理，密切关注事件流程及进展情况，并做好登记工作上报领导。（2）正常情况下，要求值班人员在10分钟内进行事件确认。如果属于一般事件则按照事件流程进行分派处理，否则应迅速启动《应急预案》，并严格按照《应急预案》所规定的步骤快速实施应急处置，及时汇报上级领导，掌握实时处理情况。（3）在处理过程中，如需其他部门去现场增援处理，应及时向上级领导部门汇报，协调沟通，尽快联系技术工程师或厂家技术支持赶赴现场援助处理。 2.演练准备工作 2.1.视频监控系统检查视频监控是否正常工作，图像是是否清晰。检查接受到的视频图像为实时图像。

2.2.湿温监控系统检查湿度控制器、温度控制器是否正常工作，检测当湿度过高或温度过高时其是否实现实时报警。 2.3.UPS检测系统检查监控中心所收到的UPS运行状态，与实时UPS运行状况是否一致，具体参数是否正常（如输入电压、电流、蓄电池供电情况等）。 3.演练过程 3.1.机房市电供电异常 3.1.1.准备工作机房供电系统图、配电系统维修工具、应急灯、UPS操作手册、应急联系电话表。全面检查机房供电系统状况，重点确保UPS 主机系统和电池组等处于良好运行状态。与配电室联系好，保证在演练期间配电室无维修或其他操作，电力供应稳定。通知UPS供应商或维护商做好相应备件及技术支持准备，以防止UPS后备电池因维护保养不善造成其使用寿命缩短或UPS主机在进行逆变切换时发生故障。演练前对网络系统及应用系统进行一次系统备份和数据备份。

数据中心容灾备份方案完整版

数据中心容灾备份方案 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

数据保护系统医院备份、容灾及归档数据容灾解决方案 1、前言在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化 HIS、LIS 和 PACS 等系统是目前各个医院的核心业务系统，承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于15 年；住院电子病历保存时间自患者最后一次出院之日起不少于 30 年。

2、医院备份、容灾及归档解决方案针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾数据备份解决方案针对于医院的 HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的 LAN 或 LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。备份介质层（内置虚拟带库）：主流备份介质有备份存储或虚拟带库等磁盘介质、物理磁带库等，一般建议将备份存储或虚拟带库等磁盘介质作为一级备份介质，用于近期的备份数据存放，将物理磁带库或者光盘库作为二级备份介质，用于长期的备份数据存放。

系统容灾解决方案

系统容灾解决方案容灾基本概念容灾是一个范畴比较广泛的概念，广义上，我们可以把所有与业务连续性相关的内容都纳入容灾。容灾是一个系统工程，它包括支持用户业务的方方面面。而容灾对于IT而言，就是提供一个能防止用户业务系统遭受各种灾难影响及破坏的计算机系统。容灾还表现为一种未雨绸缪的主动性，而不是在灾难发生后的“亡羊补牢”。从狭义的角度，我们平常所谈论的容灾是指：除了生产站点以外，用户另外建立的冗余站点，当灾难发生，生产站点受到破坏时，冗余站点可以接管用户正常的业务，达到业务不间断的目的。为了达到更高的可用性，许多用户甚至建立多个冗余站点。容灾系统是指在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外(如火灾、地震等)停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。要实现容灾，首先要了解哪些事件可以定义为灾难？典型的灾难事件是自然灾难，如火灾、洪水、地震、飓风、龙卷风、台风等；还有其它如原提供给业务运营所需的服务中断，出现设备故障、软件错误、网络中断和电力故障等等；此外，人为的因素往往也会酿成大祸，如操作员错误、破坏、植入有害代码和病毒袭击等。现阶段，由于信息技术正处在高速发展的阶段，很多生产流程和制度仍不完善，加之缺乏经验，这方面的损失屡见不鲜。容灾的七个层次等级1：被定义为没有信息存储的需求，没有建立备援硬件平台的需求，也没有发展应急计划的需求，数据仅在本地进行备份恢复，没有数据送往异地。这种方式是成本最低的灾难恢复解决方案，但事实上这种恢复并没有真正达到灾难恢复的能力。一种典型等级1方式就是采用本地磁带库自动备份方案，通过制定相关的备份策略，可以实现系统等级1备份。等级2：是一种为许多站点采用的备份标准方式。数据在完成写操作之后，将会送到远离本地的地方，同时具备有数据恢复的程序。在灾难发生后，在一台未启动的计算机上重新完成。系统和数据将被恢复并重新与网络相连。这种灾难恢复方案相对来说成本较低，但同时有难以管理的问题，即很难知道什么样的数据在什么样的地方。这种情况下，恢复时间长短依赖于何时硬件平台能够被提供和准备好。

数据中心机房应急预案培训讲学

数据中心机房应急预案

目录一、基本原则 (3) 二、应急事件级别定义 (3) 三、组织机构及职责 (4) 3.1应急领导小组组织机构 (4) 3.2 应急领导小组职责 (4) 3.3应急小组成员职责 (5) 四、应急响应机制 (6) 4.1基本处理流程 (6) 4.2机房应急开关机具体措施 (7) 4.3服务器及存储设备故障处理 (7) 五、应急方案 (8) 5.1网络故障事件应急预案 (8) 5.2服务器故障应急预案 (8) 5.3灾害性事件应急预案 (10) 5.4其他突发事件应急预案 (10) 六、后期处置 (10) 七、应急保障 (11)

一、基本原则 (1)居安思危，预防为主。实行突发事件统一管理、统一指挥、各级负责的原则； (2)统一领导，分级负责,全面规划、及时发现、快速反应、措施果断的原则,并按照事件级别迅速上报相关领导和责任人。 (3)制度规范，加强管理。严格按照事件处理流程规范操作，使突发应急的工作规范事件化、制度化。 (4)快速反应，协同应对。当突发事件发生时，各级要立即按应急预案，投入应急工作；加强各个部门配合协作。形成统一指挥、反应灵敏、功能齐全、协调有序、运转高效的应急管理机制。 (5)主动报告原则：当突发事件发生后，要及时报告应急预案实施情况。二、应急事件级别定义根据网络与信息安全突发公共事件的可控性、严重程度和影响范围，一般分为四级：I级（特别重大）、II级（重大）、III级（较大）、IV级（一般）。国家有关法律法规有明确规定的，按国家有关规定执行。（1）I级（特别重大）：重要网络与信息安全系统发生全市性大规模瘫痪，事态发展超出相关主管部门的控制能力，对国家安全、社会秩序、经济建设和公共利益造成特别严重损害的突发公共事件。（2）II级（重大）：重要网络与信息安全系统造成全市性瘫痪，对国家安全、社会秩序、经济建设和公共利益造成严重损害，需要跨部门、跨地区协同处置的突发公共事件。（3）III级（较大）：某一区域的重要网络与信息安全系统瘫痪，对国家安全、社会秩序、经济建设和公共利益造成一定损害，但不需要跨部门、跨地区协同处置的突发公共事件。

EMC MirrorView演练方案

2 CMB 分行 MirrorView 演练方案 2008年12月5日易安信电脑系统（中国）有限公司广州分公司技术解决方案部广州市天河北路233号中信广场7401室电话：(86-20) 38771938 EMC Technical Solution Group

文档信息项目名称：招商银行分行容灾项目文档版本号： 1.5 文档作者：方天舒生成日期：2008年9月8日文档审核者：审核日期：文档维护记录版本号维护日期作者/维护人描述 1.0 2008年9月10日方天舒创建 1.1 2008年11月21日方天舒完善文档内容 1.2 2008年11月27日方天舒完善文档内容 1.3 2008年12月05日方天舒完善文档内容 1.4 2009年2月3日樊军修改文档为通用版本 1.5 2009年2月4日韩震调整格式版权说明本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属广东发展银行和美国EMC公司所有，受到有关产权及版权法保护。任何个人、机构未经广东发展银行和美国EMC公司的书面授权许可，不得复制、引用或传播本文件的任何片断，无论通过电子形式或非电子形式。

CMB分行MirrorView/S演练方案目录 1 前言 (4) 2 MirrorView灾备切换演练步骤 (5) 2.1 演练前的环境准备 (5) 2.2 计划性（planned）的灾备切换演练 (5) 2.3 非计划性（unplanned）的容灾切换演练 (6) 3 MirrorView/S灾备切换演练详细步骤示例（武汉分行） (8) 3.1 演练前的环境准备 (8) 3.1.1 主机环境准备 (8) 3.1.2 应用系统数据备份 (8) 3.1.3 VG信息保存 (9) 3.1.4 LV裸设备的用户权限设置保存 (9) 3.1.5 数据库关键表的记录总数和表占用空间记录 (9) 3.1.6 备份操作系统 (11) 3.1.7 主机系统环境要求 (11) 3.1.8 SAN Switch环境准备 (12) 3.1.9 存储环境准备 (12) 3.2 计划性（planned）的灾备切换演练 (12) 3.2.1 演练前的系统环境检查 (12) 3.2.2 在生产端主机（mbfe）上停止应用系统 (13) 3.2.3 将生产数据由生产端切换到容灾端 (14) 3.2.4 检查容灾端的数据的可用性和完整性 (14) 3.2.5 在容灾端主机（mbfe）上停止应用系统 (16) 3.2.6 将生产数据由容灾端切换到生产端 (16) 3.2.7 检查生产端的数据的可用性和完整性，恢复生产环境 (17) 3.3 非计划性（unplanned）的容灾切换演练 (20) 3.3.1 演练前的系统环境检查 (20) 3.3.2 灾难发生模拟 (21) 3.3.3 在生产端主机（mbfe）上恢复演练环境 (21) 3.3.4 将生产数据由生产端切换到容灾端 (21) 3.3.5 检查容灾端的数据的可用性和完整性 (22) 3.3.6 删除容灾端存储系统（SECONDARY ARRAY）上的MirrorView/S配置 (24) 3.3.7 删除生产端存储系统（PRIMARY ARRAY）上的MirrorView/S配置 (24) 3.3.8 灾难解除模拟 (25) 3.3.9 在容灾端存储系统（SECONDARY ARRAY）重新创建MirrorView/S配置 (25) 3.3.10 在容灾端主机（mbfe）上停止应用系统 (26) 3.3.11 将生产数据由容灾端切换到生产端 (27) 3.3.12 检查生产端的数据的可用性和完整性，恢复生产环境 (27) 3.4 异常处理步骤 (29) 3.4.1 数据库数据恢复 (29) 3.4.2 手工启动应用系统 (30) 第3页

数据中心容灾备份方案

数据保护系统医院备份、容灾及归档数据容灾解决方案

1、前言在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化HIS、LIS 和PACS 等系统是目前各个医院的核心业务系统，承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于15 年；住院电子病历保存时间自患者最后一次出院之日起不少于30 年。

2、医院备份、容灾及归档解决方案针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 2.1 数据备份解决方案针对于医院的HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的LAN 或LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。

DSG SuperSync平台容灾演练方案

目录第一章文档介绍 (3) 1.1摘要 (3) 1.2客户的受益 (3) 1.3责任人............................................................................................................................ 错误！未定义书签。第二章灾备前搭建测试环境进行演练 (4) 第三章灾备演练计划和安排 (6) 2

第一章文档介绍 1.1 摘要此文档主要阐述了本次软件灾备演练的目的、计划、步骤、分工，以及评测方法，便于医院信息管理部各位领导了解整个演练进程，并做相应检验。本次在医院处进行的灾备演练评测，是希望通过在实际生产环境中的部署与试用，使医院信息管理部各位领导和专家能够全面了解并评估DSG公司的SuperSync数据库复制软件及其应用技术，为医院未来的企业业务容灾系统建设提供有益的探索。我们精心设计了整个演练过程，力求以医院业务应用的视角来评测该软件。 1.2 客户的受益通过此文档，客户方信息管理部相关人员将能够更加清晰地了解测试的全部细节，从而便于安排相关检测。 3

第二章灾备前搭建测试环境进行演练本次评测在医院搭建的测试拓扑图如下具体模拟灾备测试环境的相关参数列表如下（实际灾备演练过程和此次测试过程一致）： 4

目标端软件测试情况：测试用DSG用户在源端和目标端分别做了insert,update,delete测试，数据均完全一致，两边可以随意切换。下面就是联系应用和用户确定方案和时间，做正式灾备演练测试。 5

OracleDataGuard容灾方案

Oracle数据库异地容灾方案介绍 2008年11月

目录第一章需求分析 (4) 1.1 序言 (4) 1.2 用户现状 (4) 1.2.1 系统平台 (4) 1.2.2 数据库平台 (6) 1.3 用户需求 (7) 1.3.1 日常功能 (7) 1.3.2 故障切换 (7) 1.3.3 基本要求 (7) 1.3.4 性能要求 (8) 1.3.5 数据一致性 (9) 1.3.6 系统兼容性 (9) 1.3.7 高可用性 (10) 1.3.8 健壮性要求 (10) 1.3.9 设备无关性 (10) 1.3.10 管理监控功能 (11) 第二章Oracle Data Guard介绍 (12) 2.1 Data Guard实现原理 (12) 2.2 Oracle Data Guard 优势 (15) 2.3 Data Guard提供的保护模式 (16) 2.4 Data Guard实现方式以及对系统的限制要求 (17) 2.5 切换方式 (17) 第三章系统建议方案 (19) 3.1 Data Guard优势 (19) 3.2 Data Guard运行模式 (19) 3.3 Data Guard保护模式 (20)

3.4 Data Guard初始安装步骤 (20) 3.5 用户需求点对点应答 (21) 3.5.1 日常功能 (21) 3.5.2 故障切换 (22) 3.5.3 基本要求 (23) 3.5.4 性能要求 (23) 3.5.5 数据一致性 (25) 3.5.6 系统兼容性 (26) 3.5.7 高可用性 (26) 3.5.8 健壮性要求 (27) 3.5.9 设备无关性 (27) 3.5.10 管理监控功能 (28)

容灾演练方案

xxxxxxxxxxxxxxxxxxxxxxxx项目容灾演练方案

目录第一章、总拓扑图 (4) 第二章、网络容灾演练方案 (5) 2.1 核心交换机 (5) 2.1.1 参加演练人员 (6) 2.1.2 演练流程 (6) 2.1.3 准备工作 (6) 2.1.4 演练步骤 (8) 2.1.5 预期演练结果 (9) 2.2 radware负载均衡器 (9) 2.2.1 参加演练人员 (9) 2.2.2 演练流程 (10) 2.2.3 准备工作 (10) 2.2.4 演练步骤 (13) 2.2.5 预期演练结果 (14) 第三章、应用服务器容灾演练方案 (14) 3.1 Vmware HA (14) 3.1.1 参加演练人员 (15) 3.1.2 演练流程 (15) 3.1.3 准备工作 (15) 3.1.4 模拟JJESX1故障 (16) 3.1.5 模拟JJESX2故障 (17) 3.1.6 预期演练结果 (17) 3.2 websphere (18) 3.2.1 参加演练人员 (18) 3.2.2 演练流程 (19) 3.2.3 准备工作 (20) 3.2.4 WAS故障 (24) 3.2.5 DMGR故障 (24)

3.2.6 ODR故障 (25) 3.2.7 WVE故障 (25) 3.2.8 预期演练结果 (25) 第四章、数据库系统容灾演练方案 (26) 4.1小型机故障切换 (26) 4.1.1 参加演练人员 (26) 4.1.2 演练流程 (26) 4.1.3 准备工作 (27) 4.1.4 演练步骤 (32) 4.1.5 预期演练结果 (32) 4.2生产端数据库平台整体故障切换 (33) 4.2.1 参加演练人员 (33) 4.2.2 切换流程 (34) 4.2.3 演练步骤 (35) 4.2.4 还原流程 (42) 4.2.5 演练步骤 (43) 4.2.6 预期演练结果 (46)

机房应急演练方案

1.应急响应机制 1.1.基本处理流程（1）值班人员平时应做好应急事件的监控工作，对于突发事件应认真分析、准确判定故障发生的数据域，负责跟踪该事件直至其结束。对于不在运维中心的故障，应在第一时间内通知负责人去现场处理，密切关注事件流程及进展情况，并做好登记工作上报领导。

（2）正常情况下，要求值班人员在10分钟内进行事件确认。如果属于一般事件则按照事件流程进行分派处理，否则应迅速启动《应急预案》，并严格按照《应急预案》所规定的步骤快速实施应急处理，及时汇报上级领导，掌握实时处理情况。（3）在处理过程中，如需其它部门去现场增援处理，应及时向上级领导部门汇报，协调沟通，尽快联系技术工程师或厂家技术支持赶赴现场援助处理。 2.演练准备工作 2.1.视频监控系统检查视频监控是否正常工作，图像是是否清晰。检查接受到的视频图像为实时图像。 2.2.湿温监控系统检查湿度控制器、温度控制器是否正常工作，检测当湿度过高或温度过高时其是否实现实时报警。 2.3.UPS检测系统检查监控中心所收到的UPS运行状态，与实时UPS运行状况是否一致，具体参数是否正常（如输入电压、电流、蓄电池供电情况等）。

3.演练过程 3.1.机房市电供电异常 3.1.1.准备工作机房供电系统图、配电系统维修工具、应急灯、UPS操作手册、应急联系电话表。全面检查机房供电系统状况，重点确保UPS 主机系统和电池组等处于良好运行状态。与配电室联系好，保证在演练期间配电室无维修或其它操作，电力供应稳定。通知UPS供应商或维护商做好相应备件及技术支持准备，以防止UPS后备电池因维护保养不善造成其使用寿命缩短或UPS主机在进行逆变切换时发生故障。演练前对网络系统及应用系统进行一次系统备份和数据备份。 3.1.2.应急演练应掌握的数据由于当前UPS系统在机房的负荷较大，当前UPS有效后备时间约2—2.5小时。经与相关小组了解业务系统数据应急和设备正常关闭时间约

六种数据库容灾方案

六种数据库容灾方案 1、经典方案，即双机ha，单盘阵的环境。简单的说，双机热备就是用两台机器，一台处于工作状态，一台处于备用状态，但备用状态下，也是开机状态，只是开机后没有进行其他的操作。打个比方来说，在网关处架上两台频宽管理设备，将两台的配置设定为一致，只是以一台的状态为主，一台为次。主状态下的频宽管理设备工作，处理事件，次状态下的频宽管理设备处于休眠，一旦主机出现故障，备用频宽管理设备将自动转为工作状态，代替原来的主机。这就是“双机热备”。 2、单机双盘阵（os层镜像）。针对某些用户的双盘阵冗余的需求，我提出了在os层安装卷管理软件，用软件对两台盘阵做镜像的方案，但只有单机工作，一台盘阵挂了，因为os层的软raid的作用，系统仍然可以工作。 3、双机双柜（os层镜像）方案，这个方案，仍然是用os层做镜像，但是用了双机ha，这种方式有个尚未确认的风险，非纯软方式的ha要求主机有共享的存储系统。一台机器对盘阵lun做的镜像虚拟卷，是否也适用另一台主机，也就是说，a主机做的镜像，b主机接管后，是否会透明的认出a机做镜像之后的逻辑虚拟卷，如果ab两主机互相都能认，那么就是成功的方案！！ 4、双机双柜（底层镜像）。这种方案，虽然共享的lun不是在一台物理盘阵上，但是被底层存储远程镜像到另一台盘阵上，能保持数据的一致性

5、双机双柜纯软方式HA。这种方案，主机装纯软HA软件，虽然纯软不需要外接盘阵，但是接了盘阵，照样可行。 6、双机双柜（hacmp geo），其实geo大体上就是个类似于纯软HA的软件。

数据库安全（一）数据库安全的定义数据库安全包含两层含义：第一层是指系统运行安全,系统运行安全通常受到的威胁如下，一些网络不法分子通过网络，局域网等途径通过入侵电脑使系统无法正常启动，或超负荷让机子运行大量算法，并关闭cpu风扇，使cpu过热烧坏等破坏性活动；第二层是指系统信息安全，系统安全通常受到的威胁如下，黑客对数据库入侵，并盗取想要的资料。编辑本段（二）数据库安全的特征数据库系统的安全特性主要是针对数据而言的，包括数据独立性、数据安全性、数据完整性、并发控制、故障恢复等几个方面。下面分别对其进行介绍 1．数据独立性数据独立性包括物理独立性和逻辑独立性两个方面。物理独立性是指用户的应用程序与存储在磁盘上的数据库中的数据是相互独立的；逻辑独立性是指用户的应用程序与数据库的逻辑结构是相互独立的。 2．数据安全性操作系统中的对象一般情况下是文件，而数据库支持的应用要求更为精细。通常比较完整的数据库对数据安全性采取以下措施：（1）将数据库中需要保护的部分与其他部分相隔。（2）采用授权规则，如账户、口令和权限控制等访问控制方法。（3）对数据进行加密后存储于数据库。 3．数据完整性数据完整性包括数据的正确性、有效性和一致性。正确性是指数据的输入值与数据表对应域的类型一样；有效性是指数据库中的理论数值满足现实应用中对该数值段的约束；一致性是指不同用户使用的同一数据应该是一样的。保证数据的完整性，需要防止合法用户使用数据库时向数据库中加入不合语义的数据 4．并发控制如果数据库应用要实现多用户共享数据，就可能在同一时刻多个用户要存取数据，这种事件叫做并发事件。当一个用户取出数据进行修改，在修改存入数据库之前如有其它用户再取此数据，那么读出的数据就是不正确的。这时就需要对这种并发操作施行控制，排除和避免这种错误的发生，保证数据的正确性。 5．故障恢复由数据库管理系统提供一套方法，可及时发现故障和修复故障，从而防止数据被破坏。数据库系统能尽快恢复数据库系统运行时出现的故障，可能是物理上或是逻辑上的错误。比如对系统的误操作造成的数据错误等。 SQL server数据库安全策略 SQL Server2000[1]的安全配置在进行SQL Server2000数据库的安全配置之前，首先必须对操作系统进行安全配置，保证操作系统处于安全状态。然后对要使用的操作数据库软件（程序）进行必要的安全审核，比如对ASP、PHP等脚本，这是很多基于数据库的Web应用常出现的安全隐患，对于脚本主要是一个过滤问题，需要过滤一些类似“,;@/”等字符，防止破坏者构造恶意的SQL语句。接着，安装SQL Server2000后请打上最新SQL补丁SP3。 SQL Server的安全配置 1．使用安全的密码策略我们把密码策略摆在所有安全配置的第一步，请注意，很多数据库账号的密码过于简单，这跟系统密码过于简单是一个道理。对于sa更应该注意，同时不要让sa账号的密码写于应用程序或者脚本中。健壮的密码是安全的第一步，建议密码含有多种数字字母组合并9位以上。SQL Server2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非您确认必须使用空密码，这比以前的版本有所改进。同时养成定期修改密码的好习惯，数据库管理员应该定期查看是否有不符合密码要求的账号。 2．使用安全的账号策略由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以，我们必须对这个账号进行最强的保

某公司系统容灾解决建设方案

某公司软件容灾方案 1容灾软件 Symantec 的存储管理软件VERITAS Storage Foundation（简称SF）适用于企业存储管理的标准化平台，它不仅提供比操作系统本身逻辑卷管理器更加强大的在线卷管理功能，还提供许多高级的存储管理功能，其中包括用于容灾的数据镜像、数据复制等功能。是目前市场上广泛使用的容灾软件。 Symantec VERITAS Cluster Server(简称VCS)是一个用于容灾演练、应用级容灾的软件。它是在基本的HA软件功能的基础上发展而来的。 Veritas Storage Foundation 软件可以根据企业不同需求，提供不同的容灾解决方案，小到同城数据镜像，大到两地三中心数据容灾。SF与VCS紧密集成，可以提供完整的、从数据到应用、并自动实时演练的企业容灾方案。铁道部高铁指挥实验系统采用了SF/VCS实现了容灾。

2数据同城镜像方式利用灾备中信和主中心之间或者同机房内的裸光纤线路构成SAN环境，直接采用Storage Foundation在两个存储之间实现存储镜像。即所有数据都将同时写入两边的磁盘整列中。如上图所示，主中心的服务器将应用的每个写i/o数据同时写入到两个中心的存储中。由于镜像的实现是依托于底层的Volume，所有数据存取的过程对于应用来说都是透明的。我们可以通过设臵Volume Manager的读取策略来指定主中心的服务器从本地的磁盘阵列上读取数据，加快数据查询的速度。在这个场景中，数据发生物理错误的可能性基本上分为两种，生产中心的存储系统出现物理错误，如硬盘问题、光纤卡问题、光纤连接问题或光纤交换机问题等，另外一种就是整个数据中心出现故障。

机房应急演练方案

精品文档 1.应急响应机制 1.1.基本处理流程一般事已解按事件流程处记故障恢复（1）值班人员平时应做好应急事件的监控工作，对于突发事件应认真分析、准确判定故障发生的数据域，负责跟踪该事件直至其结束。对于不在运维中心的故障，应在第一时间内通知负责人去现场处理，

密切关注事件流程及进展情况，并做好登记工作上报领导。（2）正常情况下，要求值班人员在10分钟内进行事件确认。如果属于一般事件则按照事件流程进行分派处理，否则应迅速启动《应. 精品文档急预案》，并严格按照《应急预案》所规定的步骤快速实施应急处置，及时汇报上级领导，掌握实时处理情况。（3）在处理过程中，如需其他部门去现场增援处理，应及时向上级领导部门汇报，协调沟通，尽快联系技术工程师或厂家技术支持赶赴现场援助处理。 2.演练准备工作 2.1.视频监控系统检查视频监控是否正常工作，图像是是否清晰。检查接受到的视频图像为实时图像。 2.2.湿温监控系统检查湿度控制器、温度控制器是否正常工作，检测当湿度过高或温度过高时其是否实现实时报警。 2.3.UPS检测系统检查监控中心所收到的UPS运行状态，与实时UPS运行状况是否一致，具体参数是否正常（如输入电压、电流、蓄电池供电情况等）。 . 精品文档

3.演练过程 3.1.机房市电供电异常 3.1.1.准备工作机房供电系统图、配电系统维修工具、应急灯、UPS操作手册、应急联系电话表。全面检查机房供电系统状况，重点确保UPS 主机系统和电池组等处于良好运行状态。与配电室联系好，保证在演练期间配电室无维修或其他操作，电力供应稳定。通知UPS供应商或维护商做好相应备件及技术支持准备，以防止UPS 后备电池因维护保养不善造成其使用寿命缩短或UPS主机在进行逆变切换时发生故障。演练前对网络系统及应用系统进行一次系统备份和数据备份。 3.1.2.应急演练应掌握的数据由于目前UPS系统在机房的负荷较大，目前UPS有效后备时间约2—2.5小时。经与相关小组了解业务系统数据应急和设备正常关闭时间约1.5小时。机房计算机设备允许最高环境温度为33°C。 . 精品文档 3.1.3.市电异常应急演练处置流程图突发市电停电检查UPS运行状每十分钟UP每十分钟记录一行一次记录，机房温度、湿机房系统进行次正常

医院容灾演练方案

河池XX县人民医院存储容灾演练方案 2011年11月

目录第1章实施步骤、效果说明和测试方案 (2) 1.1整个EMC Recoverpoint实施步骤和时间预估 (2) 1.2效果说明 (2) 1.3测试目的 (2) 1.4测试环境说明 (3) 1.5服务器系统 (4) 3.5.1常见系统故障 (4) 3.5.2常见系统维护 (4) 1.6测试项目设置 (5) 1.7具体测试内容 (6) 3.7.1数据一致性测试 (8) 3.7.2数据容灾故障恢复测试 (9) 3.7.3容灾:任意时间点回滚测试 (10) 3.7.4容灾: 容灾存储恢复至主存储数据测试 (11) 3.7.5容灾:主存储误操作数据恢复测试 (11)

第1章实施步骤、效果说明和测试方案 1.1 整个EMC Recoverpoint实施步骤和时间预估 1.2 效果说明 1,实现存储间的数据互联互通、相互流动的功能。 2,实现主备存储间数据实时同步，主备存储的数据一致、高可用的功能。 3,实现当主存储发生逻辑错误后，可以通过备用存储对主存储的数据追回、不丢失数据的功能。 4,实现存储上的数据任意时间点回滚功能，有效地避免主数据库的逻辑错误或突然断电导致数据库无法正常运行的故障。并将数据丢失率降低至最小。 5,实现备用存储的在线使用功能，当备用存储的数据修改后，能够直接恢复到主存储。该功能可以在备用存储上打开数据库，实现报表、测试、升级、培训等操作，分流用户的业务，降低生产系统的负载。 6,完成备用存储的报表、测试、升级、培训功能后，可以通过主存储将其变化的数据继续同步到备用存储，恢复存储间的数据实时同步，保持数据一致、高可用状态。 1.3 测试目的为了检验是否可以达到客户的要求，在首次完成recoverpoint后，需要按

机房应急演练方案方案

数据容灾备份设计方案

数据容灾备份设计方案 1.1数据备份的主要方式目前比较实用的的数据备份方式可分为本地备份异地保存、远程磁带库与光盘库、远程关键数据+定期备份、远程数据库复制、网络数据镜像、远程镜像磁盘等六种。（1）本地备份异地保存是指按一定的时间间隔（如一天）将系统某一时刻的数据备份到磁带、磁盘、光盘等介质上，然后及时地传递到远离运行中心的、安全的地方保存起来。（2）远程磁带库、光盘库是指通过网络将数据传送到远离生产中心的磁带库或光盘库系统。本方式要求在生产系统与磁带库或光盘库系统之间建立通信线路。 — （3）远程关键数据+定期备份本方式定期备份全部数据，同时生产系统实时向备份系统传送数据库日志或应用系统交易流水等关键数据。（4）远程数据库复制生产系统相分离的备份系统上建立生产系统上重要数据库的一个镜像拷贝，通过通信线路将生产系统的数据库日志传送到备份系统，使备份系统的数据库与生产系统的数据库数据变化保持同步。（5）网络数据镜像是指对生产系统的数据库数据和重要的数据与目标文件进行监控与跟踪，并将对这些数据及目标文件的操作日志通过网络实时传送到备份系统，备份系统则根据操作日志对磁盘中数据进行更新，以保证生产系统与备份系统数据同步。（6）远程镜像磁盘利用高速光纤通信线路和特殊的磁盘控制技术将镜像磁盘安放到远 …

离生产系统的地方，镜像磁盘的数据与主磁盘数据以实时同步或实时异步方式保持一致。磁盘镜像可备份所有类型的数据。备份拓扑网络结构1.2（即东风东路院区中心机广州市第八人民医院具有两个不同地点的中心机房房和嘉禾院区中心机房），在这基础上是可以构建一个异地容灾的数据备份系统，以确保本单位的系统正常运营及对关键业务数据进行有效地保护，以下设计方案仅提供参考。嘉禾院区数据中心东风东院区数据中心本方案中，我们采用EMC的CDP保护技术来实现数据的连续保护和容灾系统。 1.在东风东院区数据中心部署一台EMC 480统一存储平台，配置一个大容量光纤磁盘存储设备，作为整个系统数据集中存储平台。 2.在嘉禾院区数据中心部署一台EMC 480统一存储系统，配置一个大容量光纤磁盘存储设备，作为整个平台的灾备存储平台。） 3.两地各部署两台EMC RecoverPoint/SE RPA，采用CLR技术，即CDP（持续数据保护）+CRR（持续远程复制），实现并发的本地和远程数据保护。 4.在东风东院区数据中心本地采用EMC RecoverPoint/SE CDP（持续数据保护）技术实现本地的数据保护。． 5.两地采用EMC RecoverPoint/SE CRR（持续远程复制）技术，实现远程的数据保护。由于两地之间专线的带宽有限，可以采用EMC Recoverpoint/SE异步复制技术，将东风东院区数据中心EMC480上的数据定时复制到嘉禾院区数据中心。根据带宽的大小，如果后期专线带宽有所增加，RecoverPoint会自动切换同步、异步、快照时间点三种复制方式，尽最大可能保证数据的零丢失。 1.3本地数据数据保护（CDP）设计

XXXX公司Oracle数据库异地容灾方案

XXXX公司Oracle数据库异地容灾方案 2011年08月29日

1、公司简介 XXXX公司。 2、项目背景 ●XXXX有两个数据中心。 ●两个基地之间使用TCP/IP网络进行连接。 ●生产业务系统的后台数据库为Oracle。 ●数据库服务器操作系统为Windows。 ●数据库目前总体数据量约为2.4T。 ●生产系统为双机容错架构。 ●希望远程数据中心成为容灾中心。 3、解决方案 3.1方案原理这是一个很典型的应用场景，用户对RPO、RTO的要求比较高，用户希望数据丢失尽可能少，恢复尽可能快。可是，要实现这一愿望，传统的容灾方案都是采用昂贵的存储设备或卷管理软件来实现，投入相当惊人，用户很难接受！CommVault的CDR连续数据复制是一个性价比很高的解决方案，工作原理如下图所示：

这个Oracle远程容灾方案的设计思想是：在容灾系统初始化时或备份系统被破坏时，利用备份和恢复来传送数据库的DBF文件；在数据库日常工作时，利用CDR来时复制数据库日志文件，并将日志回滚到备份数据中（对于双机架构来说，原理相同，所需模块相同，如图生产主机可为双机或集群架构）。系统的数据流如下图所示：

3.2实施过程在这个方案中，我们采用了CommVault的备份技术和CDR技术，数据共有4份冗余，除了生产数据外，还有容灾数据，本地备份和异地备份数据；这里需要注意的是，在两个数据中心的数据库都是使用本地数据为业务系统提供服务，并且将数据在两个数据中心之间相互复制，以便达到两个数据中心互为容灾中心的目的。整个容灾系统的建立共分4个阶段： ●初始化阶段：通过备份＋恢复方式，在容灾站点生成初始化数据 ●容灾复制阶段： 1.通过CDR复制交易日志 2.自动回滚日志实现数据库容灾 3.每天做异地数据库的冷备份 4.每天做本地数据库的热备份 ●灾难重建阶段：如果数据崩溃，由于本地和异地都有灾备数据，通过本地的直接恢复实现本地网络的灾难数据重建，避免在远程网络上传送大量的初始化数据 ●容灾演练阶段：将容灾站点的数据库打开，就可以使用了。恢复正常工作方式，只要将灾备的数据恢复，然后回滚以前的日志数据，就能恢复容灾复制阶段。 4、技术要点在这4个阶段中，充分利用了CommVault的独特技术： ●CDR复制：连续数据复制，复制数据库交易日志。 ●断点续传：支持从中断点继续传送。 ●GridStor：支持多个介质服务器使用不同地区的数据源，这样就不需要通过网络来回传送大量的数据。 ●自动恢复和回滚：支持以时间或者自动的方式，恢复和回滚日志或其它数据，而不需要手工执行。 ●辅助拷贝：支持将本地的备份数据复制到异地，实现异地的灾备。

XXX市商业银行灾备切换演练总体方案

XX市商业银行灾难备份系统切换演练总体方案 XX市商业银行 2016年1月

目录一、本次演练目的和原则 (1) 1. 演练目的 (1) 2. 演练要求 (1) 二、演练时间及参演部门 (3) 三、演练组织架构及名单 (4) 四、演练方案 (7) 1. 演练内容 (7) 2. 演练总体安排 (7) 3. 本次演练涉及的主要服务器 (8) 4. 演练步骤 (8) 五、演练风险控制 (10) 六、演练后的总结及修订情况 (11)

一、本次演练目的和原则 1.演练目的为保障XX市商业银行信息系统安全、可靠、稳定运行，提高应对各类信息系统突发事件对能力，有效防范重要信息系统风险，根据中国银监会关于《银行业重要信息系统突发事件应急管理规范》对通知，结合我行自身情况，特制定本次灾备切换演练计划。本次灾备切换演练主要目的： ●论证我行重要信息系统突发事件应急预案对可行性； ●验证核心系统切换到灾备中心后，灾备核心系统接管生产的可用性； ●验证灾备中心DELL SharePlex数据库同步的可用性； ●检验系统切换手册和文档的可用性，并在演练过程中发现信息系统应急管理体系存在的问题和不足，以便演练后进行改进和完善； ●验证网点接入灾备中心网络能力； ●使参演人员熟悉应急管理和灾难恢复/切换的流程； ●提高参演人员的应急处理能力和系统的风险防控能力。 2.演练要求 1.切换演练实施前按照监管单位要求，向上级报备； 2.切换演练中要做好回退方案，防范切换演练过程中对风险；

3.演练后不影响生产系统数据和对外服务； 4.演练后不影响全行生产环境其它各系统的正常运行； 5.演练后不影响灾备中心数据复制的正常运行； 6.演练后不影响灾备中心接管生产系统能力； 7.演练后向上级单位汇报演练情况。