异地备份与恢复方案研究与实验Word格式.docx
《异地备份与恢复方案研究与实验Word格式.docx》由会员分享，可在线阅读，更多相关《异地备份与恢复方案研究与实验Word格式.docx（126页珍藏版）》请在冰豆网上搜索。
近年来，数据大集中已经成为我国企业信息化建设的趋势。
伴随着数据大集中的实现，企业数据中心的技术风险也相对集中。
一旦数据中心发生灾难，则将导致企业所有分支机构、营业网点和全部的业务处理停顿，或造成客户重要数据的丢失，其后果不堪设想。
如何防范技术风险，确保数据安全和业务的连续性，已是企业急需面对的课题，而建立异地备份与恢复机制则是解决上述问题的一道良方。
1.2国内外研究现状
异地灾难备份是随着信息化的日益推进而逐渐凸现其重要作用，信息化发展的越早，对信息化依赖程度越高的国家，接受的网络攻击和恐怖事件也往往越频繁，造成的损失和社会影响就越大，这使得其在灾难备份上积累来非常宝贵的经验。
美国的异地灾难备份应用和市场起步于上个世纪70年代末期，上世纪80年代和90年代已经形成了系列相关的制度和准则，而2001年“9.11事件”以后，更是引起了包括美国在内的西方国家的广泛重视。
美国的证监委和联邦处都发布了白皮书，限定了它们的金融部门灾备能力到位的时间表，要求在1～3年之内全部到位；
美国政府计划也对政府容灾能力提出了要求，比如说要求政府在灾难的情况下保护自己的信息系统，要求它最短的恢复时间不要大于12小时，而且这种灾备能力要能够维持到一个月。
其他的国家，如英国、新加坡、德国等，灾“9.11事件”以后，财政部门对自己的金融管理系统提出了要求。
全球有70％以上的发达国家在政府和金融等敏感领域，都在策划和实施灾备系统。
金融界巨头摩根－斯坦利公司，在世贸大厦租有25层，惨剧发生时，2000多名员工正在楼内办公。
正当很多人痛惜摩根－斯坦利将成为这一恐怖事件的殉葬品时，该公司竟然宣布全球营业部第二天就能照常工作。
摩根－斯坦利公司奇迹般地劫后复苏，归功于它不仅像一般公司那样在内部进行数据备份，而且在新泽西州建立了异地灾备中心和有效的灾难恢复计划。
作为世界领先的全球金融服务机构之一的澳大利亚大通-曼哈顿银行，其灾备方案就是一个较为典型的例子。
澳大利亚大通-曼哈顿银行的全球灾备系统有五个灾难备份中心，包括三个全球同城灾备中心，两个全球异地灾备中心。
位于澳大利亚的同城灾备中心距离生产中心约30公里，两个中心使用两条高速的ATM通讯链路连接。
银行所有的重要数据均在同城灾备中心的服务器上作镜像，同时，大通-曼哈顿银行在英国的全球备份中心对数据进行异地备份。
与境外比起来，中国的灾难备份建设起步较晚，但是如何充分调动和发挥各方面的积极性，全面提高抵御灾难打击能力和灾难恢复能力，已经引起了国内有关政府及行业主管部门和信息化依赖程度较高的大中型企业的高度重视。
人民银行总行在2002年8月30日下发的《中国人民银行关于加强银行数据集中安全工作的指导意见》中明确规定：
“为保障银行业务的连续性，确保银行稳健运行，实施数据集中的银行必须建立相应的灾难备份中心。
数据集中初期的灾难备份必须能支持信息通过通信网络从生产中心到备份中心的电子传送。
数据集中两年内必须实现备份中心与生产中心相互镜像，支持双向恢复，保证数据一致性。
”
2003年8月，中共中央办公厅、国务院办公厅转发的《国家信息化领导小组关于加强信息安全保障工作的意见》，以及2004年1月初召开的国家信息安全工作会议都明确提出了在重要信息系统领域要加强灾难备份的工作。
并明确指出灾难备份是构建我国信息安全保障体系的重要组成部分。
中国工商银行自从承担《银行计算机灾难恢复系统研究》项目后，以其雄厚的技术实力和有效的组织规划，在国内率先启动了数据集中工程和灾难恢复的建设，数据中心（北京）的灾难备份与恢复系统在国内采用最先进灾难备份与恢复技术，不仅实现数据中心（北京）所辖21个分行的业务数据、主机、网络、应用的备份和业务级的灾难恢复功能，大大提高了工商银行数据中心生产系统的可用性和安全性，还实现了两个数据中心互为备份。
根据国际上SHARE78标准定义的异地恢复任务分类，达到了五级的灾难备份恢复水平。
而兴业银行应该算是走在信息化前沿的城市商业银行，兴业银行于2001年底完成了全行数据大集中工作，同时基于大集中的框架进行来IT组织架构的重组，成功推出新一代核心业务处理系统，并在福州、上海构建了两个互为备份的现代化数据运行中心，建成了远程容灾系统，是国内同业中首家具有远程灾难备份能力的银行，成为国内率先真正实现365天24小时不间断提供服务的商业银行。
1.3广东邮政省中心数据备份现状
我省邮政信息系统正由原来的分布式逐步走向集中式，并且随着邮政业务的不断发展，我省邮政信息系统中的子系统越来越多，数据量也越来越庞大，人工对系统的保护和人工对数据的防灾越来越显得重要。
我省邮政信息系统属于24X7的关键业务系统，需要不间断为用户提供服务，因此如何对存储数据进行有效管理，如何保证存储数据的安全性，已经成为迫在眉睫的问题。
目前我省邮政信息系统中仍有部分系统没有实施数据备份策略；
或者有做数据备份，但没有做到异地存放；
或者有做到异地备份，但无法保证数据能够恢复到最新状态。
以上情况使数据在安全方面都存在很大的隐患。
附录一的表格是对我省邮政省中心信息网中的一些关键系统的数据备份现状的总结。
1.4研究内容
本项目通过对广东邮政省中心信息系统中所使用到的各种数据库，进行异地备份与恢复方法的研究与实验，然后提出了适合广东邮政省中心信息网实际情况的异地备份解决方案，从而实现数据的安全和业务的连续，提高了广东邮政省中心系统的容灾能力。
2异地备份与恢复的研究
2.1基于存储系统的点对点拷贝技术
2.1.1原理
磁带拷贝进行数据备份和恢复是最常见的传统灾难备份方式，但这种方式无法满足在灾难发生时能够快速切换的要求。
基于存储系统的点对点拷贝数据级容灾解决方案，是利用存储设备控制器中嵌入的远程复制功能，配合数据复制软件、卷管理软件，在相同存储子系统之间进行数据复制。
在运行中心和容灾中心安装相同的存储子系统，使用安装在存储子系统上的数据复制软件，可以实现生产中心和灾难备份中心的数据的实时拷贝维护能力。
保持运行系统的存储数据逻辑卷与备份系统存储数据逻辑卷的一致性。
这种解决方案可以不依赖于应用而靠大量的硬件技术来实现。
2.1.2实现方式概述
目前业界有两种基本的基于磁盘系统的远程拷贝形式：
同步点对点远程拷贝（SynchronousWrites）：
来自主机的数据被写往本地连接的磁盘系统，该系统将数据转发给远地连接的磁盘系统。
只有当两个系统都拥有数据的拷贝以后，本地系统才会向主机返回一个I/O完成指示。
同步远程拷贝能够在远地提供最新的数据，但应用程序会因等待写I/O操作的完成而被延迟。
由于距离的限制这种方式也叫做“同城镜像（MetroMirror）”。
如下图所示：
图2-1同城镜像工作示意图
异步点对点远程拷贝（AsynchronousWrite）：
来自主机的数据被写往本地连接的磁盘系统，该系统立即向主机返回一个I/O完成指示。
数据在很短的一段时间（在实际中通常在数秒钟到一分钟左右）以后被送往一个远程磁盘系统。
异步远程拷贝对应用程序性能的影响最小，但远程磁盘系统在数据的更新程度上与本地系统相比会有一个延迟。
图2-2异步点对点远程拷贝工作示意图
单纯的异步拷贝由于线路距离较远等原因，本地磁盘和远地磁盘可能会有逻辑卷读写顺序上的差异。
这种方式也叫做“全局拷贝（GlobalCopy）”
在全局拷贝（GlobalCopy）的情况下，比如本地磁盘系统提供给主机5个逻辑卷，某一时刻主机对这些逻辑卷发起了A，B，C，D，E，5个写盘请求，本地的磁盘系统的写顺序是A，B，C，D，E。
但是由于线路等原因，远地的磁盘系统在接收写请求时，收到的顺序可能是A，C，B，D，E。
写盘的顺序也是A，C，B，D，E。
我们假设灾难发生在这5个写操作B，D的中间部分，那么这时远地的数据C是没有意义的。
为了解决本地磁盘和远地磁盘可能存在的逻辑卷读写顺序的差异，有的磁盘系统提供带有一致性组的异步远程数据拷贝。
在这种方式下，远地的磁盘系统会将先收到的写请求缓存起来（比如上面的数据C），等到它前面的数据（A,B）到达后，再按照顺序写盘。
这种方式也叫做“全局镜像（GlobalMirror）”。
图2-3全局镜像工作示意图
2.1.3优缺点分析
这种方案具有以下优点：
●“同城同步方式”和“远地异步方式”对系统性能影响很小。
●数据实时性较好。
●与采用何种数据库无关。
这种方案具有以下缺点：
●两边的存储设备必须是同构的。
●对线路带宽的要求通常也较高。
●灾难发生时，可能导致容灾中心数据不一致，严重时有可能造成数据库无法启动。
●由于数据库、应用系统不处在就绪状态，切换时间较长。
2.2基于ORACLE的数据库
2.2.1DATAGUARD技术
2.2.1.1原理
在生产中心和容灾中心采用相同的数据库，生产中心为主数据库，容灾中心为备用数据库。
在修改主数据库时，对主数据库更改而生成的更新数据即发送到物理备用数据库。
这些更改可以应用到运行于管理恢复模式下的备用数据库。
当主数据库打开并处于活动状态时，备用数据库要么执行恢复操作，要么只读方式打开进行报表访问。
如果主数据库出现了故障，备用数据库即可以被激活并接管生产数据库的工作。
2.2.1.2实现方式概述
备用数据库可以是物理备用数据库，也可以是逻辑备用数据库。
物理备用数据库具有与主数据库完全相同的物理结构，它通过接收主数据库日志并应用日志的方式与主数据库保持同步。
物理备用数据库在应用日志时，是基于数据块级别来进行。
因此，要求备用数据库和主数据库具有相同的物理结构，而且备用数据库只能处在恢复状态和只读打开两种状态中的一种。
逻辑备用数据库与主数据库只要求逻辑结构相同，物理结构可以不同，它通过接收主数据库的日志，并转化为SQL语句，在备用数据库中运行的方式，与主数据库保持同步。
逻辑数据库除了用于灾难恢复之外，也可以用于其他的用途，它允许用户根据需要随时进行查询以及随时生成报表，还可以建立自己的数据库对象，进行读写操作。
DATAGUARD的实现方式如下图所示：
图2-4DATAGUARD工作示意图
基于数据库的容灾支持三种模式：
（1）最大保护模式
最大保护模式为主数据库提供最高级别的数据可用性。
它保证在主数据库提交的事务可在备用数据库恢复并可用。
当所有的备用数据库都不可用时，主数据库的处理会自动挂起，保证主数据库和备用数据库之间不会出现不一致。
在以最大保护模式运行时，日志写进程负责将日志记录从主数据库传送到备用数据库，在没有得到传送数据已在备用数据库可用之前，主数据库的事务不会提交。
这会在某种程度上影响主数据库的性能，但最大程度地保护了数据的一致性。
当主数据库出现故障时，因为所有在主数据库提交的事务都已在备用数据库同步，所以不会有数据丢失。
（2）最高可用模式
最高可用模式也为主数据库提供了高级别的保护，同最大保护模式相比，当备用数据库不可用时，主数据库不会挂起，而是降为最大性能模式。
由于主数据库仍在继续运行，主数据库和备用数据库之间会出现数据不一致的情况。
这种模式也是一种同步模式，日志写进程负责将日志记录从主数据库传送到备用数据库，在没有得到传送数据已在备用数据库可用之前，主数据库的事务不会提交。
（3）最大性能模式
最大性能模式是缺省的保护模式，它是一种异步模式。
在正常操作过程中，主数据库不会确认数据是否已经在备用数据库可用，就继续进行本地操作。
如果备用数据库出现故障，主数据库的处理也不会挂起，因此它对主数据库的性能影响很小。
2.2.1.3优缺点分析
●对存储设备没有同构的要求。
●有利于在灾难发生时，备用数据库系统的快速就绪。
●比较节省投资。
●最大保护和最高可用模式，在灾难发生时能够保证数据的不丢失，但对系统资源具有很高的占用；
而最大性能模式在灾难发生时，具有数据丢失的可能性。
●要求主数据库和备用数据库的操作系统和数据库版本的一致。
2.2.2RMAN技术
2.2.2.1原理
恢复管理器（RMAN）是一种用于备份（backup）、还原（restore）和恢复（recover）数据库的Oracle应用工具，能够提供DBA针对企业数据库备份与恢复操作的集中控制。
RMAN保留一个在注册数据库上进行过的备份与恢复操作的索引。
如果创建了恢复目录，RMAN既可以将备份记录保存在各自目标数据库的控制文件中，也可以将备份记录保存在恢复目录中。
实际的物理备份拷贝将被存储在指定的存储系统上，可以是磁带或磁盘。
RMAN将全部备份数据以Oracle特有的格式写入称为“备份片”的文件中，该文件只能通过RMAN应用工具读取。
没有其他应用能够使用RMAN备份集完成恢复任务。
如果用户想备份到磁带上，需要安装、配置并与Oracle集成的一套标准介质管理器，例如veritas的NetBackup和HP的DataProtector。
每条RMAN备份命令的执行都要产生一个备份集，这是一个或多个物理文件的逻辑分组，称为备份片。
RMAN是块级别的备份与恢复，备份与恢复发生在数据库块级别，可以通过比较数据块而获得一致性的数据块，可以避免备份没有用过的块，可以检验块是否损坏等块级别的问题。
2.2.2.2实现方式概述
RMAN的系统结构如下图表示：
图2-5RMAN的体系结构图
组成以上RMAN的结构说明如下：
（1）RMAN工具
也就是RMAN命令集，可以通过运行rman这个命令来启动RMAN工具，提供备份与恢复的接口。
（2）服务进程
RMAN的服务进程是一个后台进程，用于与RMAN工具与数据库之间的通信，也用于RMAN工具与磁盘/磁带等I/O设置之间的通信，服务进程负责备份与恢复的所有工作，当连接到目标数据库或分配一个新的通道时会产生一个服务进程。
（3）通道
通道是服务进程与I/O设备之前读写的途径，一个通道将对应一个服务进程，在分配通道时，需要考虑I/O设备的类型，I/O并发处理的能力，I/O设备能创建的文件的大小，数据库文件最大的读速率，最大的打开文件数目等因素
（4）目标数据库
就是RMAN进行备份与恢复的数据库，RMAN可以备份除了联机日志，pfile，密码文件之外的数据文件，控制文件，归档日志，spfile
（5）恢复目录
用来保存备份与恢复信息的一个数据库，一般不要创建在目标数据库上，利用恢复目录可以同时管理多个目标数据库，存储更多的备份信息，可以存储备份脚本。
如果不采用恢复目录，可以采用控制文件来代替恢复目录，oracle9i因为控制文件自动备份的功能，利用控制文件很大程度上可以取代恢复目录。
（6）媒体管理层
MediaManagementLayer（MML）是第三方工具或软件，用于管理对磁带的读写与文件的跟踪管理。
若要直接通过RMAN备份到磁带上，就必须配置媒体管理层，媒体管理层的工具如备份软件可以调用RMAN来进行备份与恢复。
（7）备份，备份集与备份片
RMAN的备份是以备份集与备份片的形式保存的。
备份集是一个逻辑结构，包含一组的物理文件。
这些物理文件就是对应的备份片。
备份片是最基本的物理结构，可以产生在磁盘或者磁带上，可以包含目标数据库的数据文件，控制文件，归档日志与spfile文件。
一个数据文件不能跨越一个备份集，但是能跨越备份片文件，控制文件能保存在同样的备份集上，但是不能与归档日志保存在同样的备份集上。
RMAN能够备份整个数据库或数据库部件，如表空间、数据文件、控制文件、归档文件以及Spfile参数文件，还可以进行增量数据块级别的备份，增量RMAN备份是时间和空间有效的，因为RMAN只备份自上次备份以来发生过变化的数据块。
RMAN同时也提供了其它更多功能，如数据库的克隆、采用RMAN建立备用数据库、利用RMAN备份与移动裸设备（RAW）上的文件等工作将变得更方便简单。
RMAN通过增强的自动配置与管理功能，以及特有的块级别的恢复，将使备份与恢复工作变得更加快捷。
2.2.2.3优缺点分析
●RMAN不需要用户干预，记录追踪在数据库上执行的全部备份与恢复操作，因而避免了在执行备份与恢复操作期间出现的人为错误。
●可以有效地用RMAN管理企业数据库间的集中备份与恢复过程。
●它支持增量备份。
●它有能力识别损坏的数据块。
●它能够反复核对并确保备份文件完整无缺。
例如，可以使用reportneedbackup命令验证所需的备份是否可用。
●它能够按照用户指定的限制识别需要备份的数据文件。
●RMAN能够对所执行的全部备份与恢复操作生成日志。
●可以存储预配置并编译了的备份脚本，并在任何时间运行，而不需要反复地重新编译这些RMAN命令。
●RMAN脚本与操作系统无关，可以不加修改地移用到所有的操作系统上。
RMAN必须使用控制文件或者恢复目录进行数据库恢复，因此如果控制文件损坏或者恢复目录损坏，将会导致无法恢复，因此对恢复目录进行备份也是很重要的。
2.2.3冷备份技术
2.2.3.1原理
ORACLE数据库冷（cold）备份包括以正常方式（NORMAL）关闭Oracle数据库，并备份所需的全部Oracle数据库文件。
这种备份也称为脱机（offline）备份。
在某些情况下，在进行冷备份之前，不大可能进行数据库的正常关闭。
在这些情况下，通常利用IMMEDIATE选项关闭数据库，然后以RESTRICTED模式启动数据库，并最终彻底地关闭它。
然后，使用操作系统备份实用工具拷贝数据库文件和控制文件到异地备份服务器，还必须拷贝所有尚未备份的归档日志文件到异地备份服务器。
Oracle强烈建议不要备份联机日志文件，因为实际上恢复数据库时并不需要它们。
2.2.3.2实现方式概述
这种备份过程包含以下步骤：
（1）关闭Oracle数据库。
●关闭在Oracle上运行的所有与Oracle相关的内部或第三方软件。
●以正常（NORMAL）方式关闭OracleRDBMS。
（2）备份所需的Oracle文件到异地的备份服务器。
●备份所有Oracle数据文件。
●备份参数配置文件和控制文件。
●备份所有的归档重做日志文件。
（3）以正常（NORMAL）方式启动Oracle数据库。
2.2.3.3优缺点分析
●是非常快速的备份和恢复方法（只需拷贝文件）。
●数据库既可运行在归档模式，也可运行在非归档模式。
●与归档日志文件相结合，可作数据库在备份后的任一时间点的恢复。
●维护容易，数据安全性高。
●在冷备份过程中，数据库必须是关闭状态，不能提供给用户访问，因此对生产业务影响大。
●若磁盘空间有限，只能拷贝到磁带等其它外部存储设备上，速度会很慢，从而对生产业务影响时间长。
●不能检测出数据坏块。
2.2.4联机热备份技术
2.2.4.1原理
当Oracle数据库处于打开状态，并以ARCHIVELOG模式操作时采用热备份。
这种备份也称为联机（online）备份。
虽然允许用户在此备份过程中访问数据库，但是当Oracle数据库负载较低时，设计这个备份过程必须小心。
例如，不要试图在大量更新批作业运行时备份一个数据库，因为数据文件与在非热备份（HOTBACKUP）模式下的文件相比，它可能会产生更多重做记录。
另一种选择是，如果可能，批作业规划在备份过程完成之后进行。
2.2.4.2实现方式概述
热备份过程包括备份属于特定表空间的所有数据文件、归档重做日志和控制文件。
热备份类型的备份过程包含以下步骤：
（1）进行表空间的联机备份。
在备份前将备份的表空间置于backup模式，即发出altertablespacebeginbackup命令时，则属于该表空间的数据文件标志为hot-backup-in-progress（热备份进行中）。
在发出altertablespacebeginbackup命令之前进行备份，将使备份数据文件失去作用。
该命令将对热备份模式下的所有数据文件设置检查点，这意味着在热备份模式下属于这些数据文件的任何脏缓冲区都将写入磁盘。
文件头的检查点SCN前移至发出beginbackup命令时捕捉到的SCN。
这很重要，因为备份文件中的检查点SCN必须与备份开始时的一致，Oracle不能保证文件头是操作系统备份实用工具拷贝的第一个数据块。
至此，在初始化检查点之后，在热备份模式下后续的检查点将停止更新文件头。
如果热备份期间在数据文件上进行的DML（即插入、更新或删除操作）越多，则此期间产生的重做记录越多。
这就是Oracle为什么建议在数据库中DML操作较少的时候进行热备份的原因。
altertablespaceendbackup命令创建一个含有开始备份检查点SCN的重做记录，这个SCN同时也在热备份数据文件头中，这就是Oracle知道备份期间产生的所有重做记录何时运用到数据文件的原因。
换句话说，使用热备份时，在恢复期间，至少要运用beginbackup和endbackup命令之间产生的重做记录，以使备份数据文件保持一致。
如果在运用重做记录之前停止恢复，并试图打开数据库，将显示错误。
注意数据库中的每一个表空间都必须进行上述操作过程，且此时数据库应在ARCHIVELOG模式下运行。
进行热备份时，Oracle不允许使用NORMAL或IMMEDIAE选项关闭数据库，而且不能使用NORMAL或TEMPORARY选项使热备份模式下的表空间脱机。
（2）备份所有归档重做日志文件，但不应对联机重做日志文件进行备份，因为联机日志含有备份结束标记，如果在恢复中使用将导致混乱。
。
（3
升级会员 