1 医院数据中心异地灾备系统建设
医院数据中心
异地灾备系统建设
项目建议书
迪思杰（北京）数码技术有限公司
2010-8-24
目录
1 项目背景
随着医院信息化进程的不断深化，信息系统成为了支撑医院业务运行的重要平台，医院的全部业务流程都依赖于信息系统提供的服务来运作。为了保证该系统的稳定、安全、有效的运行，医院的IT部门都采用了双机、RAID、磁带备份等技术，来回避由于磁盘故障，人为失误，应用程序的逻辑错误，自然灾害等原因带来的系统停机或者数据丢失。但大部分医院并没有建立一个容灾机制，一旦数据库或硬件出现故障，较长时间不能恢复，对医院来说都是一次灾难，将会给给医院的声誉带来了恶劣的影响并造成了极大的经济损失：
ü广东省人民医院电脑故障让患者受累
ü北京妇产医院挂号故障千人排队苦等
ü上海市第十人民医院停机4个多小时
ü通山县人民医院电脑故障无法交费老汉等2小时猝死检测室
ü闵行区医院电脑故障千余人等数小时挂号
ü华山医院网络故障2小时取不了药
ü中山市中医院系统出现故障，医院收费环节完全瘫痪，导致数千人看病受到影响
ü第八人民医院医院电脑临时出故障沟通不畅引患者投诉ü北京安贞医院电脑系统出现故障，造成大厅聚集近百名患者
ü上海一医院突发电脑故障造成大量病人滞留
ü齐鲁医院电脑突发故障患者排长队苦等
ü上海龙华医院电脑系统故障致排队人群至门口
ü东方医院电脑系统突发故障数百患者苦等三小时
因此迫切需要建设容灾系统，以保证计算机业务系统的连续运行，并提高信息系统抵御突发性灾难的能力，保证医院稳定运行。
本方案是迪思杰(北京)数码技术有限公司根据****医院提出的以上需求，所提出的利用DSG Realsync数据同步复制软件实现数据的实时复制，从而满足“建设容灾系统，实现数据的远程备份和业务的不中断运行“的需求。
DSG Realsync数据同步复制目前在国内有200多家客户，占到第三方数据复制软件市场70%以上的市场份额。
本方案如有欠缺或遗漏之处，敬请谅解！
2 容灾技术分析
2.1 容灾技术的选择
在选择容灾系统的构造时，首先要考虑的就是选择采用合理的异地数据复制技术。数据的远程复制技术是容灾系统的核心技术，它对于数据系统的一致性和可靠性以及系统的应变能力具有举足轻重的作用，通过有效的数据复制，远程的业务数据中心与本地的业务数据实现同步，确保一旦本地系统故障，远程的容灾中心迅速进行完整的接管。
实现这些功能的业界常用解决方案主要包括以下几类：
1. 磁盘阵列复制技术：
主要由一些磁盘阵列厂商提供，如EMC SRDF、IBM PPRC 、HP BusinessCopy、HDS TrueCopy等, 该技术是将数据复制通过磁盘阵列控制器在进行写入操作的同时通过高速网络向容灾系统的阵列上发送相同的I/O指令来实现；
2. 存储卷复制技术：
由一些卷管理软件厂商提供，如VERITAS VVR；
3. 存储虚拟化技术：
飞康的CDP等，该技术是将系统中各种异构的存储设备映射为一个单一的存储资源，对用户完全透明，达到屏蔽存储设备的异构和主机的异构的目的。
4. 数据库复制技术：
由数据库厂商以及一些第三方厂商提供，如DSG RealSync/SmartE等；
磁盘阵列复制技术、存储卷复制技术、存储虚拟化技术与数据库复制技术在容灾应用的层面相比较起来，有几个明显的缺点：
不足一：切换的复杂性
在灾难发生的时候，如果采用的是盘阵/卷/虚拟类的容灾方案，那在业务切换（接管）时需要经过：
1、主机启动、
2、存储启动、
3、Oracle数据库启动、
4、中间件启动
5、网络切换、
6、应用切换，
7、相关参数修改
等等多个环节才能成功完成整个过程，而在突发事件产生的时候，现场是否有能
有这么多技术人员保障，能够解决各个环节的启动、切换等，这个一个非常现实的问题。
由于Realsync软件实施的容灾数据库是OPEN状态的，所以没有主机、存储、数据库重启等繁琐步骤，只需要将容灾端ORACLE数据库的trigger激活，并将应用服务器器连接到接管的数据库服务器上。
Realsync是所有方案中切换最简单、最方便的，相信这个操作大部分的IT部门人员都可以完成。
不足二：30分钟切换（接管）的压力较大
由于采用磁盘阵列/存储卷/虚拟容灾方案，在业务切换（接管）时需要经过主机启动、存储启动、Oracle数据库启动、网络切换、应用切换等多个环节；其中仅UNIX操作系统启动（含服务器外围设备和网络等元素的启动）和Oracle启动两个步骤就要花费几十分钟（至少为15+10=25分钟）。
在很多关键行业，如果要实现30分钟内接管业务，这是有一定压力的。
因此，在证券等实时性较高的行业，数据库复制技术被大规模采用。（DSG目前在金融证券基金期货行业，拥有50多个灾备客户）
不足三：备份数据库是否一定能够接管还存在疑问
由于磁盘阵列/存储卷/虚拟容灾方案是采用基于IO级别的同步，而这个同步和Oracle的写操作是不完全一致的，所以备份数据库存在几个疑问：
n 疑问一：灾难产生时，备份系统的Oracle是否一定能够起得来？
n 疑问二：即使Oracle能够起得来，数据是否一定都能够读取？n 疑问三：灾难切换后系统的性能是否处于正常状态？
不足四：无法避免物理错误（如磁盘坏块），导致数据不一致、不安全
由于磁盘阵列/存储卷/虚拟容灾方案是采用基于IO级别的同步，无法解决磁盘经常出现的物理错误，例如：数据库坏块，这是Oracle数据库经常出现的典型问题（我们可以提供许多实例）。因此，基于磁盘阵列/存储卷/虚拟容灾的方案将面临数据丢失的风险。
而数据库复制技术则不会有这样的问题。
2.2 推荐采用“RealSync产品”
要建立查询数据库的关键技术，就是数据库的实时复制。
目前****医院是采用的Oracle数据库，而实现Oracle数据库数据实时复制的产品只有两类方案，一是Oracle自带的工具，二是第三方的数据库复制工具。而Oracle自带的工具在资源占用、效率和功能等方面，还满足不了****医院现有系统的需求，因此在本方案里，DSG推荐采用Realsyc产品，该产品目前在业内应用范围广泛，主要实现如下功能：
(一) 核心业务的灾备平台
通过数据同步建立灾备中心可以实现对业务关键数据的容灾及保护，在不影响生产数据库性能的同时为生产数据库在本地或异地建立一份准实时镜像，以保证在生产数据库发生灾难时可使用容灾数据库进行业务接管和数据恢复。
(二) 业务负载分担
由于复制的第二数据中心的数据处于实时可读取状态，数据库处于OPEN状态，
从而实现系统业务模块的重新部署。
通过第二数据中心实现对核心系统的业务模块进行负载分担，将那些只对数据进行读取操作的模块都迁移到第二数据中心上来，主要包括：
ü提供帐务和话单实时查询；
ü提供统计报表运行；
ü提供经营分析数据抽取；提供其他系统的数据访问接口；
这样作将达到两个好处：
ü提高数据访问的效率，提高外围系统部署的灵活性；
ü提高核心系统的运行效率，提高核心系统运行的稳定和可靠性；
2.3 为什么推荐RealSync产品
我们建议采用DSG RealSync软件的原因在于：
1. 提供可靠的应急切换，避免物理错误的复制
实现对业务关键数据的容灾及保护，打开的Oracle数据库确保在业务切换时数据库一定可以打开接管业务，避免了数据库可能无法启动的风险；DSG Realsync 是基于交易指令的复制，因此对于那些产生坏块，或者是文件被破坏等操作将不会在目标系统重现。
2. 支持不同硬件平台之间的复制
RealSync技术是逻辑级的数据复制技术，因此对于生产系统和目标系统来说，其硬件平台可以属于不同的厂商、不同的型号，亦可采用不同的操作系统等等。它的优点在于：一方面，在系统建设时，为用户提供硬件平台的灵活选择空间；同时，提供了在同一解决方案架构下，实现企业不同平台上的多个信息系统的统一复制的支持。
如支持UNIX/AIX---Linux的复制容灾，大大节约成本。
3. 复制目标数据库处于OPEN状态、数据是实时的、可以支持实时数据库访问
RealSync维护的容灾数据库在数据复制过程中始终处于打开状态，客户可通过打开的Oracle数据库实现快速切换，且在目标端数据库提供数据查询、报表和ETL抽取等功能，实现业务分担；满足此次提供的业务需求。
4. 按需复制，满足业务需求，降低存储成本和网络成本
根据客户建设管理数据库的业务需求，很多情况下，仅仅对需要的数据表信息进行复制，realsync软件完全可以支持这类需求，这样也可以减轻复制的压力、减少存储和网络带宽的成本。
5. 对生产系统的低干扰性
DSG实时数据复制技术不需要通过任何数据库的引擎来获取变更数据，而是通过数据库自身的信息获取源系统上的改变并传送给目的系统，这不会对生产系统造成性能影响。
6. 提供不停业务的首次全同步功能和单表修复功能
RealSync还提供目标端系统数据初始装载功能支持，将主系统上的已有存量数据，在不中断业务的情况下平滑的装载到目标数据库上。这是realsync软件独有的功能。
7. 支持长距离复制、更低的网络带宽要求和运行成本
目前Realsync 是全球同类方案中要求最低的，交易级复制软件仅需要在网络上传输的量为Oracle redo log的1/3，一方面比Oracle DG的带宽要求低，当然更远远低于磁盘阵列、卷文件、虚拟存储复制所需要的带宽。
8. 成熟的产品、稳定的应用
DSG从2002年在中国成立以来，在RealSync这个数据库复制产品的项目实施方面也经过了很长的一段路。DSG始终以“客户需求为导向”的原则发展自己的产品，到目前为止，DSG RealSync产品已经在数据量超大的电信行业、安全性要求极高的金融行业、环境较为复杂的政府和企业中被广为采用，主要包括：
l 电信行业：北京移动、广西移动、甘肃移动、贵州移动、青海移动、澳门电信、广西电信、陕西电信、贵州电信、四川电信、山东电信、内蒙电信、河北电信、辽宁电信、吉林电信、江西电信、云南电信、安徽电信、海南电信、福建电信、甘肃电信、宁夏电信、新疆电信、广东电信、杭州电信、舟山电信、绍兴电信、湖州电信、辽宁网通、山东联通、江西联通、福建联通、广西联通、湖南联通、江苏联通、四川联通、吉林联通、广东联通、贵州联通、湖北联通、内蒙联通、贵州联通、云南联通…
l 金融行业：广发银行、太平洋保险集团、上海黄金交易所、中国金融期货交易所、中国期货保证金监控中心、天平保险、华夏基金、易方达基金、金元比联基金、友邦基金、招商基金、南方基金、鲁证期货、中银期货、东吴期货、信达期货、西部期货、国泰君安期货、鲁能金穗期货、东航期货、中原期货、中大期货、广发证券、银河证券、民族证券、宏源证券、新时代证券、上海证券、远东证券、太平洋证券、东兴证券、万联证券、金元证券、信达证券、江南证券、华泰证券、南京证券、信泰证券、东吴证券、长江证券、国联证券、东海证券、西南证券、山西证券、金通证券、中原证券、财达证券、西部证券、国盛证券、国海证券、华福证券、恒泰证券、湘财证券、华鑫证券、财富证券、中天证券、财通证券、国金证券、中投证券、华欧证券、中邮证券、德邦证券、爱建证券、华宝证券、联合证券、日信证券、英大证券…
l 政府行业：
国家知识产权局、北京电力、四川电力、河南电力、江西电力、青海电力、吉林电力、湖南电力、安徽电力、宁夏电力、天富热电、厦门电力、河北省地税、重庆地税、深圳地税、深圳市统计局、武汉财政、上海松江财政、吉林省交通厅、辽宁省征稽局、蛇口码头、宁波港、江苏省航道局、江苏农垦、无锡公积金、贵州公安、东营公安、青岛有线、泰州社保、南通社保、阿克苏社保、太仓社保、中国一汽、济南钢铁、南京军区总医院、格力电器、深圳神州通集团、深圳统计局、阿里巴巴、河北省地税11地市征管数据集中容灾备份系统、江西省电力12地市营销数据集中容灾备份……
2.4 RealSync在应急灾备方面的特点
l 零时间数据库切换的热容灾：
系统恢复时间是指当主系统出现故障不能在短期内恢复，而需要启动容灾端系统时，容灾端系统启动的时间。该时间不仅仅是指容灾端的硬件系统启动，更主要的、也是更耗费时间的是容灾端数据库系统的启动、业务系统的启动和外部接口的切换等。其中又以数据库的启动最为耗费时间，因为容灾端数据库不属于正常下线，因此重起时需要作许多检查和恢复，花费的时间非常长。
RealSync维护的容灾数据库系统在数据复制过程中也始终处于打开状态，保证数据复制在逻辑上的完整性，保证灾难切换的时效性和可靠性，RealSync技术为源系统提供了永远可用的后备数据库系统。在源系统出现故障时，应用系统可实现实时访问备用数据库系统。达到数据库系统的零切换目的。
打开的备份数据库保证数据复制在逻辑上的完整性，为源系统提供了永远可用的后备数据库系统，确保容灾系统的可靠性。
当源系统出现故障时，应用系统可实现实时访问备用数据库系统，无需重新启动备用数据库，达到数据库的秒级切换目的。
l 异构的系统平台，开放的硬件选择：
RealSync技术是逻辑级的数据复制技术，因此对于生产系统和容灾系统来说，其硬件平台可以属于不同的厂商、不同的型号，可采用不同的操作系统等。它的优点在于：一方面为用户提供容灾系统建设时，硬件平台的可灵活选择空间；同时提供了在同一容灾解决方案架构下，实现企业不同平台上的多个信息系统的统一容灾支持。
l 支持从高到中低端应用需求：
由于RealSync在建设容灾系统时，对服务器、存储阵列和传输带宽要求都无特殊要求，而不同于传统容灾技术要求高端磁盘阵列、高端服务器、数GB的传输带宽，所以该系统适应于高端的电信、金融客户、也适合中端的政府机构、大型企业、同时也适合于运行PC平台的中小型企业应用。
l 投资回报分析（ROI）：
采用RealSync容灾技术，容灾数据库始终处于打开状态，不同于其他模式下容灾数据库系统不可用的状态。因此，可以通过RealSync维护的容灾系统，提供数据共享服务：
为决策分析和报表系统提供快速的数据抽取功能
提供准实时脱机查询，提高查询效率
为试验系统提供真实的生产数据
将以上本来需要在主系统上运行的业务与生产系统完全隔离，充分利用容灾系统的资源，实现企业应用负载分担，减少对生产系统的影响，提高服务系统响应效率；从而将容灾系统这个成本中心转化为利润中心。
l 灵活的组网结构和低带宽资源需求
RealSync采用交易（Transaction）传输方式，极大的减少了复制过程中需要传输的数据量。使得在网络上传输的数据量大大减少，要求更低的网络带宽。Realsync支持标准的TCP/IP网络传输，用户可灵活布建容灾网络架构。
系统可支持1:1、N:1、1:N和双向容灾结构支持，提高企业容灾结构的灵活性。
2.5 RealSync在报表分担、数据共享利用等方面的特点
l 按需复制
查询和统计系统往往不需要所有的原始数据，因此完全可以按需要复制数据。RealSync系统支持对指定信息的按需复制，如指定需要复制的表、字段和条件等，减少存储和网络带宽的成本。
l 实时数据更新
实时更新保证副本系统快速反映源系统的变化，提供账单查询、话单查询等的及时性。经过大量的测试，实时数据复制技术使源系统和目的系统的数据延迟<10
秒。
l 对生产系统的低干扰性
DSG实时数据复制技术不需要通过任何数据库的引擎来获取变更数据，而是通过数据库自身的信息获取源系统上的改变并传送给目的系统，不会对生产系统造成性能影响。
l 系统异构，可提供更多的优化空间
源数据库系统和目的数据库系统的可异构，主要包括索引规则和存储参数（如数据块大小、回滚段等）。因此可以在目标数据库上根据业务特点进行调整和优化，完全不受源系统的限制。
3 方案设计
数据库同步复制软件是****医院实施关键系统灾备工程的一个重要组成部分，当生产系统出现异常或故障时，备份系统的数据库能够完全代替生产系统的Oracle 数据库管理系统，以实现关键系统的正常运行。
l 业务功能实现：
在关键业务应用系统的数据库上安装复制软件代理程序，通过代理程序获取数据库的交易，实现数据变化的实时跟踪。抓取的数据通过1000Mbps以太网进行实时传输，实现系统数据同步到备份系统上的实时传输。
l 技术实现：
复制软件是采用交易复制的方式进行数据同步；灾备数据库上的Oracle数据库处于OPEN状态，可提供实时数据访问；如可将生产系统上的统计查询等业务运行在历史的Oracle数据库上，数据复制的时延可以空载在3-5秒左右；具体细节如下：
3.1 方案设计
根据以上系统状况和功能要求，本期项目将采用1套Realsync数据库复制软件来完成：
根据业务需求，在关键系统安装DSG RealSync程序，该程序对ORACLE数据库产生的redo log进行实时分析，生成sql语句。并将sql语句通过IP网络传输到历史数据库。
3.2 Realsync软件配置
DSG realsync软件的安装分为生产系统和目标系统两个方面：
n 生产系统上：
DSG realsync在每个数据库实例都要安装一个production agent，用来分析本agent产生的redo log数据。
n 目标系统上：
DSG reasync在备份中心的服务器上，分别安装一个realsync，但需要为每个
各模块的作用：
RealSync for Production Server：
安装在源系统（Data Source）上运行数据库实例的服务器上，每个数据库实例配置一个License；
该模块中又包含以下功能：
ü Analyzer Module：日志分析功能
ü Synthisizer Module：交易合成功能
ü sender Module：数据传输（输出端）功能
RealSync for Destination Server：
安装在复制目标系统（Data Target）上运行数据库实例的服务器上，每个数据库实例配置一个License；
该模块中又包含以下功能：
ü Importer Module：数据传输（输入端）功能
ü Loader Module：交易指令装载功能
RealSync Full Sync
首次全同步功能；
提供从源数据库上把已有的存量数据初始化同步到目标系统上来，即将源系统上的所有表的数据export出来传输到备份系统上import进去，实现初始数据的同步。
该模块的特点是在初始化过程中无需业务停机，而且可以多路并发，可处理全同步过程中的变量数据。
RealSync management console：
管理控制界面；
3.3 性能和资源需求估算
在关键业务系统中的应用，性能和压力是复制软件的核心，是每天每时每刻都用到的，尤其是在业务高峰期情况下，能否跟得上日志的产生速度、能否不大量的占用系统资源、能否保证复制的及时性是整个数据库复制软件产品最为核心的内容。
根据我们在各种国内的几十家应用情况显示来看DSG RealSync在实时复制方面的性能是同类产品中领先的。主要体现在：
n 网络需求
RealSync对数据传输采用TCP/IP网络传输。RealSync复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。RealSync只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3。根据估算，如客户每天产生的日志量约为10GB，我们按照80%的日志量在1天的20%时间内（这里设为4小时）产生的，那么我们可以估计高峰期的日志量为8GB/3*1024*1024/(4*3600)=1.5Mb/s。同时为了预留一定的带宽，建议将带宽作为10Mbps就能满足日常的复制需求。本项目的带宽情况完全能够满足要求。
n 日志分析速度
我们采取了积压日志分析的方式进行测试，利用rac环境下的两台服务器同时产生10GB的日志数据，然后启动realsync测试其在多长时间内能够分析完这些数据。测试结果表名，在rac模式下，由两个数据库节点同时工作，在5分钟内产生的10GB归档日志，共计800万条记录，realsync只需要2分钟40秒即能分析完累积的日志，约9分钟装载完成。日志分析的速度远远高于产生日志的速度。完全能够满足用户IT系统的业务需求，即使是在业务高峰期，也不会造成日志累积。目前DSG的用户中，广西移动每天的增量日志达到600G，realsync依然稳定运行。
n 每秒钟复制的操作数
在测试过程中，我们采用PL/SQL方式在源端产生1万,10万，100万条记录，以及进行1万,10万，100万的update,delete操作等。按照统计结果，DSG RealSync 达到平均18000条/s的复制速度。完全能够满足单系统上用户IT系统的业务要求。
n 复制数据延迟
RealSync是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。如果每天产生30GB的日志量，在30Mb带宽的情况下，可确保数据的延迟在5秒钟左右。
n CPU资源占用
DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为<5%的CPU资源占用。根据我们在河北地税的使用情况来看，在系统高峰期每2分钟产生100MB的日志量，而REALSYNC的日志分析资源占用仅为2%（4cpu,8G ram）。
n 源端的缓存空间
当灾备中心暂停或传输异常中断导致复制停止时，RealSync会将数据库的变化内容存储在源系统或目标系统的队列中，当系统恢复后，RealSync会自动识别复制环境，自动从断点处开始复制工作。在上述过程中，主中心的业务不受任何影响。数据的一致性不会破坏。当复制环境停止的情况下，需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。根据每天平均产生25GB
的日志计算，我们建议在源端给REALSYNC预留的缓存空间能够满足一天的缓存量：按照1/3的比例计算并增加一定的富裕量，需予留10GB的缓存存储空间。n 业务切换
RealSync是通过对Oracle Log日志进行分析获取跟踪源系统的交易指令实时的将指令传输到目标端进行加载，且目标端数据库始终在OPEN状态，可实时在目标端进行查询和统计，所以当灾难发生时或在主机源端发生故障以后，可直接将生产端数据库切换到容灾端，目标端数据库不需要重新启动，确保目标端数据的可用性，并大大提高了RTO、RPO指标。
3.4 系统实施概述
（一）系统安装
REALSYNC的安装点包括如下：
l 在每个系统的数据库服务器上（RAC环境下是安装在一台服务器上，一个服务器上有多个INSTANCE时，需要为每个INSTANCE安装一个Realsync Agent），配置一个REALSYNC AGENT，启动一个agent端口；
l 在灾备中心的每个服务器上安装一个ORACLE Agent，但要为每个instance启动一个agent端口；
（二）首次全同步
首次全同步是此次项目中一个非常复杂的问题，因为如何将生产系统首次同步到查询中心是一个非常复杂的问题，也是本项目中的一个难题。
复制环境的建立，首先需要将生产系统中的已有数据初始化同步到目标系统上，同时记录各种系统状态和映射关系等。因此如何快速、有效的建立复制的初始化环境是每个复制系统都非常关心的问题。
全同步是关键系统中一个非常复杂的问题，因为如何将生产系统首次同步到灾备中心是一个非常复杂的问题，也是本项目中的一个难题。
从目前的技术来看，能够实现首次全同步的方式有多种方案：
第一：备份/恢复的方式
第二：ORACLE EXPORT/IMPORT方式；
第三：采用复制软件自带的首次初始化功能。
在传统办法中，数据首次同步过程大都采用Oracle的EXP/IMP工具，将源端数据库数据抽取出来，通过网络传输至目标端数据库进行加载。或者是借助第三方的备份软件工具，将源端的数据进行备份，再通过磁带运输至目的地，将磁带数据恢复到目标数据库，从而达到首次数据同步的目的。
这种方式存在大量的问题：
（1）性能低下：通过Export/Import方式，最大的问题在于性能很慢，对于一个几十GB的数据库，进行一次export/import，则大约费时8－10小时以上。
（2）完全需要手工干预：数据的导出（Export），传输和装载（Import）等过程都需要手工干预和执行。
（3）业务必需停止：在执行export/imp过程中，业务必需中断。（4）易出错：尤其在Import过程中，由于表之间的关联性存在，往往出现由于违反参照完整性规则而导致装载中断，非常难于操作。
根据关键系统的需求来看，我们在作首次同步的时候必需满足以下几个条件：
一：大数据量下如何快速首次同步
二：如何简化首次全同步的操作步骤
三：如何作到首次全同步过程中对生产业务不造成影响
四：如何支持异构环境下的数据首次同步？
根据以上几个条件，我们认为采用DSG realsync自带的首次全同步功能才能够简化首次同步的操作复杂程度。因为前两种方式无论在操作复杂程度上，还是是否需要停止业务方面都表现得不好，主要在于：
l 备份/恢复方式：数据量大，无法通过网络传递；
l exp/imp：数据量大，导出时间漫长。同时导出时需要停止业务。
而DSG在数据的一致性同步方面有着非常好的解决方案，这是其它方案所不具备的。DSG的RealSync集成有数据的一致性同步工具，能够自动化的进行数据的首次同步和出现差异情况下进行一致性同步的工作，无需人工干预，维护工作量小，且大大提高了工作效率：
（1）速度快：对于几十GB的数据量，在正常情况下，只需要1小时左右完成初始数据同步。
（2）完全自动化：采用DSG RealSync只需要１条命令就完成系统的初始化工作，系统自动进行导出、传输和装载任务，完全无需人为干预，减少出错机会。
（3）不中断业务：在DSG Realsync在进行首次数据装载时，无需停止源端业务，实现不停机的系统初始化；
（三）全同步实施步骤
对于一个数据库的全同步过程包括：
1. 在容灾端安装ORACLE数据库
因为容灾端是两个ORACEL INSTANCE，创建ORACEL DATABASE。
2. 启动实例并create database
采用逻辑同步方式，必需手工在目标端建立好instance和database.
为了确保目标端的性能最优，可采用与生产数据库相同的参数。使用源端的SPFILE参数。
3. 创建tablespace和user
tablespace和user由管理员创建。DSG可以提供导出脚本的程序帮助管理员生成现成的脚本，管理员只需要作简单的修改后就可在容灾系统上创建。
4. 调用realsync的set dict命令创建所有的用户对象
DSG 提供了的set dict命令用于在目标端创建与生产端相同的所有objects。包括：functions、procedures、packages、types、triggers、java sources、jobs、libraries、directories、tables(含indexes,constraints,grants)、views、sequences、profiles、roles、synonyms、database links等
5. 数据抽取与装载
执行命令set dm 1.1 account account –sync ftciq –th 20进行数据的同步，系统自动进行数据抽取、传输、装载，并自动分析其间产生的日志。无需人为干预。
当存量数据装载完后，系统自动利用期间产生的日志进行数据的修补到一致状态。
首次同步结束后，系统自动进入到增量实时复制阶段，不需要人为干预。（四）时间估算
根据生产系统为40GB的量计算，在4Mb带宽下，全同步的时间主要是数据传输时间和目标端装载时间。
数据传输时间：
40GB的数据量经过压缩后约为10GB左右，按照4Mb带宽计算为：
10GB*1024*8/4Mb/3600=5小时。
按照一定的富裕量计算，可在6小时左右完成数据的首次全同步。
因此对于40GB的数据量，根据工程性能指标参考，可在6个小时左右完成全同步。
（五）开始实时复制
当对系统的初始化环境工作结束后，RealSync自动进入实时复制状态，无需手工干预。
4 RealSync产品原理
目前此类软件没有相应的技术标准，因此特将RealSync软件的原理展示给大家，作为评判的标准。
示意图：
如上图所示，RealSync在Data Source端和Data Target端分别安装Agent进程，Source端的Agent进程对ORACLE日志进行监控，发现改变及时对目标数据库进行更新。
当应用系统在Data Source端向数据库进行任何操作时时，这些信息都将在Redo Log中保存，RealSync Agent通过对实时获取的Log日志进行分析，获得本次操作的交易指令和交易数据，然后将这些交易指令和交易数据经过格式转化生成DXF数据格式，并实时通过网络传送到Data Target系统。
Data Target系统的RealSync Agent接收数据库包，经过校验码检查，确认正确的数据库包后，调用Oracle函数按照交易的先后顺序在Data Target系统中执行该交易。
4.1 日志抓取（Data Capture）
RealSync对数据的抓取是通过安装在Data Source端的Agent模块定时分析Oracle Redo Log来获取Data Source端的交易类型及数据的。
RealSync Agent在判断Data Source端的Oracle系统是否有新的交易产生时是通过定期检查Oracle Controle file中记录的当前SCN号来判断的，这样避免每次检都通过读取log文件来判断否有新的交易产生时造成的系统影响。
在Controle file中确认有新的交易产生时，可以同时获得当前的Redo Log 组，以及最新日志在日志文件的最新位置。
RealSync Agent模块根据这些信息将上次抓取时记录的日志位置与本次读取的最新位置之间的Log读取并加以分析。然后将这些数据保存在Online Log Cache 文件中，等待下一步作交易合成处理。
RealSync的优势：
与其他类似日志复制产品相比，RealSync对日志进行分析，得到交易信息再进行传送；而其他类似产品不对日志作分析，传送全部日志，然后在目标端通过日志作Recover，这样一来，不仅传送数据量大，而且目标端数据库不能打开。
4.2 日志分析（Analyze）
Oracle数据库的所有更改都记录在日志中，其中记录了对数据库中的每一个变化。
当我们候需要需要了解数据库中所作的交易时，一个最有效实用而又低成本的方法就是分析Oracle数据库的日志文件。
RealSync Agent中集成了DSG的优秀日志分析功能，该功能完全不同于Oracle 提供的Logminer日志分析工具，在性能和功能上都大大提高，主要体现在系统性能的优化上，大幅度提高日志分析的速度，使得对于高并发业务系统的复制成为可能。按照RealSync的日志分析设计目标，每秒能够分析的日志量达到10M/s。RealSync通过对日志的分析，得到该数据库中的每个SQL指令，并将这些SQL 指令生成DXF（DSG Extend Format）格式的表达方式。
DXF格式是DSG公司的专有技术，该技术是DSG公司用来表达SQL指令的方式，该数据格式能够通过DSG的专有转换算法能够直接转换为ORACL的内部数据表达格式，从而在分析和转载时需要最小的转化，提高分析和装载速度，减少资源占用、丰富能够表达的各种数据类型。
4.3 交易合成（Synthesize）
通过ORACLE REDO LOG分析的交易指令存在如下的几个特点：
（1）这些指令是交叉出现的，属于一个交易（Transaction）的多条SQL指令是非连续存储的，多个交易的SQL之间是相互穿插的；
（2）Redo log中记录了所有的commit的交易以及没有commit的交易；
所以，为了提高系统的可控制性、保证逻辑完整性、避免数据丢失，最好将复制的最小单位为一个交易（Transaction），而不是以单个SQL指令为复制单位，这样在Data Target端的交易装载更加容易控制。
同时，对于复制的数据而言，只有那些Commit的数据对于Data Target端系统是有意义的，而对于那些Rollback的数据无需复制到Data target系统上。
所以RealSync在复制过程中不是复制每个SQL语句，而是对抓取的数据进行交易整合后以交易（Transaction）为单位进行复制，同时只复制COMMIT的交易。如上图所示，在Online Log Cache文件中，包括Commit的交易，没有Commit 的交易和Rollback的交易。交易合成模块首先按照交易序号对SOL语句进行划分，每个交易包含多条SOL语句。然后，以交易为单位进行处理，将已经Commit 的交易，传至传输处理模块；将未提交的交易保存在本地，一旦通过日志得知保存的未提交交易已提交，立即将该交易发送到传输处理模块；对Rollback的交易作丢弃处理。
RealSync的优势：
RealSync是以交易为单位进行传输的，而不是以SOL语句为单位进行传输的，更容易保证数据的一致性和完整性。
4.4 交易传输
RealSync技术为了保证数据传输的安全、可靠，在传输处理上作了特殊的处理与支持:
（1）数据在传输之前首先存入Data Source端的Cache，传输进程
（Export Process）从Cache中读取交易数据封装为TCP/IP数据包传送给Data target端的Import进程。
（2）在data target端，Import进程在收到传输的交易数据包后，首先存入Queue，然后由Load进程从Queue中严格按照交易的顺序装载交易信息。
如上图所示，负责传输的进程（Export Process）从本地队列中按照先进先出的原则抓取需要传输的交易，将交易数据封装成一个数据包后通过TCP/IP协议传递给对端系统。在封装的数据包的包头部分描述了包的大小。
对端系统在接受到传来的数据包后，首先根据包头描述的包大小进行传输的合法性检查，判断是否传输完整。
4.5 数据装载
在传统的复制技术中，常用的数据装载方式是采用Oracle 的SQL接口，通过Insert、Update、Delete等SQL语句实现数据的装载。这种方式在通用性上很好，但关键在于性能问题非常突出。
SQL语句的执行需要经过parse、plan、格式转换等过程，造成大量的系统开销。尤其是update和Delte操作的大量Where子句操作需要进行复杂的查询定位任务，从而导致装载性能低下，对处理能力的要求比生产系统的还高。
DSG RealSync在设计之初就定位于电信级大数据量系统的应用，因此在装载性能上进行了大幅度的改善，使得装载端的性能和处理能力需求降至最低。
在其中DSG RealSync采用了两个关键的技术提高了装载速度：
（1）采用DXF数据格式的装载；
（2）采用Rowid mapping的方式实现快速定位；
(一) 用DXF数据格式的装载：
DXF（DSG Extend Format）格式是DSG公司的专有技术，该技术是DSG公司用来表达SQL指令的方式，该数据格式能够通过DSG的专有转换算法能够直接转换为ORACL的内部数据表达格式，从而在分析和转载时需要最小的转化，提高分析和装载速度，减少资源占用、丰富sql语句的表达方式。
Oracle数据库系统在设计上提供了4个层次的接口，其中包括User层，SQL层，Transformation层和I/O层。其结构为：
在这四层当中，当采用SQL接口进行数据装载时，调用的是User层，
而DSG RealSync通过DXF数据格式装载时，调用I/O层直接将数据通过Oracle 的最底层函数写入系统中，所以DSG RealSync在装载层上有一定优势；
(二) Row mapping实现快速定位
对于交易中的操作，存在着大量的Where子句操作，在采用标准SQL语句执行这些操作时，系统需要首先定位目标记录所在的数据文件的位置信息，这将带来大量的索引查询开销，当并发执行数千条指令时，系统的开销将变得非常庞大。DSG RealSync工具不采用该方式实现装载数据的定位，而是通过ROW Mapping 的方式实现记录的快速定位：
当RealSync从源端Log文件中读取交易数据时，将获得该交易对应记录的所在位置，用rowid表示为rowid_ds；
当该交易在目标端装载时，系统不翻译为Where子句，而是去通过保存在目标端的row mapping表获得对应目标端该记录的所在位置rowid，记录为rowid_dt。
从而在目标端装载时通过rowid能够直接定位于该数据需要写入的位置。避免了大量的索引查找时间。
每条记录的row mapping信息是在该记录执行insert操作、sql loader或首次批量同步时建立起来的。
RealSync的优势：
DSG扩展格式DXF(DSG Extend Format)是RealSync产品的一个核心技术，是一种最高效率表示ORACLE记录的数据格式，该格式只需要经过最小的转换过程就能够装载到ORACLE数据库中，并且装载效率非常高。
n 无需标准SQL语句执行的复杂过程
n 加快装载速度
n 对于Update，Delete等带Where子句的交易，可以大幅度提高装载速度
5 应急响应方案与灾备演练计划
5.1 容灾管理规划
众所周知，容灾不是简单的设备冗余。除了IT技术方面的设计，还应着重考虑管理层面的问题，例如灾难管理组织结构、灾难恢复流程等。灾难管理组织结构中定义了灾难发生前、中、后，各相关人员的职责；灾难恢复流程书面化各恢复工作的流程和执行步骤。BCP和DRP中应包含以下内容：
l 灾难管理组织结构
l 应急响应流程
l 灾难评估流程
l 灾难恢复决策流程
l 容灾系统启动流程
l IT系统切换和回切流程
l 业务验证流程
l 业务恢复流程
l BCP或DRP的管理方法
l 容灾演习的规划
5.2 复制软件的日常维护
作为realsync软件的运行，日常维护也是非常重要的方面，维护的内容主要包括：
l 检查复制软件是否运行正常
l 启动和停止复制任务进程
l 排除复制过程出错的错误
l 检查复制的工作状态是否与业务需求有较大偏差
l 数据一致性的检查
l 修复不一致的数据
l 维护容灾端Oracle数据库工作状态
以上是针对复制软件日常维护需要作的事情
5.3 人员组织结构规划
根据容灾项目的运行维护特点，一般要求容灾项目的部门、个人的设置包括如下
几个方面。
容灾项目领导小组
l 对容灾项目总体负责
l 制定项目组工作制度
l 制定项目计划
l 跟踪项目过程
l 控制项目变更
l 审核项目成果
l 评价项目组成员、部门的工作情况
l 协调项目所涉及的内部及外部资源
l 为项目组各部门提供良好的沟通渠道
l 召开项目评审会，组织项目验收工作
容灾项目经理
l 作为技术负责人和技术经理在容灾系统建设件领域有多年的经验
l 有丰富的不同类型容灾技术实施方法的分析和设计的经验l 有经验于容灾的设计研究，可能采用的容灾系统设计模型/方法 /工具的拟定，以至于容灾系统的二次设计
l 定义灾难管理框架
l 规范灾难管理流程
l 制定业务连续性计划规范
l 协助客户建立灾难管理组织结构
l 协助并指导业务连续性计划的开发
l 制定灾备测试要求
l 主持制定灾备演练计划
l 主导灾备演练并给予指导
l 其它相关咨询工作
系统专家
结合关键系统的实际情况、容灾项目的具体要求为数据中心异地容灾项目提供有效、稳定、高效、可靠的运行优化，系统技术部分包括：
l 服务器和UNIX操作系统管理员
l 磁盘阵列和SAN存储管理员
l ORACLE数据管理员
l 中间件技术管理员
l 应用程序管理员
l 数据库复制软件管理员
网络专家
复制容灾项目中的网络建设、尤其是容灾切换过程中的网络切换过程专家。5.4 《重大故障应急备份切换方案》
安装情况不同，备份切换分为备份数据库的切换，服务器切换、存储切换以及其他子系统的切换。分别描述如下。
（1）基于DSG系统的数据库灾难恢复步骤（灾备中心）：
在生产数据库系统发生灾难的情况下，此时可使用容灾数据库首先接管业务，然后进行数据的反向恢复，最后进行时间一致性检查，恢复系统正常状态。
在生产数据库系统发生灾难的情况下，此时可使用容灾Oracle数据库，首先接
以上过程是利用灾备中心的系统首先接管业务后，再进行生产中心的修复和数据的反向复制，因此不会造成长时间的业务中断。
（2）数据一致性检查:
对于ORACLE而言，数据一致性的检查主要是通过数据库的SQL接口读取记录，进行对比的方式进行。而这种比对方式耗时巨大，效率十分低下，如果对于一些没有主键的表就几乎无法比较。
DSG在数据一致性校验的检查机制方面做的尤为突出，并且使得这一需求变得可行。在其它同类产品中，DSG Realsync不是通过select接口来读取数据并进行比较，而是通过批量读取的方式从数据库底层直接读取记录，并通过rowid的对应关系来定位记录，并通过数据源的记录值、ROWID，目标端的记录值、ROWID，以及Realsync所记录的ROWID映射关系来比较双方的记录是否一样。
这种方式省却了大量的从select接口查询记录的资源占用和时间消耗。并且能够比较到每条记录，能够清晰定位不一致的记录。无论被比较的表含有主键或者没有主键，都能进行比较，并且比较的性能一样。
科力锐灾备云服务项目方案书 深圳市科力锐科技有限公司 2019年2月
目录 一、项目服务背景................. 错误!未定义书签。 二、项目服务特点 (4) 三、科力锐灾备云平台和服务简介 (6) 四、科力锐灾备云平台和服务特点 (12)
近年来，国家大力推动“互联网+”战略，即通过“互联网+各个传统行业”的形式，利用先进的信息通信技术与传统行业进行深度融合，改造传统的生产、办公、经营方式，提高各个企事业单位的效率，创造新的发展生态。政府信息化全力推进，政府部门间、对企业、公民的政务全部以电子化开展，即用电子化、无纸化办公的形式取代传统的依靠纸质文档和人工流转办公的方式，大幅提升工作效率。企、事业单位也将生产、办公系统化，为繁荣社会经济、扩大城乡就业、增加财政收入、推动自主创新和促进科学发展发挥了重要作用。但部分企、事业单位依然存在着资金短缺、人才匮乏、管理滞后、信息化能力弱、产品和市场信息不畅、市场竞争力不足、互动渠道窄等问题，限制了产业竞争力的提升。 在国家推动“互联网+”战略的大背景下，企事业单位信息化系统急需数字化转型，数据资产化趋势明显，同时业务系统已经成为各个组织单位的“生命线”，越来越多组织已认识到灾备的重要性。 然而，由于主机故障、系统故障、软件逻辑错误、人为操作失误和病毒攻击（例如勒索病毒）等众多风险高发引发灾难，极大的威胁了企事业单位的IT应用系统的安全和服务的连续性，需要能够提供灾备服务作为防范各类风险的最后一道屏障，帮助发生系统灾难的企事业单位快速的恢复IT应用系统保障生产经营工作得以正常开展，意义十分重大。 因此，一方面需要考虑如何保障组织的核心数据资产不丢失，另一方面需要考虑如何保障组织的核心业务系统不停或者少停。 从灾备的角度而言，各企、事业单位将会面临以下几点挑战： 1、如何获取专业的灾备技术服务，降低数据丢失风险，满足数据保护需求。 2、如何能在降低灾备建设成本的基础上，让各单位都能够低成本使用成熟、可靠的 灾备技术方案，保障核心数据资产不丢失。 3、如何在缺乏专业的灾备运维管理人员，管理人员技术水平参差不齐的现状下，确 保在核心业务系统出现问题而中断时能够快速进行恢复。 4、如何在IT架构混合化、多元化的大环境和趋势下，确保灾备技术方案能面向未来 的适应各单位数据中心的快速扩展。
数据中心灾备服务 方案相关内容 如何应对“将鸡蛋放在一个篮子里”所带来的风险？对于信息化应用而言，灾备系统的建设已成为备受关注的热点和重点。 概述 数据中心是数据大集中而形成的集成IT应用环境，它是各种IT应用服务的提供中心，是数据计算、网络、存储的中心。数据中心实现了安全策略的统一部署，以及对IT基础设施、业务应用和数据的统一运维管理。 数据大集中的同时也对数据安全提出了更高的要求，如何应对“将鸡蛋放在一个篮子里”所带来的风险，已成为备受关注的重点。面对频频发生的雪灾、地震等自然灾害，对于信息化应用而言，灾备系统的建设也已成为热点。随着2007年11月《信息系统灾难恢复规范》正式成为国家标准，许多用户将从观望、徘徊转向实际应用。对于正处于服务转型期的电信运营商来说，借助灾备中心应用热潮，提供更有价值的信息化服务，改变原有的、单一的网络接入商角色，是值得把握的一次良好机会。 灾难备份概念介绍 1. 灾难备份的分类 灾备从应用层次，大体可分为三个类别：数据级别、应用级别和业务级别。从用户整个业务连续性的保障程度来看，其高可用性级别也随之逐级提高。 1) 数据级别 数据级别灾备的关注点在于数据，即灾难发生后可以确保用户原有的数据不会丢失或者遭到破坏。数据级别灾备是保障数据可用的最低底线，当数据丢失时能够保证应用系统可以重新得到所有数据。这种方案的优点是投入低，构建简单。 2) 应用级别 对于业务应用繁多，并且系统需要保持7*24小时连续运行的企业来说，显然需要高级别的应用灾备系统来满足其需求。应用级备份是在数据级灾备的基础上，在备份站点同样构建一套应用系统。应用级灾备系统能提供不间断的应用服务，使用户的服务请求能够透明地继续运行，保证信息系统提供的服务完整、可靠和安全，完全不受灾难的影响。一般来说，应用级灾备系统需要通过更多软件来实现，它可以使企业的多种应用在灾难发生时进行快速切换，确保业务的连续性。 3) 业务级别
数据中心解决方案之灾备方案设计 1.数据中心容灾备份解决方案 随着社会的发展和科技的进步，政府日常工作越来越依赖于数据处理来进行，政务系统的连续性依赖于数据中心系统的稳定运行。然而，灾难就像灰尘一样伏击在运营环境周围，政务系统的数据中心可能正在一个充满风险和威胁的环境下运行。如果不能对这些风险采取有效治理，一旦数据由于某种原因丢失，就很有可能对政府的日常工作造成严重的影响。如果核心数据丢失，将会使得某些核心功能陷入瘫痪，造成不可估量的损失。因此，保证政务的连续性和数据的高可靠性和可用性，已经成为政府部门在数据中心建设中，必须要考虑的问题。 1.1灾备解决方案原则 首先，在制定容灾系统方案的过程中要考虑的就是容灾系统建设对原有业务系统带来的影响。比如，采用数据复制技术对系统I/O带来的延迟，应用数据同步对日常业务处理系统带来的压力等。因此，企业要通过周密的测试和分析来规避容灾系统建设时带来的这些风险，以保证业务系统不会因容灾系统的建设而出现在处理性能上下降的问题。 第二，数据状态要保持同步。为保证在灾难发生时，业务可以成功地切换到备份中心，就必须保证容灾系统数据同步机制的可靠性。因此，建立可靠的数据同步校验机制是必须的; 同时，还要考虑建立定时的、自动的数据同步核查对比机制，以检验两个中心数据的一致性，这是数据容灾工作中非常重要的一部分。
第三，容灾系统的日常维护工作要尽可能轻，并能承担部分业务处理和测试的工作。容灾系统的维护和管理是容灾切换成功的重要保证，在系统建设中，就必须要考虑系统的维护管理流程。生产中心任何业务处理过程的改变都必须完整地复制到备份中心; 所有新业务系统上线时，必须通知备份中心，并在备份中心配置好数据同步机制; 对原程序的改动也必须保证两个中心同时上线。 第四，系统恢复时间要尽可能短。容灾系统主要是为了实现在主中心系统发生灾难时，可以在规定时间切换到备份中心，保证数据不会丢失，并且继续向用户提供服务。但往往在灾难发生时，主要技术人员不能及时到达现场，为了顺利实现系统间的切换，应该让系统切换操作尽可能地简单; 并建立固定化的、标准化的切换流程，要求维护人员在切换演习时严格按照流程的指导步骤进行操作。 第五，可实现部分业务子系统的切换和回切。当人事变动、业务变化、IT设施变化以及其他可能引起恢复规划文档失效的变化发生时，应及时更新各恢复规划文档，并在必要时启动模拟测试或演习，确保业务连续性系统的工作能力。 第六，技术方案选择要遵循成熟稳定、高可靠性、可扩展性、透明性的原则。目前，国际上比较成熟的容灾技术包括：SAN/NAS技术、远程镜像技术、虚拟存储、基于IP的SAN互连技术以及快照技术等。其中基于IP的SAN远程数据容灾备份技术应用比较广泛，其是利用基于IP的SAN的互连协议，将主数据中心SAN中的信息通过现有的TCP/IP网络，远程复制到备份中心的SAN中的。当备份中心存储的数据量过大时，可利用快照技术将其备份到磁带库或光盘库。这种基于IP的SAN远程容灾备份，可以跨越LAN、MAN和WAN，成本低、可扩展性好。基于IP的互连协议主要包括FCIP、iFCP、InfiniBand、iSCSI等。
XXXXXXX客户中心机房设备监测及同城容灾系统项目 灾备系统实施方案 2011年5月25日 XXXXXXX有限责任公司信息中心
目录 第1章项目背景 (3) 第2章目标和范围 (3) 第3章灾备系统的规划 (4) 3.1.总体建设原则 (4) 3.2.灾备系统架构 (5) 3.3.数据复制策略 (5) 第4章灾备系统的实施 (6) 4.1.灾备DS5100的配置 (6) 4.1.1.磁盘组的划分 (6) 4.1.2.LUN的划分 (7) 4.1.3.存储HOST的配置 (8) 4.2.复制存储网络的配置 (9) 4.2.1.生产中心SAN连接 (10) 4.2.2.灾备中心SAN连接 (10) 4.2.3.Zone的划分 (10) 4.3.ERM的配置步骤 (12) 4.3.1.初始安装和配置 (12) 4.3.2.创建镜像关系对 (12) 第5章灾备数据验证 (19) 5.1.公文系统灾备数据的验证 (19) 5.2.邮件系统灾备数据的验证 (20) 5.3.财务银行系统灾备数据的验证 (21) 5.4.财务管理系统灾备数据的验证 (23) 5.5.统计报表系统灾备数据的验证 (24)
第1章项目背景 第2章目标和范围 灾备系统的建设是个循序渐进的过程，从灾备系统的业务和数据恢复能力上，可以将灾备系统分为数据级灾备系统和应用级灾备系统。数据级灾备系统的关注点在于数据保护，即灾难事件发生后如何确保重要信息系统的关键数据不会丢失或者遭到破坏。应用级灾备系统是在数据级灾备系统的基础上，不仅提供数据保护功能，而且还提供灾难事件发生后的业务接管能力。 XXXXXXX根据行业内信息系统的现状和灾备建设的总体规划，确定本项目的灾备建设目标为同城数据级灾备系统。 同城灾备系统与生产中心处于同一地理区域，面临同一区域性灾难风险，故同城灾备系统用于非区域性灾难事件，即：生产中心发生的设备故障，或者人为操作错误，以及生产中心所在建筑发生的水灾、火灾、电力异常等突发事件，导致生产中心重要信息系统的关键数据部分损坏或者完全丢失，致使生产中心业务系统陷于停顿。 本项目中，灾备系统建设的范围将涵盖集团公司重要信息系统的关键数据，这些重要信息系统包括： ?财务银行系统 ?财务管理系统 ?统计报表系统 ?人力资源系统 ?运销系统 ?协同办公系统
数据中心容灾备份方案 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 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。 备份介质层（内置虚拟带库）：主流备份介质有备份存储或虚拟带库等磁盘介质、物理磁带库等，一般建议将备份存储或虚拟带库等磁盘介质作为一级备份介质，用于近期的备份数据存放，将物理磁带库或者光盘库作为二级备份介质，用于长期的备份数据存放。
数据中心灾备系统的分类 根据数据中心的安全要求，应对灾难恢复系统采用的技术路线做出全面的考虑。 1.数据级容灾和应用级容灾 按照容灾系统对应用系统的保护程度可以分为数据级容灾和应用级容灾，业务级容灾的大部分内容是非IT系统。 数据级容灾系统只保证数据的完整性、可靠性和安全性，但提供实时服务的请求在灾难中会中断。应用级容灾系统能够提供不间断的应用服务，让服务请求能够透明(在灾难发生时毫无觉察)地继续运行，保证数据中心提供的服务完整、可靠、安全。因此对服务中断不太敏感的部分可以选择数据级容灾，以便节省成本，在数据级容灾的基础上构建应用级容灾系统，保证实时服务不间断运行，为用户提供更好的服务。 (1)数据级容灾。通过在异地建立一份数据复制的方式保证数据的安全性，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据。数据级容灾是容灾的基础形式，由于只需要考虑数据的复制和存放，不需要考虑备用系统，实现起来相对简单，投资也较少。数据级容灾需要考虑三方面问题:在线模式与离线模式问题;远程数据复制技术问题;同步与异步容灾问题。 (2)应用级容灾。应用级容灾能保证业务的连续性。在数据级容灾的基础上，建立备份的应用系统环境，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据和应用系统。 应用级容灾系统是建立在数据级容灾系统基础上的，同时能完成数据和应用系统环境的复制存放和管理。为实现发生灾难时的应用切换，容灾中心需要配置与工作系统同构和相同功能的业务网络、应用服务器、应用软件等。 应用级容灾还需要考虑数据复制的完全性、数据的一致性、数据的完整性、网络的通畅性、容灾切换的性能影响、应用软件的适应性改造等问题，以及为保证业务运行的所需设备、环境、人员及其相应的管理。 2.灾难恢复系统的在线/离线模式 (l)在线模式。在线灾难恢复系统要求工作系统与灾难备份系统通过网络线路连接，数据通过网络实时或定时从工作系统传输到灾难备份系统。对数据保护的实时性高，对业务连续性要求高，就需要采用在线模式。 (2)离线模式。离线灾难备份系统的数据通过存储介质(磁带、光盘等，搬运到异地保存起来实现数据的保护。离线模式适合于对数据保护的实时性要求不高的场合，离线模式设备比较简单，投资较少。 3.数据备份技术 正常情况下系统的各种应用在数据中心运行，数据存放在数据中心和灾难备份中心两地保存。当灾难发生时，使用备份数据对工作系统进行恢复或将应用切换到备份中心。灾难备份系统中数据备份技术的选择应符合数据恢复时间或系统切换时间满足业务连续性的要求。目前数据备份技术主要有如下几种: (1)磁带备份。 (2)基于应用程序的备份。通过应用程序或者中间件产品，将数据中心的数据复制到灾难备份中心。在正常情况下，数据中心的应用程序在将数据写入本地存储系统的同时将数据发送到灾难备份中心，灾难备份中心只在后台处理数据，当数据中心瘫痪时，由于灾难备份中心也存有生产数据，所以可以迅速接管业务。这种备份方式往往需要应用程序的修改，工作量比较大。另外，由应用程序本身来处理数据的复制任务，对应用系统的性能影响较大。 (3)数据库的远程数据复制。基本原理是将数据中心的数据库日志传送到远程灾难备份中心的数据库中，通过日志同步两端的数据库。这种方式需要数据库软件的支持。由于数据库方式只是传送数据库日志，与应用没有直接关系，因此无须对应用程序做大量修改。这种灾难备份方式比较适合于只对数据库有远程灾难备份需求，传输距离较长且网络传输带宽不大的用户环境。 (4)服务器逻辑卷的远程数据复制。这种方式在服务器操作系统逻辑卷管理软件基础上实现，通过IP网络将逻辑卷操作传输到异地主机，在异地主机执行同样的逻辑卷操作，保证本地和远端逻辑卷的一致性。这种灾难备份方式适合文件、数据库等多种数据的远程复制要求，并且对应用系统和数据库是透明的，但需要数据中心和灾难备份中心主机同构。 (5)基于存储备份软件实现的远程数据复制。数据的复制和同步通过存储备份软件实现，系统的灵活性很强，完全不依赖主机系统和存储系统，也不影响本地应用的响应速度，数据可以从任何存储设备上镜像到任何地点的任何存储设备上。 (6)基于智能存储设备的远程数据复制。由智能存储设备自身管理软件实现数据的远程复制，即智能存储设备将系统中的存储操作指令发送到远端的智能存储设备上，在远端智能存储设备中重做存储操作指令，实现数据远程复制。这种灾难备份方式要求数据中心和灾
数据中心灾备体系设计详细介绍与分析 2010-03-03 网络网络 数据中心灾备体系设计主要由三部分组成：灾备需求分析、灾备技术体系设计与灾备管理制度设计。灾备需求分析是根据数据中心的业务特点与系统特点，分析存在的风险；灾备技术体系设计则是为达到灾备需求的旧标而进行的具体技术实现；灾备管理制度设计则是为确保灾备系统规范运作而设立的管理制度。由于《规范》中对灾备管理制度的设计已经提出了比较明确的设计方法与要求，本文将不再赘述，而将重点放在介绍灾备需求分析与灾备技术体系设计方面，为相关工作的具体实施提供参考。 一、区域数据中心灾备需求分析 (一)风险分析 全面详尽的风险分析是数据中心灾备体系设计的基础，风险分析方法包括： 1．资产识别，主要包括：基础设施、硬件、软件、数据、文档、服务和声誉等。单位应对资产进行分类，以区分资产的不同重要程度并确定重要资产的范围，应X对资产进行标识以区分资产对业务正常运作的影响程度，据此确定资产的等级。 2．威胁识别，即识别信息资产构成潜在破坏的可能性因素，如自然因素与人为因素，内部因素与外部因素等。3．脆弱性识别，即识别可能被威胁利用的信息资产的弱点，主要包括技术与管理两个方面。技术脆弱性涉及物理层、网络层、系统层、应用层等各个层面的安全问题；管理脆弱性可分为技术管理脆弱性和组织管理脆弱性两方面，前者与具体技术活动相关，后者与管理环境相关。 具体分析活动可通过问卷调查、工具检测、人工核查、文档查阅和渗透性测试等方式开展。完成风险分析后，需要根据灾难发生的可能性、灾难发生后的损失预计等因素，计算对应的风险值，进行风险分级，为后续分析工作提供参考。
本地数据备份及异地数据级灾备项目建设方案
XX地税本地数据备份及异地数据级 灾备项目建设方
一、数据备份及异地灾备系统项目分析 随着国家经济从计划经济向市场经济发展步伐的不断加快，西部大开发的政策也促使中西部地区的经济蓬勃发展，在这种情况下，作为国家对市场经济发展进行有效调控的一种重要手段，税收管理日益呈现出了其在当今经济生活中的重要性和权威性。因此在各种与经济发展相关的税收信息越来越多元化，海量化的发展的同时，传统的人工处理方式已经越来越不适合当前经济发展的需要了，而计算机信息技术的发展又为税务信息化工作提供了强有力的支持。目前作为西部经济发展最迅速省份之一的陕西省的地税系统，必定需要一个非常强大的税务信息系统的有效支撑，同时随着税务信息处理系统的建成投入使用，我们又必须面对更严峻的考验，那就是如何科学、安全、有效地保护税务信息系统中的海量化税收信息数据。 我省税务信息系统按照“秦税工程”方案于3月份完成了对省地税集中数据中心系统的搭建。数据大集中处理是今后发展的一种趋势，一方面有利于对税收业务系统进行统一规划管理，让全省所有分支机构采用统一的业务系统平台，减少管理漏洞；另一方面利于省地税对数据信息的统一管理，可以更好的利用和保护这些核心业务数据；同时也可以减少各地的信息化重复建设费用。 伴随着我省地税信息系统的数据集中处理模式，可以预计，税务系统的业务运作、经营管理将越来越依赖于数据中心各业务信息系统
的可靠运行。我中心所提供的税务系统服务的连续性以及业务数据的完整性、正确性、有效性都会直接关系到全省地税系统的生产、经营和决策活动。一旦因自然灾害、设备故障或人为因素等原因引起计算机系统停顿导致信息数据丢失和业务处理中断，将会给我省税务部门造成巨大的经济损失和声誉损害，甚至是税务数据的致命打击！ 在数据大集中的模式下，我们也必须处理因数据集中处理也伴随而来一些不得不面对的运行风险，如：这些集中的数据会因为一些突然发生的灾难而造成破坏或者永久性的损失。同时，这些生产运行主机系统及其配套设备一旦发生灾难性破坏，就会导致税收业务中断，这对于我们来说将是灾难性的打击，因此，我省税务生产业务系统的灾难备份及恢复系统就显得格外重要！
1.数据中心容灾备份解决方案 随着社会的发展和科技的进步，政府日常工作越来越依赖于数据处理来进行，政务系统的连续性依赖于数据中心系统的稳定运行。然而，灾难就像灰尘一样伏击在运营环境周围，政务系统的数据中心可能正在一个充满风险和威胁的环境下运行。如果不能对这些风险采取有效治理，一旦数据由于某种原因丢失，就很有可能对政府的日常工作造成严重的影响。如果核心数据丢失，将会使得某些核心功能陷入瘫痪，造成不可估量的损失。因此，保证政务的连续性和数据的高可靠性和可用性，已经成为政府部门在数据中心建设中，必须要考虑的问题。 1.1灾备解决方案原则 首先，在制定容灾系统方案的过程中要考虑的就是容灾系统建设对原有业务系统带来的影响。比如，采用数据复制技术对系统I/O带来的延迟，应用数据同步对日常业务处理系统带来的压力等。因此，企业要通过周密的测试和分析来规避容灾系统建设时带来的这些风险，以保证业务系统不会因容灾系统的建设而出现在处理性能上下降的问题。 第二，数据状态要保持同步。为保证在灾难发生时，业务可以成功地切换到备份中心，就必须保证容灾系统数据同步机制的可靠性。因此，建立可靠的数据同步校验机制是必须的; 同时，还要考虑建立定时的、自动的数据同步核查对比机制，以检验两个中心数据的一致性，这是数据容灾工作中非常重要的一部分。 第三，容灾系统的日常维护工作要尽可能轻，并能承担部分业务处理和测试的工作。容灾系统的维护和管理是容灾切换成功的重要保证，在系统建设中，就必须要考虑系统的维护管理流程。生产中心任何业务处理过程的改变都必须完整地复制到备份中心; 所有新业务系统上线时，必须通知备份中心，并在备份中心配置好数据同步机制; 对原程序的改动也必须保证两个中心同时上线。 第四，系统恢复时间要尽可能短。容灾系统主要是为了实现在主中心系统发生灾难时，可以在规定时间切换到备份中心，保证数据不会丢失，并且继续向用户提供服务。但往往在灾难发生时，主要技术人员不能及时到达现场，为了顺利实现系统间的切换，应该让系统切换操作尽可能地简单; 并建立固定化的、标准化的切换流程，要求维护人员在切换演习时严格按照流程的指导步骤进行操作。 第五，可实现部分业务子系统的切换和回切。当人事变动、业务变化、IT设施变化以及其 他可能引起恢复规划文档失效的变化发生时，应及时更新各恢复规划文档，并在必要时启动模拟测试或演习，确保业务连续性系统的工作能力。 第六，技术方案选择要遵循成熟稳定、高可靠性、可扩展性、透明性的原则。目前，国际上比较成熟的容灾技术包括：SAN/NAS技术、远程镜像技术、虚拟存储、基于IP的SAN互连技术以及快照技术等。其中基于IP的SAN远程数据容灾备份技术应用比较广泛，其是利用基于IP的SAN的互连协议，将主数据中心SAN中的信息通过现有的TCP/IP网络，远程复制到备份中心的SAN中的。当备份中心存储的数据量过大时，可利用快照技术将其备份
数据保护系统 医院备份、容灾及归档数据容灾 解决方案
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 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。
数据中心灾备系统的分类 来源：机房360 作者：林小村更新时间：2010/11/19 11:50:11 摘要：本文为大家讲述数据中心的一些技术知识，具体为您讲述数据 中心灾备系统的分类情况。 根据数据中心的安全要求，应对灾难恢复系统采用的技术路线做出全面的考虑。 1.数据级容灾和应用级容灾 按照容灾系统对应用系统的保护程度可以分为数据级容灾和应用级容灾，业务级容灾的大部分内容是非IT系统。 数据级容灾系统只保证数据的完整性、可靠性和安全性，但提供实时服务的请求在灾难中会中断。应用级容灾系统能够提供不间断的应用服务，让服务请求能够透明(在灾难发生时毫无觉察)地继续运行，保证数据中心提供的服务完整、可靠、安全。因此对服务中断不太敏感的部分可以选择数据级容灾，以便节省成本，在数据级容灾的基础上构建应用级容灾系统，保证实时服务不间断运行，为用户提供更好的服务。 (1)数据级容灾。通过在异地建立一份数据复制的方式保证数据的安全性，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据。数据级容灾是容灾的基础形式，由于只需要考虑数据的复制和存放，不需要考虑备用系统，实现起来相对简单，投资也较少。数据级容灾需要考虑三方面问题:在线模式与离线模式问题;远程
数据复制技术问题;同步与异步容灾问题。 (2)应用级容灾。应用级容灾能保证业务的连续性。在数据级容灾的基础上，建立备份的应用系统环境，当本地工作系统出现不可恢复的物理故障时，容灾系统提供可用的数据和应用系统。 应用级容灾系统是建立在数据级容灾系统基础上的，同时能完成数据和应用系统环境的复制存放和管理。为实现发生灾难时的应用切换，容灾中心需要配置与工作系统同构和相同功能的业务网络、应用服务器、应用软件等。 应用级容灾还需要考虑数据复制的完全性、数据的一致性、数据的完整性、网络的通畅性、容灾切换的性能影响、应用软件的适应性改造等问题，以及为保证业务运行的所需设备、环境、人员及其相应的管理。 2.灾难恢复系统的在线/离线模式 (l)在线模式。在线灾难恢复系统要求工作系统与灾难备份系统通过网络线路连接，数据通过网络实时或定时从工作系统传输到灾难备份系统。对数据保护的实时性高，对业务连续性要求高，就需要采用在线模式。 (2)离线模式。离线灾难备份系统的数据通过存储介质(磁带、光盘等，搬运到异地保存起来实现数据的保护。离线模式适合于对数据保护的实时性要求不高的场合，离线模式设备比较简单，投资较少。 3.数据备份技术 正常情况下系统的各种应用在数据中心运行，数据存放在数据中
银行应用级灾备建设方案
目录 1项目背景及建设需求 (3) 2各系统数据备份概况 (4) 3灾备端应用部署规划 (5) 4灾备网络通信系统 (7) 5各业务系统应用级部署工作计划 (8) 6各业务系统应用部署工作分解 (9) 6.1系统部署 (9) 6.1.1AIX平台 (9) 6.1.2虚拟机平台 (9) 6.2FTP环境构建 (10) 6.3系统验证 (11) 6.3.1验证前准备 (11) 6.3.2单系统验证 (15) 6.3.3系统集成验证 (16) 7项目主要风险点 (17)
1项目背景及建设需求 目前，我行灾备项目已完成核心业务域和城商业务域数据级同城备份，通过两台IBM中端磁盘阵列实现了两大业务域关键数据从生产中心到灾备中心的同城复制。其中： ?DS5100承载ESB、加密平台、图形前端数据库三个系统数据复制，未实现数 整报表系统的数据复制 ?DS5020承载PCSP（综合前置）、ATMP、虚拟化平台数据复制，未实现财务 系统（NC）数据复制 按山东省银监局相关要求：2013年三季度，需要完成国际结算、信贷、图形前端、票据、手机银行、NC、ATMP、数整报表、加密平台、综合前置、ESB等十一个重要业务系统的应用级灾备建设。
2各系统数据备份概况 十一个业务系统数据存储及异地备份概况统计如下表： 从上表可知，ESB、加密平台、图形前端、ATMP、综合前置（PCSP）等五个系统数据通过磁盘阵列实时复制到灾备端，数整报表、国际结算、信贷、票据、手机银行、财务系统等六个系统数据则通过每日全备、定时FTP传送至灾备端。
3灾备端应用部署规划 目前，灾备中心网络链路已就绪，各业务系统应用服务器硬件已完成上架、加电测试等相关工作。各系统部署规划如下表： 系统名称系统平台数据库应用灾备端服务器配置 ESB AIX6100-07 DB2 9.1 P740一台 加密平台AIX6100-07 P720一台 SQLServer 虚拟机 图形前端Windows2008 2008 ATMP AIX5300-12 Oracle10g P720一台 综合前置AIX6100-07 P720一台 数整报表AIX6100-07 DB2 9.1 P740一台 国际结算Windows2003 虚拟机 信贷系统Windows2003 虚拟机 票据系统SLES10 虚拟机 手机银行SLES11 虚拟机 财务系统 AIX5300-12 P720一台 （NC）
省电子政务应急灾备中心 某市分中心 项目建议书
目录 第1章项目概述................................................................................................................ - 4 - 1.1项目名称 (4) 1.2项目概况 (4) 1.3主要结论和建议 (4) 第2章项目建设的必要性 ................................................................................................. - 5 - 2.1某省电子政务外网概述 (5) 2.2某省电子政务灾备系统现状及问题 (5) 2.3项目建设必要性 (6) 第3章项目需求分析 ........................................................................................................ - 7 - 3.1业务承载范围需求 (7) 3.2网络需求 (7) 3.3存储容量需求 (7) 3.4分险防控需求 (7) 3.5容灾系统能力需求 (8) 3.5.1 容灾系统的容灾对象.................................................................................................- 8 - 3.5.2 信息系统灾难恢复目标RPO与RTO ........................................................................- 9 - 3.5.3 标准灾难恢复能力等级体系.....................................................................................- 9 - 3.5.4 信息系统灾难恢复目标与灾难恢复能力等级体系的关系.................................. - 10 - 3.5.5 容灾系统能力需求分析.......................................................................................... - 11 - 第4章总体设计.............................................................................................................. - 12 - 4.1建设思路 (12) 4.2建设原则 (12) 4.3建设目标 (13) 4.3.1 近期目标.................................................................................................................. - 13 - 4.3.2 中远期目标.............................................................................................................. - 13 -4.4总体架构.. (14) 第5章容灾系统解决方案 ............................................................................................... - 15 - 5.1灾备中心架构概述 (15) 5.2灾备云平台建设 (18) 5.2.1 灾备网络建设.......................................................................................................... - 18 - 5.2.2 灾备云平台建设...................................................................................................... - 19 -5.3信息与网络安全建设 (22) 5.3.1管理层面................................................................................................................... - 22 -
目录 一、需求分析 (2) 1.1 数据连续性面临挑战 (2) 1.2 需求分析 (4) 二、技术方案 (6) 2.1 方案一.数据集中保护建设方案 (6) 2.1.1方案设计 (6) 2.1.2方案说明 (6) 2.2 方案二.业务系统应用容灾及集中保护平台建设方案 (9) 2.2.1方案设计 (9) 2.2.2方案说明 (10) 三、方案优势及技术说明 (13) 3.1 方案优势 (13) 3.1.1契合安全等级保护三级的建设 (13) 3.1.2业务连续性保障 (18) 3.1.3成本可控 (18) 3.1.4混合IT数据保护 (18) 3.1.5降低成本投入&最大化提高投资回报率 (18) 3.1.6极简化的数据保护系统 (19) 3.2 爱数备份柜数据保护技术 (19) 3.2.1 源端重复数据删除技术 (22) 3.2.2 虚拟化平台备份 (23) 3.2.3 LAN-free备份 (27) 3.2.4 远程复制（D2D2R） (28) 3.2.5 Oracle多通道备份等高级备份功能 (31) 3.2.6 操作系统备份与恢复 (33)
一、需求分析 1.1 数据连续性面临挑战 如何保证计算机系统连续不断的运行，保护企业中最宝贵的数据资产，成为其稳定发展的关键。随着信息化建设的不断发展和完善，济康医药连锁有限公司不仅完成从IT基础设施到IT应用的过渡，而且即将搭建统一的数据平台。信息化办公使得工作人员的办公效率得到了很大的提高，同时为大家的协同工作也做到了高效和便捷。为更好地服务于贵单位用户，将会有越来越多的关键业务集中于计算机系统中，能否提供一个高可靠性和高可用性的信息服务成为衡量服务质量的一个重要指标，因此整个计算机信息化系统的安全可靠地运行将直接关系到贵单位的生产和未来的发展。而实际上，计算机信息系统时刻受到来自自然灾害、人为因素、供电、病毒、黑客攻击等各方面的破坏和侵袭、因此，具备快捷方便的数据备份、灾难恢复和数据恢复功能是现今系统网络管理的重要目标。 风险分析的目的是针对当前核心业务流程，系统环境和所存在的潜在风险确定系统可恢复能力级别，确定当前业务环境中的客观存在
灾备流程 》》灾备切换 整个切换过程分切换准备和正式切换两步。 ●切换准备 用户以电话方式告知解密密码后，需要进行切换前的状态检查工作，包括： ◆用户真实交易网管是否已经关闭（灾备中心询问，客户检查并得到灾备中心确认）； ◆灾备中心是否还有灾备运行机给予切换（灾备中心检查）； ◆灾备中心是否可以连通交易所（灾备中心检查）； ◆用户信息是否齐全（灾备中心检查）。 ●正式切换 在用户提供正式切换密码并完成上一步所有操作（是否完成需要灾备中心人员确认）后，即可由灾备中心通过管理程序进行正式切换： ◆根据用户号，读取用户的相关信息，如该用户的版本信息。 ◆分配一组灾备运行机。 ◆数据准备。 ◆调用“灾备数据恢复模块”启用灾备运行机。 ◆当日交易完成，调用“柜台环境复原模块”复原灾备运行机。 ②期货经纪公司的操作流程 ◆发生灾难或其他重大事故 ◆判定本地已经无法维持正常交易 ◆通过电话通知共享灾备中心进行切换操作（分两步）。 切换准备：告知灾备中心加密密码，确认主交易系统已经关闭； 正式切换：检查确认所有切换准备工作，告知灾备切换密码并经灾备中心确认后实施切换。 ◆当共享灾备中心完成切换以后，自己先检验数据是否正确，否则要求中心重导数据。 ◆发布消息，通知客户和营业部连接灾备中心的托管网关。 ◆进行正常交易 ◆盘后尽快恢复自己的交易系统
③切换后状态图 1），RAID-Based基于磁盘阵列的容错方式 一）、RAID是单点故障解决的标准方案。常见结构为RAID5。在RAID5+多盘热备的基础上，同时考虑冗余电源、先进冷却系统、HBA、双主动/主动RAID控制卡，以及符合SAF －TE监控标准的机架，将会使数据从存储系统到服务器的路径都得到完全保护。 二）、其他关注的焦点，应当转向服务器应用系统的保护。同样，可以在服务器系统上应用RAID1。 具备以上两点，存储系统就已具备完整的容错和恢复能力。 三）、硬件或软件 1、服务器6台，配置RAID1 2、RAID5+多盘热备+SCSI热插拨+冗余电源+冷却系统+ HBA+双主动/主动RAID控制卡 3、Win2003 + 应用程序 4、RAID阵列数据恢复专用软件（东智） 优点 1、服务器RAID1有效避免由于应用程序自身缺陷导致系统全部宕机，故障发生后可快速恢复系统应用。 2、数据全部存贮在磁盘阵列柜中，如果出现单盘故障时，热备盘可以接替故障盘，进行RAID 重建。理论上，RAID5+多盘热备可以支持多点单盘故障。 3、通过冗余电源、冷却系统、HBA、双主动/主动RAID控制卡，以及符合SAF－TE监控标准的机架，可以实现数据从存储系统到服务器的路径都得到完全保护。 缺点 虽然有效避免单点或多点故障，但在选配这种方案时，需要选用一个品质与售后服务较好的硬件和软件产品。因此成本较高。
目录 一、需求分析 ................................................................................................................. 1.1 数据连续性面临挑战 1.2 需求分析 二、技术方案 ................................................................................................................. 2.1 方案一.数据集中保护建设方案 2.1.1方案设计 2.1.2方案说明 2.2 方案二.业务系统应用容灾及集中保护平台建设方案 2.2.1方案设计 2.2.2方案说明 三、方案优势及技术说明 ........................................................................................... 3.1 方案优势 3.1.1契合安全等级保护三级的建设 3.1.2业务连续性保障 3.1.3成本可控 3.1.4混合IT数据保护 3.1.5降低成本投入&最大化提高投资回报率 3.1.6极简化的数据保护系统 3.2 爱数备份柜数据保护技术 3.2.1 源端重复数据删除技术 3.2.2 虚拟化平台备份 3.2.3 LAN-free备份 3.2.4 远程复制（D2D2R） 3.2.5 Oracle多通道备份等高级备份功能 3.2.6 操作系统备份与恢复 一、需求分析 1.1 数据连续性面临挑战 如何保证计算机系统连续不断的运行，保护企业中最宝贵的数据资产，成为其稳定发展的关键。随着信息化建设的不断发展和完善，济康
数据中心容灾备份方案 Company number：【WTUT-WT88Y-W8BBGB-BWYTT-19998】
数据保护系统 医院备份、容灾及归档数据容灾 解决方案 1、前言 在医院信息化建设中，HIS、PACS、RIS、LIS 等临床信息系统得到广泛应用。医院信息化 HIS、LIS 和 PACS 等系统是目前各个医院的核心业务系统，承担了病人诊疗信息、行政管理信息、检验信息的录入、查询及监控等工作，任何的系统停机或数据丢失轻则降低患者的满意度、医院的信誉丢失，重则引起医患纠纷、法律问题或社会问题。为了保证各业务系统的高可用性，必须针对核心系统建立数据安全保护，做到“不停、不丢、可追查”，以确保核心业务系统得到全面保护。 随着电子病历新规在 4 月 1 日的正式施行，《电子病历应用管理规范（试行）》要求电子病历的书写、存储、使用和封存等均需按相关规定进行，根据规范，门(急)诊电子病历由医疗机构保管的，保存时间自患者最后一次就诊之日起不少于 15 年；住院电子病历保存时间自患者最后一次出院之日起不少于30 年。
2、医院备份、容灾及归档解决方案 针对医疗卫生行业的特点和医院信息化建设中的主要应用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于数据保护系统的多种解决方案，以达到对医院信息化系统提供全面的保护以及核心应用系统的异地备份容灾 数据备份解决方案 针对于医院的 HIS、PACS、LIS 等服务器进行数据备份时，数据保护系统的备份架构采用三层构架。 备份软件主控层（内置一体机）：负责管理制定全域内的备份策略和跟踪客户端的备份，能够管理磁盘空间和磁带库库及光盘库，实现多个客户端的数据备份。备份软件主服务器是备份域内集中管理的核心。 客户端层（数据库和操作系统客户端）：其他应用服务器和数据库服务器安装备份软件标准客户端,通过这个客户端完成每台服务器的 LAN 或 LAN-FREE 备份工作。另外，为包含数据库的客户端安装数据库代理程序，从而保证数据库的在线热备份。