某社保信息系统数据库

异地容灾系统改造技术方案建议书

某市劳动和社会保障信息中心对计算机系统的数据安全提出极高的要求。为了应对各种系统硬件或系统软件故障而造成的系统停机，目前中心数据库服务器采用双机集群配置，磁盘采用RAID 技术提供磁盘镜像，并配备磁带库数据备份系统。当某一通信线路、路由器、防火墙、交换机、服务器出现故障，相应的备份通信线路，以及冗余的路由器、防火墙、交换机、服务器接管工作。当数据磁盘出现故障时，可以采用RAID 磁盘镜像以及数据备份系统进行数据恢复。但尽管如此，目前，针对系统中极为重要的业务数据的安全防护，只采用了数据备份的单一落后的手段，因而不能快速有效的应对各类数据事故或灾难。因而，为了进一步的提高整个系统的容错能力，从而确保应用系统业务数据的绝对完全，并在数据库服务器或磁盘阵列中任何一个系统发生故障的情况下，都能够迅速接管原系统的服务和数据，从而保证系统的连续运行，我公司特设计了此套针对某市社保信息系统的数据库容灾方案。

Oracle 公司和一些第三方的厂商提供了基于Oracle redo log 的数据库的容灾技术。基于数据库的容灾技术与前面所说的两类基于存储和逻辑卷的数据复制容灾技术有较大的差别。Oracle 在其数据库产品中集成了称为Data Guard 的数据库容灾产品。Data Guard 提供了一种管理、监测和自动运行的体系结构，用于创建和维护一个或多个备份数据库(Standby Database) 。通过传输和运行数据库日志(redolog 或archived redolog) 文件，来保持生产和备份数据库的数据一致性。一旦生产数据库因某种情况而不可用时，可以在非常短的时间内(数分钟)将备份数据库切换为新的生产数据库，以达到无数据损失或最小化数据损失的目的，为业务系统提供持续的数据服务能力。Oracle Data Guard 的容灾原理如下图所示：

图一：Oracle Data Guard 容灾的工作原理

ORACLE 从7.3 版开始支持备用数据库(Standby Batabase) 。7.3.x-8.0.x 版本的Oracle 需要手工拷贝所有归档日志并手工同步，从ORACLE8.15 开始，开始支持多节点复制，并实现了自动同步，但是这种数据同步是异步模式的，可能引起数据丢失。

从ORACLE9i 开始，备用服务器已经换了一种新的称呼，叫做数据保护(Data Guard)，在这种模式中，开始支持三种不同的数据保护模式，并开始采用LGWR 对数据的传送而不是以往的ARCH，并增加了一个新的后台进程叫DMON 监控数据的同步，支持多达9 个节点的同时复制。从Oracle9.20 开始，还开始支持物理备用数据库(Physical Standby Database) 和逻辑备用数据库(Logical Standby Database) 。

一个Data Guard 环境可配置一个生产数据库和最多至9 个备份数据库系统，生产和备份数据库之间通过Oracle Net 技术互联，并且没有任何距离上的限制。Oracle Data Guard 产品的体系结构如下图所示：

 

系统的拓普结构如下图所示：

图3: 某市社保中心数据库容灾系统拓普结构

2.3.1硬件和系统软件配置要求

Oracle DataGuard 容灾系统对硬件和数据库软件有以下的基本要求:

主数据库服务器(Primary Database Server) 和备用数据库服务器(Standby Database Server) 要求为同一厂商的产品，操作系统相同，但不要求版本相同。因此选用IBM或HP都可以，但仅限同一品牌。Primary Database 和Standby Databse Oracle 数据库版本完全一致,Primary Database 所用的存储系统和Standby Database 可以为不同厂商和品牌的产品。据此要求我们建议的主数据库服务器系统和容灾备用数据库服务器系统硬件和系统软件配置如下表:

设备名称和用途	设备配置	数量	备注
主数据库服务器	HP RX8640或IBM P570，配置8 CPU/32GB	2 台	新购买
主磁盘阵列	HP EVA4400，9*300GB 或IBM DS4700，9*300GB	1 台	新购买
主SAN交换机	8口/4gb	1 台	新购买
磁带库	HP MSL6030，800G/1.6T 或IBM 3573-L4U，800G/1.6T	1 台	新购买
备份软件	HP DP软件或IBM TSM	1套	新购买
应用服务器	利用现有的RX4640； 每台机器改造到4CPU/16GB	2 台	购买2*2路RX4640CPU， 24GB RX4640内存
网络设备	连接信息中心机房和和远程灾备中心的必要网络设备，如交换机、路由器等	1套	视中心目前网络配置和具体连网情况而定
容灾备用数据库服务器	HP RX6600或IBM P550，配置8CPU/32GB	1套	新购买
容灾磁盘阵列	利用现有的HDS9570V，28*146GB	1 台	购买12*146硬盘
容灾软件	Oracle10g Data Guard	1套	Oracle10g 企业版中已经集成了Oracle10g Data Guard 产品

表一: 某社保中心数据库容灾系统改造主要配置建议

2.3.1硬件和系统软件配置要求

Oracle DataGuard 容灾系统对硬件和数据库软件有以下的基本要求:

主数据库服务器(Primary Database Server) 和备用数据库服务器(Standby Database Server) 要求为同一厂商的产品，操作系统相同，但不要求版本相同。因此选用IBM或HP都可以，但仅限同一品牌。Primary Database 和Standby Databse Oracle 数据库版本完全一致,Primary Database 所用的存储系统和Standby Database 可以为不同厂商和品牌的产品。据此要求我们建议的主数据库服务器系统和容灾备用数据库服务器系统硬件和系统软件配置如下表:

设备名称和用途	设备配置	数量	备注
主数据库服务器	HP RX8640或IBM P570，配置8 CPU/32GB	2 台	新购买
主磁盘阵列	HP EVA4400，9*300GB 或IBM DS4700，9*300GB	1 台	新购买
主SAN交换机	8口/4gb	1 台	新购买
磁带库	HP MSL6030，800G/1.6T 或IBM 3573-L4U，800G/1.6T	1 台	新购买
备份软件	HP DP软件或IBM TSM	1套	新购买
应用服务器	利用现有的RX4640； 每台机器改造到4CPU/16GB	2 台	购买2*2路RX4640CPU， 24GB RX4640内存
网络设备	连接信息中心机房和和远程灾备中心的必要网络设备，如交换机、路由器等	1套	视中心目前网络配置和具体连网情况而定
容灾备用数据库服务器	HP RX6600或IBM P550，配置8CPU/32GB	1套	新购买
容灾磁盘阵列	利用现有的HDS9570V，28*146GB	1 台	购买12*146硬盘
容灾软件	Oracle10g Data Guard	1套	Oracle10g 企业版中已经集成了Oracle10g Data Guard 产品

表一: 某社保中心数据库容灾系统改造主要配置建议

2.3.2网络需求

Oracle Data Guard 是通过Oracle Net Service 来进行日志文件传输和同步的，一般采用TCP/IP 网络传输。因而对网络的设备、线路没有特殊的要求。但在系统实施时，必须根据主数据库的具体情况确定最低的网络带宽的要求。

根据经验推算，某社保系统每天Oracle 生成的日志文件的容量不多于60GB，由于一天当中社保业务处理量分布不均匀，多数Redo 信息(70% 左右)在每天约4 小时的高峰时间生成。据此我们可以估计高峰期的日志传输量为60GB X 0.7 / (4 X 3600) = 3MB/s，约为30Mbps 。因而，建议数据中心和容灾中心间的网络连接带宽至少为30Mbps 。容灾中心的选择可根据此网络带宽的要求确定。（此部分为经验推算）

2.4 Data Guard 运行模式选择

Oracle10g 在Data Guard 的配置方面提供了几种不同的类型，根据某社保用户对于高可用性的不同要求，可以选择不同的Data Guard 类型。

按照备用库（Standby Database）应用归档日志的不同方式，Standby Database 可以分为物理备用库（Physical Standby）和逻辑备用库（Logical Standby）。

１）物理备用库（Physical Standby）：

物理备用库提供了一份跟主数据库在物理级别上完全相同的copy，指在数据库的data block 级别都是完全相同的，比如数据库表中记录的rowid 。物理备用库是通过不断地恢复Primary Database 传入的重作日志数据信息来达到跟主数据库保持同步。

物理备用机在物理上和主据库的结构完全一样。也就是说，物理备机除了control 文件和主机不一样以及在线日志是可选的以外，其它都和主数据库一样。

物理备用机的两种数据库打开的模式:

a) Managed recovery mode

归档文件从主数据传到备用数据库，log apply services 把这些日志应用到备用数据库中。

b) Read only mode

这种模式可供用户只读的操作数据库，归档日志仍然会从主数据库传到备用数据库，但Log apply services 不可以把这些日志应用到备用数据库中。

相对于Logical Standby Database 来说，Physical Standby Database 具有如下优点：

（1）支持所有的DDL 和DML 语句，不管是什么数据类型、表的类型，任何DDL 和DML 语句都可以应用在物理备用数据库上。

（2）性能优势

（3）相对于logical standby database 而言，physical standby database 的性能要优越很多，特别是有大型操作的时候，physical 是直接应用归档日志的，而logical 的方式则是需要把所有的归档转换成SQL 语句再在logical standby database 上执行它。这会占用大量的系统资源，如CPU，memory，I/O 等。

（4）可以在Standby Database 上进行数据备份工作，从而减轻主数据库的备份压力

（5）物理备机的中的数据文件可以用来恢复主数据库的数据文件

（6）减轻主数据库的工作压力

（7）备用数据库可以用只读方式来打开，可以分担一部分查询的工作

 

２）逻辑备用库(Logical Standby Database)

逻辑备用库指在逻辑上跟主数据库保持一致，但是在物理层面上跟主数据库并不相同。逻辑备用库是通过将Primary Database 传入的重作日志数据信息转化为SQL 语句，然后在备用库上重新执行来达到跟主数据库保持同步。与物理备用机不同的是它可以在更新的同时对数据库进行查询。

逻辑备用库在应用重作信息的同时也可以提供查询功能。但是由于逻辑备用库应用重作日志的方式限制，所以逻辑备用库在功能和性能上面都有所限制。以下是逻辑备用库的一些限制条件。

1) 以下数据类型不被支持：

NCLOB ，LONG ，LONG RAW ，BFILE ，ROWID ，UROWID

2) 以下操作不被支持：

ALTER DATABASE ，ALTER SESSION ，ALTER SNAPSHOT

ALTER SNAPSHOT LOG ，ALTER SYSTEM SWITCH LOG

CREATE CONTROL FILE ，CREATE DATABASE ，

CREATE DATABASE LINK ，CREATE PFILE FROM SPFILE ，

CREATE SCHEMA AUTHORIZATION

CREATE SNAPSHOT ，CREATE SNAPSHOT LOG ，CREATE SPFILE FROM PFILE

CREATE TABLE AS SELECT FROM A CLUSTER TABLE

DROP DATABASE LINK ，DROP SNAPSHOT ，DROP SNAPSHOT LOG

EXPLAIN ，LOCK TABLE ，RENAME ，SET CONSTRAINTS ，

SET ROLE ，SET TRANSACTION

3) 高级队列的管理和物化视图的刷新不被支持

4) 要求每张表应该有主键或者唯一性索引，如果必须有没有唯一性标识的表，那么可以激活Primary 库的supplemental logging 属性，但是这样将会在重作日志中记录该表中每一条记录的所有字段信息，会大大增加重作日志的记录量。

优点：

（1）数据是实时更新的，而且也可以让用户进行查询操作

中建立索引和物化视图以方便用户的查询。

由此可见，虽然Logical Standby Database 的一个显著优点是备用数据库可提供查询服务，但在oracle9i 的Data Guard 产品中，Logical Standby Database 并不支持所有的数据对象的远程数据同步，而某社保系统数据库中存在Lob, Long 等不被Data Guard 支持的数据类型，因而不建议采用Logical Standby Database 模式。

按照主数据库（Primary Database）的保护模式，整个Data Guard 环境分为最大数据保护模式（MAXIMIZE PROTECTION），最大可用性模式（MAXIMIZE AVAILABILITY），最大性能模式（MAXIMIZE PERFORMANCE）。

1) 最大数据保护模式（MAXIMIZE PROTECTION）

这种模式提供最高等级的数据保护，Primary Database 和Standby Database 之间数据完全相同。Primary Database 的LGWR 进程将同时把日志信息传送到online redo 和Standby Database 备用节点上，在主节点事务确认之前，至少有一个备用节点需要收到日志，如果备用节点无法接受日志信息，则该事务就无法提交，这就确保了数据的完全同步。但在网络不好的情况下，引起LGWR 不能传送数据，将引起严重的性能问题，导致主节点DOWN 机。如果采用这种模式，建议能建立多个standby database，以确保日志能够至少归档到一台备用机上，减少down 机的机会。

2) 最大可用性模式（MAXIMIZE AVAILABILITY）

在备用库正常的情况下，该模式提供了跟MAXIMIZE PROTECTION 一样的机制，保证没有任何数据丢失。如果备用库不可用，那么将转换到最大性能模式(MAXIMIZE PERFORMANCE)，操作可以在主库上继续执行。当备用库重新可用之后，将会继续同步，但是如果在同步完成之前，主库恰好由于故障损坏，将会丢失部分数据（当然，可以通过RAID，RMAN 等方式尽量保护主库即使出现故障也不丢失数据）。

如果只有一台standby，又不想有数据丢失的话，推荐采用这种模式。

3) 最大性能模式（MAXIMIZE PERFORMANCE）

这种模式下，主库上的Redo 信息是异步传递到备用库上，不论备用库上是否已经成功接收了重作信息，主库上的操作都会成功执行。所以这种模式提供了最好的性能，但是最低的数据保护。当主库出现故障时，因而备用库Redo 信息接收不完全，因而可能造成部分损失。

按照主库向备用库传递Redo 重作信息的方式，可以分为ARCH 方式和LGWR 方式。

1) ARCH 方式

当主库归档联机重作日志文件(online redo logfile) 时，ARCH 归档进程在归档到本机的同时，将重作数据传递到备用库，由备用库端的RFS 进程（Remote File Server）接收，生成备用库端的归档日志文件，然后由备用库端的MRP 进程（物理备用库类型）或者LSP 进程（逻辑备用库类型）将归档日志文件恢复到备用库中。

2) LGWR 方式

物理备用库类型下，主库的LGWR 进程在将重作数据写到本地联机重作日志文件中的同时，将重作数据传递到备用库，备用库的RFS 进程将收到的数据写入本地的备用重作日志文件（Standby Redo Log）中。当主库日志切换时也触发备用库的日志切换，切换发生时，备用库的归档进程将重作日志文件归档，然后由备用库端的MRP 进程将归档日志文件恢复到备用库中。

在逻辑备用库模式下，因为不可以创建备用重作日志文件（Standby Redo Log），所以处理流程跟物理备用库稍有不同。

主库的LGWR 进程在将重作数据写到本地联机重作日志文件中的同时，将重作数据传递到备用库，备用库的RFS 进程将收到的数据写入本地的归档日志文件中。当主库日志切换时也触发备用库的日志切换，切换发生时，备用库的归档进程完成归档日志文件的最后生成，然后由备用库端的LSP 进程提取归档日志文件中的SQL 语句，重新在备用库上运行一遍。

 

最后上述所有类型或者方式互相搭配进行一个比较, 见下表：

保护模式	Maximum Protection	Maximum Availability	Maximum Performance
redo 传递方式	LGWR	LGWR	LGWR 或者ARCH
网络传递模式	同步	同步	当使用LGWR 传递方式时为异步方式，如果使用ARCH 传递方式，那么不牵涉联机重作数据的网络传输
磁盘写入选项	AFFIRM	AFFIRM	NOAFFIRM
是否需要备用重作日志文件	需要	只在物理备用库类型中需要	如果物理备用库使用LGWR 传递方式，那么需要
备份库类型	物理	物理或逻辑	物理或逻辑

 

 

 

 

 

 

 

从上面Data Guard 的几种可能的运行模式的比较中，我们建议某社保中心的数据容灾模式为:

Physical Standby Database

LGWR Redo 同步

Managed recovery mode（备用数据库不提供查询服务）

Maximum Availability

三、系统实施步骤

具体的实施步骤如下:

1) 检查Oracle Data Guard 是否满足以下条件:

 a) Primary Database 必须运行在Archive Log 模式下

b) Primary Database 和Standby Databases 数据库的版本必须一样

c) 操作系统必须一样，但版本可以不同。Standby Database 可以使用与Primary Database 不同的目录结构。

d) Primary Database 硬件和操作系统的结构必须和Standby Database 一样，例如，两者都要运行在32 位或64 位的格式下，但操作系统版本可以不同。

e) Primary Database 和Standby Database 可以是single instance 的，也可以是RAC(Real Application Cluster) 。

f) 主备硬件（CPU 的数量）可以不一样，内存最好一样。

g) 检查Primary Database，避免数据库队象使用nologing 的方式，这样会导致Standby Database 无法与Primary Database 同步

2) 检查远程容灾中心的机房环境是否满足要求合适的远程容灾中心必须具备以下基本条件:

a) 稳定可靠的电源供应

b) 稳定可靠的空调和除湿除尘设备

c) 稳定可靠的防雷和接地设施

d) 稳定可靠的监控设施

e) 稳定可靠的网络设备

f) 配备若干具有一定掌握系统维护技术的专业维护人员

g) 完备的机房管理规章制度

3) 配置数据中心和容灾中心的网络连接测试网络连接是否稳定可靠、实际带宽是否满足设计要求。必要时可以考虑采用线路冗余和网络设备冗余的方式确保网络的可靠连接。

4) Standby Database 服务器的安装和配置在Standby Database 服务器上安装和配置操作系统、Oracle 数据库软件、进行存储设备的规划和配置、网络连接配置。为了方便进行后续的操作和对容灾方案进行测试，Stanndby Database 的安装和配置在社保数据中心机房进行。当Data Guard 容灾系统配置并测试完成后再将其安装到远程容灾中心。

5) Primary Database 和Standby Database 首次全同步Oracle Data Guard 容灾系统在开始实施时必须将主数据库复制到备用数据库，必须通过物理备份和恢复的方法进行此操作，以确保主数据库和Standby Database 在物理结构上完全一致。主数据库的物理备份方式通常有冷备份和在线热备份两种方式，可以根据情况决定采用何种备份方式

冷备份:

将主数据库停机后再进行完全的物理备份。停机的时间取决于主数据库的容量大小和备份的方式，一般在数小时之内便可以完成，为了尽可能减少停机对社保系统造成的影响，建议在周末或夜间进行此操作。

如果主数据库数据文件为普通操作系统文件，可以通过常规的操作系统文件备份方式，如cp、tar 、ftp 等命令进行备份。如果主数据库数据文件为Raw Device，如在RAC 环境下，可以通过操作系统中的逻辑卷管理系统对数据库文件所在的VG 或LV 进行备份，然后再将备份恢复到Standby Database 服务器。

热备份:

如果应用系统不允许停机冷备份，则可以通过Oracle RMAN 对主数据库进行在线热备份，然后将该备份恢复到Standby Database 。

通过备份和恢复的方式首次同步结束后，系统会通过Data Guard 自动进入同步，不需要再进行人为干预。

6) 配置Standby Database

7) 测试Standby Database

8) Standby Database 切换测试

9) 所有测试工作完成后将Standby Database 服务器运置容灾中心现场安装，正式启用

 

四、数据容灾系统集成服务

 服务内容:

在某社保信息系统数据库容灾方案的实施过程中，我公司会根据某社保的需求和客观软硬件条件，将提供以下的服务：

1) 数据容灾方案咨询和设计;

2) 为用户制定Oracle 数据库容灾实施方案，编制灾难恢复紧急预案；

3) 配置数据库主节点和灾难备份节点，编写脚本程序；

4) 为用户提供一年的免费服务，在容灾系统运行出现问题或者在需要实施备用数据库切换的情况下为用户提供快速的远程或/现场服务；

5) 免费维护期内每三个月对容灾系统进行一次定期巡检；

2.3 软硬件配置需求

图二: Oracle Data Guard 体系结构a) Logical Standby Database( 逻辑备用数据库):

逻辑备用数据库通过SQL Apply（即Log Miner）技术，将接收到的日志文件还原成SQL 语句，并在逻辑备份数据库上执行，从而达到数据一致性的目的。

逻辑备用数据库通过Data Guard 进程捕捉redolog file 的信息，通过网络传

输到备用数据库, 将其翻译成sql 语句，然后在备用数据库执行同样的sql 操作。如果其进程赶不上oracle 日志切换，也可以捕捉归档日志(Archiveed redolog file) 中的内容。Logical Standby Database 一般都是以表为单位进行复制，同时也支持大部分DDL 语句的复制。在Logical Standby Database 模式下，备用数据库除了完成和主数据库的逻辑同步任务外，还能以只读方式打开，进行查询、报表、统计分析、数据备份等操作。因为Data Guard 只是复制sql 语句或事务，所以备用数据库的物理结构和可以和主数据库不同。除此以外，还可以在备用数据库中创建额外的索引、物化视图等来提高查询性能。

b) Physical Standby Database( 物理备用库):

物理备用数据库提供了与生产数据库在Oracle 数据块(Data Block) 级的一致性镜像。Data Guard 是通过Redo Apply 技术来保障数据镜像能力。Data Guard 进程捕捉主数据库redolog file 的信息，再通过网络传输到备用数据库，并在备用数据库执行日志文件的redo Apply 操作，将主数据库中数据块的变化复制到备用数据库对应的数据块中去。如果其进程赶不上主数据库日志切换，也可以捕捉归档日志(Archiveed redolog file) 中的内容。

与Logical Standby Database 不同，Physical Standby Database 是基于Oracle 数据块物理复制技术的，主数据库和备用数据库在物理结构上始终保持一致。而Logical Standby Database 是基于SQL 操作的，这样生产库和备用库在逻辑上(行级)保持一致，可以在物理结构上和生产库不同。

无论是Logical Standby Database 或着Physical Standby Database，Oracle Data Guard 技术的特点和优势主要有以下几点：

1) 目标端数据库可以是一个可以访问的（只读的）数据库，可以进行查询、统计、报表、数据备份等操作，因而可以分担生产数据库系统的负荷，减轻主数据库服务器的工作压力。

2) 能保证两端数据库的事务一致性；

3) Data Guard 只复制数据库的变化信息，传输的内容只是redolog 或archive log 中的一部分，所以对网络资源的占用很小，传输数据量大大低于存储或逻辑卷

复制和镜像技术，降低了对网络系统带宽的要求，因而便于远程部署，可以实现不同城市之间的远程复制。

4) Data Guard 对源系统数据库的性能影响很小；

5) 基于其实现原理及多个队列文件的使用，复制环境可以提供网络失败、数据库失败、主机失败的容错能力；

6) 能够对各种数据灾难事故以及进行有效的防护，对系统故障也有一定的防护能力。

7) 当发生各类灾难事故事，Oracle Data Guard 容灾系统可以在数分钟时间内将Standby Database 切换成为主数据库，而且根据Data Guard 配置的运行方式，可以做到完全没有数据丢失或者只有很少量的数据丢失。这样可以将系统的停机时间降到最短，这是基于存储或卷复制技术的其它容灾解决方案无法比拟的优势。

和基于存储和卷复制的容灾方案相比，数据库容灾解决方案具有较好的使用灵活性，但也存在一些缺点，如当数据库的吞吐量太大时，其日志文件的传送和同步会有较大的延迟，当数据库每天的日量文件量超过80G 或更大时，这种方案的可行性交差。另外，Oracle Data Guard 容灾的实施的过程可能会有一些停机时间，来进行数据库的初始同步以及Data Guard 系统的配置的激活；复制环境建立起来以后，对数据库结构上的一些修改需要按照规定的操作流程进行，有一定的维护成本。

2.1.4 常用的数据容灾技术的比较:

基于远程磁盘镜像的容灾技术和以Oracle Data Guard 为代表的数据库容灾技术实现方式完全不同，远程磁盘镜像技术是存储层的数据保护方案，对于Oracle 数据库而言，Oracle Data Guard 提供了更有效、可行，更完备的数据库容灾方案。以下是Data Guard 和远程磁盘镜像技术的总体比较。异步远程磁盘镜像技术的潜在问题:

远程磁盘镜像技术可采用异步方式，达到降低网络延时、减轻对生产系统影响等目的。但用这种方式进行Oracle 数据库的镜像时，却存在一个潜在问题：无法保证写操作顺序的一致性（write-order consistency），导致出现数据坏块的可能性增大。最坏情况，可能导致备份数据库无法打开。

在有BakBone的NetVault软件之前，企业不得不依靠自己有限的备份软件搭建数据信息备份基础设施。NetVault采用与众不同的架构，设计师精心引用“搭积木”的模块化概念，提供易于安装的插件模块，可方便的扩充系统的规模与性能和提供对众多数据库关键性应用软件的支持，如Oracle,  DB2 等等。

如上图所示的，即为NetVault软件的模块化结构图。其中包括，与操作系统直接联系的核心模块，和布置在核心模块之上的服务器模块、图形界面模块、设备控制模块、应用插件模块。

各模块都有其专责功能并透过核心模块传递信息，除了核心模块以外其它各个模块互相之间各自独立。此番设计为产品功能的快速扩充及快速引入新的应用提供了最好的支持，最适合当今快速变化的网络计算环境结构。

1.    核心模块（NetVault Core Module）

介于操作系统与其它模块之间，是软件的基础平台和通讯的桥梁。优化数据传递速度、提供安全控管的机制、拥有系统监测的排错机制，每一台NetVault服务器及客户端都必须拥有此模块。

1.1服务器模块( Server Module )

用于对网络上的所有备份工作的管理，包括介质及设备管理、域管理、NetVault 自身数据库管理、任务管理、排程管理、日志管理，安装于NetVault的备份服务器上。

1.2图形界面模块( GUI Module )

在各种操作系统平台(Unix、Linux、NT/2000 )上提供完全相同的图形操作界面，多重域的控制平台和完整的远程操作功能。具体提供备份任务的设定与执行、恢复任务的设定与执行、客户端管理、设备管理、状态监测、介质管理、任务管理、日志管理。
 

1.3设备控制模块( Device Module )

安装并生效于每一台连接有备份装置的机器上，可驱动下列四种备份装置:磁带机装置、磁带库装置、硬盘虚拟磁带库装置和光学存储装置。同时它还能对这些设备装置进行自动化安装、配置和管理，如：管理分布式备份装置，提供磁带机的缓冲区大小的设置等等。

1.4应用插件模块( Application Plugin Module )

安装在需要备份数据的机器上，针对不同的数据形式有其相对应的模块，例如:

Ø 各种数据库模块：

针对不同的应用环境，NetVault提供了专业的在线数据备份的插件，通过这些插件，用户就可以很轻松的实现对这些应用数据库的数据的备份。

DB2 APM, Oracle Online APM, Microsoft SQL APM, Sybase APM, Oracle RMAN APM，SAP R/3 APM, Informix APM, Lotus Notes APM, MS Exchange APM, My-SQL APM,等。

Ø 特殊应用的功能模块：

针对用户一些比较特殊的应用数据的备份，NetVault只要安装相应的插件就可以实现，如：Windows环境下的打开的文件的备份、映射的磁盘上的数据的备份、SAN环境下的备份支持、灾难恢复、VaultSare下的数据的备份等。

1.5各模块的实际应用

（ 系统架构图 ）

1.6多平台的支持

NetVault 的服务器和客户端支持使用广泛的操作系统平台。（详细的支持列表参考附件）

Ø 集群的支持：

客户端支持所有集群产品，服务器端对Compaq 的TruCluster、SteelEye的LifeKeeper等流行的集群产品有非常好的支持。

Ø 对磁带库、磁带机的支持

NetVault 拥有对广泛的磁带库、磁带机和各种磁带技术的支持。

Ø 数据库、应用及软件接口的支持

NetVault支持各种流行的数据库系统的备份，包括Oracle、Sybase、DB/2、SQL Server、Lotus Notes、SAP R/3、Informix、Adabas、Exchange、NCR Teradata等等。

Ø 文件系统备份支持

NetVault 支持对UNIX、Linux和Windows等各种文件系统的离线和在线备份和归档，支持全备份、增量备份、合并备份等类型。具有备份任务的前/后脚本（Script）处理能力。

1.7硬盘虚拟磁带库

现在，硬盘的容量越来越大，而且价格相对越来越低。为了快速的将重要的数据进行备份和恢复，系统管理员可将特定的硬盘/分区完全仿真成磁带库（注：需要相应的磁盘空间）。把数据先快速的备份到硬盘虚拟磁带库中，在其他指定时间（如白天工作时间）再将数据自动备份/迁移到真正的磁带库磁带上，这样可大幅度缩短备份/恢复时间，同时减少高峰期对网络资源的占用。可作为写入磁带库之前的缓冲备份，同时也可以将其中的数据快速的进行恢复。

1.8强大的NDMP功能

NetVault的NDMP功能相当强大，不但支持多种品牌的NAS系统，同时还可以支持多达5种的方式，可以将网络上的数据通过备份服务器备份到NAS连接的磁带库上，也可以将其他NAS上的数据通过局域网直接备份到连接有磁带库的NAS系统上。

1.9系统的平滑升级

NetVault可以很方便的提供软件的升级。由于NetVault提供的是模块化架构的存储解决方案，而且无论是在Windows环境还是在UNIX环境下，提供的是相同的图形界面，所以NetVault可以很方便、平滑地进行升级。

1.10灾难恢复（ VaultDRTM ）

通过提供裸盘灾难恢复的解决方案可使NetVault的用户无需重装操作系统便可迅速地恢复到在线状态。VaultDR APM可以为NetVault的客户创建一份系统的灾难恢复映象。无需使用多种产品而使您的备份战略多样化。NetVault的VaultDR APM是一个完整的解决方案，可恢复整个硬盘，包括操作系统、应用软件、系统设置、分区的信息和数据。

在灾难发生后，县修复好硬件，然后管理员只需VaultOS启动盘引导需要恢复的客户机，然后通过网络恢复以前备份过的VaultDR映象。VaultOS含有必要的用于重新建立网络通讯和硬盘SCSI/RAID系统的驱动程序。在配合使用NetVault便捷的恢复上一次的文件系统全备份、增量备份或差分备份，就可让您的系统快速轻松地恢复在线，投入到业务中去。

考虑到现在用户使用Windows系统很普遍，而且业务工作的24*7的不间断，我们对于Windows系统下的灾难恢复提供了在线的灾难备份，只要通过VaultDR Online Backup for Windows的插件就可以实现对整个系统进行在线的灾难恢复的系统备份，保证了用户的业务工作的连续性。

1.11自动化的备份管理

NetVault服务器可以通过在UNIX/LINUX/WINDOWS环境下统一的图形界面对备份系统进行集中管理，统一管理备份设备、备份介质和备份/恢复任务，并且能够统一定义管理备份策略和恢复策略。对备份设备和任务提供了完善的监控和诊断机制，具有邮件通知等主动报警机制。

1.13策略/安全管理

利用策略管理工具可以创建任务模板。该模板可以应用到任何的单个客户端或并行的应用到整个客户端组。基于策略，用户可以象管理一个任务那样对一组任务进行监控，管理，方便简单。

可以对某个用户或某一组用户进行权限设置，使不同的用户有不同的权限来访NetVault。保证数据的安全性。