随着全台大量IT应用系统的建设，对系统的安全性、可靠性和业务连续性方面提出了很高的要求。而大量的意外事件，如存储、网络、外界因素电网、病毒灾难等处界因素、应用系统内部容错措施失效等原因都将会导致应用系统的数据丢失、业务中断，势必造成巨大的经济损失。

为此在存储项目中建设一套高效、可靠、投资回收比高的数据库灾难备份系统，确保系统的数据安全和灾难发生时的快速恢复。
 

1.1.1 数据库灾备需求特点
1.1.1.1 可靠性要求非常高

系统数据库灾备涉及大量的应用系统元数据存储，所以必需保证系统的数据复制的可靠性要求非常高，必需做到数据的准确性。
 

1.1.1.2 要求对生产业务系统影响尽量小

由于生产系统一般都承受大量的数据生产的压力，所以备份系统必须降低对生产系统本身的数据库系统压力，尽量降低备份和复制本身对生产系统数据库的性能的占用。
 

1.1.1.3 集中灾备，支持备份库应急使用

对于灾备系统需要提供对生产系统应急使用要求，在生产系统出现故障时，灾备复制系统能够及时应急顶替生产系统，确保业务连续和数据连续。
 

1.1.1.4 支持多源异构的数据库备份

考虑到全台数据库平台的不统一性，有可能存在不同的数据库产品和架构，所有数据库的备份需要能够支持不同源数据库备份。
 

1.1.2 数据库灾备一体化解决方案
1.1.2.1 数据库系统故障原因分析

系统灾难是指造成重要业务数据丢失、或者使业务系统停顿过长时间（不可忍受）的事故。系统灾难可能导致企业的业务的严重损失。

根据行业内经验，我们分析系统主要面临的风险有：

n 计划内

?? 应用软件等的升级,

?? 备份/恢复/归档

?? 数据中心迁移、整合

?? 测试、容灾演习…

n 计划外

?? 系统处理能力下降

?? 人为操作故障：错误删除文件数据，造成不可恢复；错误执行程序或命令，造成系统死机…

?? 系统软硬件故障，主要包括电源及UPS故障、硬盘故障、通讯控制器故障、系统总线、内存、CPU故障等

?? 安全体系被攻破

?? 生产地点的灾难：水灾、火灾、地震及其他机房事故等

n 其它

?? 包括灾难的潜在影响，如水灾、地震等，常伴随着电力的供应问题。

业界研究表明，在以上各种导致系统下线的原因中，各种原因的比例为：

clip_p_w_picpath002

40％的系统灾难是由于操作人员操作失误而引起

40％的系统灾难是由于应用软件的问题所引起

20％的系统灾难是由于设备的物理物理原因所引起，如硬件失效、掉电、自然灾害等

由此可见，系统计划外下线的主要原因在于人为操作失误和应用软件问题造成，而真正由于自然灾难造成的下线几率非常小。
 

1.1.2.2 数据保护技术

从上分析可知，系统下线原因可分为两种：逻辑错误和物理错误。逻辑错误和物理错误的防范机制也应该不同，主要的方法为如下两种：定时拷贝和连续复制：

连续复制：

连续复制是对业务状态数据进行持续不断的复制。主要预防业务系统遭遇故障如突然的宕机、存储故障等物理错误时恢复应用进程。当灾难发生时，连续复制过程也终止；在进行业务恢复时利用复制结果可以恢复停机现场的生产数据，从而恢复业务。

实际上，业务系统不能运行的原因也由这两部分组成，因此在数据保护方面也需要采用实时备份和定时备份相结合的原则。

定点拷贝（Point-in-time Copy）：

定点拷贝（Point-in-time Copy）是在业务运行过程中某一时刻的生产数据的保护。该保护在业务正常运行时生成，主要预防业务因生产数据的逻辑故障而造成的停顿；当生产数据因人为误操作或病毒破坏而损坏时，可以利用该定点拷贝将业务状态恢复到损坏发生时刻的业务正常状态。在具体的业务恢复过程中，辅以其他手段，可补充自定点拷贝生成时刻起至业务中断时这一段时间业务运行新产生的生产数据。

而上面原因分析可以看出在众多灾难产生的原因中，所有的逻辑错误都需要定时拷贝机制来实现。可见定时拷贝在数据安全性上的重要性。

表面上看二者都是实现数据的备份和恢复，但在实质上二者有着本质的差别，主要差别在于：

数据备份复制目的在于保证系统的可用性：当生产系统发生故障时，可在短时间内（分钟级）通过备份系统对外提供业务服务，以使交易不致停顿。

定时备份的目的在于对数据的保护：当生产系统发生数据损坏时，可以通过备份系统上的数据进行恢复。备份数系统上保存了多个备份时间点的多个版本，当生产系统的数据被破坏时，可通过备份系统的数据将系统回溯到错误发生之前的时刻。该技术能够应付交易数据库中的逻辑错误（比如误删除表，表记录改错了等）。同时对备份数据的异地存放可以实现异地灾备。

所以，虽然我们可以采用数据复制备份软件来达到实时备份的目的，当生产系统不能对外提供业务的时候，能够在备份系统上快速的接管业务。但是定时备份仍然是不可替代的：

复制备份无法解决生产系统的带病运行情况：例如无法避免truncate table，drop table以及错误导入数据等逻辑错误，无法识别这些错误是正常操作还是错误操作，当生产系统的数据被破坏后，备份系统上的数据也是被破坏的。

却能够避免这些数据的错误，保护数据不被破坏。当生产数据被破坏时，我们可以通过定时备份系统的多个时间点的备份数据来将系统回溯到发生错误之前的状态。

因此，将实时复制和定时备份两种技术配合使用，以达到系统保护和数据保护的双重目的。
 

1.1.2.3 实现方式及集成建议

在该高可用环境的备份构架如图：

clip_p_w_picpath004

数据库灾备一体化架构主要包括两个部分，一个是针对生产数据库的实时复制备份、另一个是针对数据库的集中D2D2T的数据库备份。
 

1.1.2.3.1 实时复制的实现

在这个架构中主要采用两类数据保护产品：实时备份和定时备份。

实时复制备份产品：是通过交易实时同步的方式实现数据备份。其目的是保护业务系统的业务连续性，当生产系统出现因为硬件故障、数据库故障、以及环境故障等而不能正常提供服务时，可在备份系统上快速接管。确保业务的连续性。

实现这些功能的业界常用解决方案主要包括以下几类：

n 磁盘阵列复制技术：主要由一些磁盘阵列厂商提供，如EMC SRDF、IBM PPRC 、HP BusinessCopy、HDS TrueCopy等；

n 存储卷复制技术：由一些卷管理软件厂商提供，如VERITAS VVR；

n 数据库复制技术：由数据库厂商以及一些第三方厂商提供，如Oracle的 Data Guard、Streams、DSG RealSync等；

n 应用层复制技术：由各系统的应用厂商自己提供；

 

我们重点分析以下几类方式：

1) 基于存储或卷的数据文件复制方式备份

2) 居于数据库本身日志同步方式实现复制

3) 第三方开发在Oracle开发居于Redo log逻辑备份产品

4) 第三方开发在Oracle开发居于数据表或者视图通过（trigger）触发器进行逻辑数据复制

 

我们首选分析实现方式1和实现方式2：

对于方式1：居于存储数据镜像实现数据复制容灾中，数据一致性是关系到容灾系统数据可用性的关键指标，只有保证数据一致性的灾备方案，才能保证数据可用，数据库能够正常启动。特别是异步容灾，数据一致性更关键；

不同的存储厂商采用了不同的方法、技术保证数据的一致性，但主要有以下三种：

1）基于时间戳（TimeStamp），典型的代表是IBM的XRC，本质是磁盘机微码对每个I/O记录一个从主机时钟（Timer）取得的时间戳，当这些I/O被传输到灾备中心后，灾备主机（SDM）对这些I/O按时间戳排序，然后写到灾备磁盘，以保证数据的一致性。

2）基于磁盘I/O序号，典型代表HDS TRUE COPY，本质是磁盘机微码对每个I/O记录一个序号，当这些I/O被传输到灾备中心后，灾备磁盘机对这些I/O按序号排序，然后写到灾备磁盘，以保证数据的一致性。

3）写一致I/O（Write Pending I/O），典型代表EMC SRDF/A，本质是磁盘机微码对生产机I/O 按时间进行分组（Delta Sets），然后将这些组数据按时间传输，并按时间写入灾备磁盘， 类似于数据库的机制，保证数据的一致性。

只有通过这些存储本身的功能，确保数据的一直性，备份的数据库才能被正常启动。同时在以上居于存储实现方案中需要多有备份的阵列统一，服务器同构，并且目标端是不能使用的，只有在主数据库损坏情况下使用备用数据库打开数据库，并且对于保证在复制时不影响本地阵列的性能也很难保证。

但是从我们实践经验来看，虽然往往数据能够完整，但是往往因为数据文件一致性问题导致数据库不能重启，特别是数据集控制文件的打开。

对于方式2：

方式2是采用Oracle本身居于日志的备份方案，主要原理如下：

clip_p_w_picpath006

在这种备份案中，要求主数据和备份数据库OS相同；

如果采用物理备用库，备份数据库无法在其以只读方式打开的同时运行恢复。如果在备用数据库以只读方式打开时，传送给它的重做数据将在备用站点上累积而不应用。不过，可以随时在物理备用数据库上恢复操作，并自动应用累积的重做数据。这允许物理备用数据库以一个序列运行，这个序列可能包括在恢复中运行一段时间，然后以只读方式打开来运行报表，接着重新运行恢复来应用尚未应用的重做数据。

对于逻辑备用库，SQL 应用技术将从主数据库接收到的重做数据转换成 SQL 语句，然后在备用数据库上执行 SQL 语句，以使逻辑备用数据库与主数据库保持同步。由于使用 SQL 语句更新逻辑备用数据库，因此它保持以读写模式打开。

但是，在新出的11g版本，在备份库采用物理备用库的情况，备份库能以只读模式打开；

对于主备之间的切换，可以采用Oracle Data Guard Broker 实现，Broker是一个分布式管理框架，它不但自动化了 Data Guard 配置的创建、维护和监控，并对这些操作进行统一管理，实现故障切换和转换。并且能够实现反向自动重新同步。

对于方式3，我们以DSG为例，来说明原理：

clip_p_w_picpath008

如上图所示，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：

方式四的实现方式其实是在数据库更上层的应用来实现，是通过捕获数据库中数据变化的方式，将变化的数据以触发器的形式进行输出，然后通过应用将数据以SQL语句方式写入目标数据库。

对于这四种方式中我们做如下几点说明：

第一、对于存储级别的存储复制实施较为简单，但是技术不太透明，维护成本较高，并且对于存储设备的依赖程度较高，一般程度只支持相同厂商的存储数据复制，而且实施成本较高，所以在多源集中灾备系统中不建议采用存储级复制。

第二、更关键的是在这种以数据方式同步的情况，不能保证数据的一致性。所以很可能会出现数据库不能恢复的情况；

第三、对于第四种方式采用数据库触发器形式，捕获数据更新，然后由数据库更新目标数据库方式，这种方式对于数据量较大时，对数据库的影响较大，在触发器执行的SQL语句可能会导致更严重的性能下降，例如这些SQL语句需要执行更长的时间， 或者这些SQL语言要锁住更多的资源，甚至造成死锁（DEADLOCK）。所以对于复制应用不建议采用这种模式。

第四、对于第2种和第3种方式，其实目前IT行业比较流行的方式，在实现机理类似的情况下，在数据库的应用，目前主流数据库都支持用于数据库复制的功能，数据库的复制特性例如Oracle的Data guard本来就是不收取另外费用，所有使得数据库复制的基础成本显得更为低廉，而且因为数据库技术的透明性，数据库同步是居于数据更新的顺序性，可以保证同步过去的数据库在一致的状态下打开，如果集成配置方案足够完好，数据库方案不会丢失任何数据，所有我们更倾向使用数据库的容灾技术。数据库复制方案成本比较低，而且技术上透明灵活，所有我们选择采用数据库复制方案。

第五、居于日志的逻辑复制技术不需要通过任何数据库的引擎来获取变更数据，而是通过数据库自身的信息获取源系统上的改变并传送给目的系统，不会对生产系统造成性能影响，并且在有Data Guard的基础上，开发较为完整的人机界面，这类产品目前比较成熟有国外的Shareplex和GoldenGate、 HVR(High Volume Replication)；国内的有DSG。

所以我们建议，在数据库实时备份复制上，我们选择方式2或者方式3实现。
 

1.1.2.3.2 定时备份的实现

对于数据定时备份，我们考虑一下几点：

第一、考虑到我们当前数据库都已经存储复制的站点，那么建议定时备份都从Standby上备份，这样实现的好处是：

1、 如果Standby在Open模式下备份，整个备份本身就是时间点一致的，可以随时打开；

2、 在Standby上的备份可以减缓主数据库的压力；

第二、对于定时备份，建议采用磁盘阵列作为备份缓冲区，尽快的完成数据库备份，然后在充足的时间内再备份到磁带，同时利用磁盘备份可以直接利用RMAN进行备份；

第三、对于大量数据备份我们建议采用数据流磁带方式进行长期保存，这种这种模式下可以保留更多的备份数据，并且在不做远程备份网络的情况下，可以通过离线介质的异地保存实现数据容灾。

第四、对于定时备份已经有比较成熟的产品，比如备份管理软件Vertas、Bakbone等等。这样产品在Oracle RMAN基础上，有着完整的媒体管理和备份策略的可视化配置，比RMAN使用更简单有效。
 

1.1.2.3.3 居于数据库闪回技术恢复

当主数据库打开并处于活动状态时，事务处理正在进行，生成重做数据，并将其传输到备用站点上。鉴于人为错误是造成系统停机的主要原因，这种重做数据可能包含重大的逻辑用户错误，如丢失一个重要的表，这可能使主数据库崩溃。

Data Guard 提供了几种易于使用的方式来避免这种用户错误。管理员可以决定在主数据库和备用数据库上同时使用 Oracle Database 10g 的闪回数据库功能，以快速将数据库恢复到一个较早的时间点上，从而取消这种用户错误。另外，如果管理员决定故障切换到一个备用数据库上，但那些用户错误已经应用到了备用数据库中（例如，由于启用了实时应用），则管理员可以简单地将备用数据库闪回到一个安全的时间点上（假定在备用数据库上已经启用了闪回功能）。最后，管理员还有额外的选择，可以不在一个或多个备用数据库上使用实时应用特性，相反使重做数据在那些备用数据库上的应用延迟一段可配置的时间，这提供了一个防止这种用户错误或损坏的保护窗口。
 

1.1.3 灾备一体化方案设计
1.1.3.1 系统结构

根据需求及其业务特点，我们建议的容灾备份一体化解决方案架构如下所示：

clip_p_w_picpath009
 

1.1.3.2 生产系统

一般由两台以上UNIX或Linux服务器组成，安装ORACLE数据库，采用RAC或者HA架构。数据量一般在50 GB左右，每天产生的archive log量约在5 G左右。
 

1.1.3.3 容灾和备份系统

根据目前要求，一般需要建立本地实时备份中心和本地定时备份中心。

实时备份中心：一般选择和生产服务器相同档次的服务器（不过可选择不同厂商的），但一般建议采用单机结构用作备份服务器，无需在本地备份服务器上采用HA或双机结构。

定时备份中心：一般选择一台PC机（安装Linux操作系统）用作备份服务器，用来作为定时备份使用。

实时备份服务器和定时备份服务器可共用一个磁盘阵列。同时通过存储SAN挂接数据流磁带库，做定时备份的D2T备份。
 

1.1.3.4 实时复制实现

对于实时复制，在不同数据库平台上有不同的实现方式，在Oracle平台有两种实现方式Oracle Data Guard和Oracle Steams两种方式，同样在DB2上有DB2复制和Q复制两种方式。这里建议对于Oracle采用Oracle Data Guard，DB2采用DB2复制复制方式。

当然也有第三方产品支持这种复制，比如SharePlex和DSG Realsync，但是这种产品基本基于数据库的复制功能进行上层开发；而且Oracle Data Guard和DB2复制，都是数据库企业版本自身带有功能，所有建议采用自身功能完成这些应用。
 

1.1.3.4.1 实时备份的集成

针对以上实时备份的实现方案，目前主要针对Oracle和DB2数据库，我们建议针对不同数据库提供不同集中备份数据库，该结构如下：

clip_p_w_picpath011

对于实时复制，我们建议采用不同类型数据库采用不同平台方式，DB2数据库集中复制到一个平台，Oracle数据库集中复制到一个独立平台，保证同平台，确保实现数据库的应急使用过程中，对于应用的连续。
 

1.1.3.5 定时备份实现

为了实现该本地定时备份功能，我们采用成熟的第三方数据库备份软件。参照Bakbone备份软件，该备份结构如下：

clip_p_w_picpath013

备份软件通过，部署数据库客户端的Agent直接备份数据库，可以支持一个服务器上多个实例的同时备份，通过备份NetVault通过LAN直接将数据库备份到备份磁盘阵列上，然后通过智能客户端将数据库通过LANfree方式备份到备份磁带库。
 

1.1.4 备份和灾难恢复策略设计

在采用了实时复制加定时备份一体化备份解决方案后，可提供所有情况下的灾难恢复支持：包括业务连续性的切换，也包括因为误操作而造成的数据损坏。
 

1.1.4.1 数据实时备份

通过数据库的实时复制功能，将数据实时备份到本地服务器上异地服务器上。

复制可以配置实时备份的时间间隔（日志抓取的频率），一般在我们的应用中更加不同的类型数据库设置不同的同时复制间隔。比如对于新闻的数据库设置间隔可以保持着5秒左右，对于媒资等数据库可以设置时间更长，比如1分钟等。
 

1.1.4.2 数据定时备份

通过备份软件的定时复制功能，将数据实时备份到磁盘设备或者离线设备上。

定时的备份策略一般设置为：

每周六晚上进行一次全库的物理全备份；对于集中数据库的数据量大小，一次物理全备的时间基本在30分钟左右；

每天晚上在业务不集中时后作一次全库的增量备份；对于集中数据库的数据量大小，一次全库的增量备份的时间基本在10分钟左右。

对于数据量在100GB以下的系统，建议每天都作全备份即可。

平常将archive log备份；

系统作升级、调整、测试前作一次物理全备份。

在备份服务器上一般建议保存2周以上的数据，这样当数据出现误操作丢失后，我们可以通过每天的备份版本和当天的archive log日志recover到出现故障前的时间点。
 

1.1.4.3 灾难恢复策略

在采用了实时备份和定时备份一体化保护的情况下，我们在出现灾难时选择进行恢复，整体的恢复策略如下：

第一、对于高可用一体化环境中，最小的恢复案例就是用来还原（Restore）一个数据库文件，假定主库上，因为误操作，删除了一个数据文件，但又不想切换到备用系统，那么最快的恢复数据库的方式就是从备用系统上把这个数据文件拷贝过去。

假定备用系统就是物理的Standby，Oralcle物理Standby的数据文件其实跟主库的数据文件是一样的，可以认为备用库数据文件是主库数据文件的一个快照。要还原主库的一个数据文件，最简单办法就是从备用库上拷贝过去并恢复（Recover）到一致状态。其大致过程如下：

1、 假定主库上数据库文件被误删除，可以先从数据库中offline该数据文件

2、 从备用库拷贝该数据文件，不管是文件系统，还是裸设备，都可以用RMAN来拷贝到文件系统；

3、 从备用库拷贝数据文件到主库，如果主库使用的文件系统，可以直接拷贝到数据文件的位置，如果是裸设备，先拷贝到裸设备，然后用dd命令还原；

4、 然后恢复（Recover）该数据文件；

5、 最后，online该数据文件；

当然，在同步可切换环境中，如果是因为物理的问题，例如服务器无法启动、磁盘阵列无法启动等情况下，最高级别的保护，就是最复杂的情况下，也就是切换（Fail over）了，其实就是一个Standby（Data Guard）的切换过程，利用实时备份复制系统来接管业务。可以通过Oracle Data Guard Broker实现应用的切换，第一保证业务连续。

在业务实时得到连续保证后，那么剩下对于生产系统的修复。

第二、如果遇到的是逻辑问题，如数据库勿操作或者人为的错误，并且错误也已经被同步到Data Guard，那么我们建议Oracle Flash Back快速闪回数据库，通过本身数据库快照进行恢复；

对于Flash back Database主要是利用数据库的前滚日志，根据前滚快照点，加上归档日志和联机日志，就可以恢复任何时间点上的记录了。前滚恢复的主要步骤如下：

n 根据指定的时间，恢复时间点之前的最近的快照，也就是块的前映像，这个过程没有Restore过程出现；

n 根据归档日志或者联机日志，回复到指定时间点的一致性状态；

这样就是可以闪回数据库。

第三、如果针对较大的数据库事故，比如数据库阵列损坏导致整个数据库的重建等等，那么我们需要利用定时备份系统中，备份数据做数据库的恢复和还原。这种数据的恢复和还原可以不在原生产环境中恢复，甚至可以用备份文件中异地进行恢复。这种恢复能够将数据库恢复到以前的一个状态正常点。