级别： 初级 李扬 (liyangbj@cn.ibm.com ), 软件工程师, IBM
韩海燕 (hanhy@cn.ibm.com), 软件工程师, IBM
蔡翔 (caixiang@cn.ibm.com), 软件工程师, IBM
2009 年 7 月 06 日 Content Manager OnDemand 是 IBM 提供的企业级报表解决方案，Content Manager OnDemand 将报表相关的数据保存在关系数据库，文件系统和 Tivoli Storage Manager 中。本文将介绍 Content Manager OnDemand 产品的备份恢复解决方案，讨论如何备份报表相关的各部分数据，并给出备份恢复方案的最佳实践。
Content Manager OnDemand 简述
Content Manager OnDemand 是 IBM 内容管理产品家族中重要的一员，是 IBM 公司提供的企业级的报表管理解决方案。它为企业级的用户提供了强大的报表自动归档、集中管理和高速检索功能， 它帮助用户将成本高昂的打印输出转换成电子信息的捕获和显示，帮助用户节约了成本。
Content Manager OnDemand 拥有非常弹性的结构，并支持当前各种商业应用的数据类型，例如大型打印输出、计算机输出、事务类型报表、传真、扫描件、电子邮件、SAP 类型文档、Seibel 类型文档等等，甚至是以前的归档，例如磁盘、文件或胶片。
Content Manager OnDemand 体系结构
Content Manager OnDemand 系统由以下几部分组成：
- 库服务器（Library Server）：保存报表索引信息，系统配置信息和用户信息的数据库；
- 对象服务器（Object Server）：管理磁盘、光盘、磁带存储设备上的报表；
- 基于 TCPIP 网络协议和服务器连接的客户机。
图 1. Content Manager OnDemand 体系结构
Content Manager OnDemand 库服务器维护系统中报表文档的元数据。该数据库还包含系统中定义的对象信息，例如用户、组、应用程序、应用程序组、文件夹、存储集等等。库服务器处理客户端登录、查询、打印、日志以及对数据库的更新操作。
Content Manager OnDemand 对象服务器管理保存在缓存存储卷上的报表，也可以通过存储管理软件 Tivoli Storage Manager（TSM）来管理保存在归档介质上的文档，例如存放于光盘和磁带存储库上的报表文档。对象服务器加载数据，检索文档，并可以对文档做自动过期处理。
Content Manager OnDemand 报表系统备份方案
本部分将以一个实例讲解 Content Manager OnDemand 系统的备份，该实例中 Content Manager OnDemand 服务器运行在 AIX 操作系统上，使用 DB2 数据库服务器，并使用 TSM 管理离线存储的报表。
关于操作系统，数据库以及 TSM 的备份，存在多种方法可供选择，已经有很多的文章和书籍做过介绍。本文结合 Content Manager OnDemand 系统，提及一些它们的备份方法和策略，不做详细的介绍，本文的重点在于 Content Manager OnDemand 报表系统的备份。
Content Manager OnDemand 备份内容
最简单的 Content Manager OnDemand 架构是由一个库服务器和一个对象服务器在同一台物理系统上。用户可以在该架构中加入 TSM 存储管理软件，用于维护归档介质上的报表文档。
用户同样可以这样配置 Content Manager OnDemand 系统，一个库服务器在一个节点上，而一个或多个对象服务器在其它不同的节点上。该配置也被称为分布式的库服务器 / 对象服务器系统。
图 2. Content Manager OnDemand 备份内容
无论采用哪种配置，Content Manager OnDemand 的报表数据保存为以下几个部分，需要分别备份：
- Content Manager OnDemand 服务器运行的操作系统
库服务器和对象服务器据需要操作系统软件来正常运行。
- 关系数据库系统
存在于库服务器上，用来保存报表的索引信息和系统的控制信息。 Content Manager OnDemand 支持三种数据库，IBM DB2, ORACLE 和 MicroSoft SQL SERVER 。
- 磁盘高速存储系统
存在于对象服务器上，存放 Content Manager OnDemand 报表的近线数据，提高报表访问的速度。
- TSM 存储管理系统
用于保存 Content Manager OnDemand 的远线数据，用于长期保存报表。
- Content Manager OnDemand 的用户定制文件
包括配置文件，用户出口程序，AFP 资源文件等等。
备份操作系统
在 Content Manager OnDemand 报表系统初次安装完成，需要对操作系统进行备份；在每次系统升级或者软件打补丁之前，需要对操作系统进行备份。备份操作系统可以加速报表系统的恢复时间，备份时既可以使用操作系统自带命令，也可以使用备份软件进行备份。
对于 AIX 操作系统，可以使用如下的操作系统命令进行备份：
/usr/bin/mksysb '-i' '-X' '-p' /dev/rmt0 |
该命令是将操作系统备份到 /dev/rmt0 对应的磁带设备。
用户同样也可以使用 NIM 等软件进行网络备份。
备份数据库系统
关系数据库系统中主要维护者报表系统的索引信息，系统配置信息，用户安全信息等等。数据库系统随着生产运行时间的推移，数据量会变得越来越大，合理的规划数据库的备份是非常关键的。
按照数据库备份的方式，可以分为离线备份和在线备份。按照数据库备份的策略，可以分为全备份和增量备份。
离线备份需要停止 Content Manager OnDemand 报表系统，在线备份可以在用户访问报表系统的时候进行。全备份备份整个数据库，备份时间较长，但恢复时比较方便。增量备份只备份更改的数据，备份时间较短，但恢复时需要的时间较长。
下面以 DB2 为例来描述数据库系统的备份方法和策略。我们可以利用数据库本身提供的命令对数据进行备份。
表 1. DB2 的备份命令
| 备份命令 | 说明 | | db2 backup db archive to \backup | 离线全备份到文件系统 | | db2 backup db archive incremental use TSM | 离线增量备份到 TSM | | db2 backup db archive online to \backup | 在线全备份到文件系统 | | db2 backup db archive online incremental use TSM | 在线增量备份到 TSM |
Content Manager OnDemand 系统也提供相应的命令对数据库进行备份。
表 2. Content Manager OnDemand 的备份命令
| 备份命令 | 说明 | | arsdb -y \backup | 离线全备份到文件系统 | | arsdb -Y ADSM | 离线增量备份到 TSM | | arsdb -z \backup | 在线全备份到文件系统 | | arsdb -Z ADSM | 在线增量备份到 TSM |
在我们的实例中，使用 DB2 的备份命令，每周日在线全备份数据库到 TSM 。
# db2 backup db archive online use tsm
Backup successful. The timestamp for this backup image is:20090513010855 |
对数据库备份主要是对数据库和日志文件的备份，Content Manager OnDemand 为归档 DB2 数据库日志文件归档提供了两个出口程序，db2uext2.disk 和 db2uext2.tsm 。建立 Content Manager OnDemand 实例时可以选择需要的出口程序，选择 db2uext2.disk, 归档日志就会自动归档到配置文件指定的磁盘文件目录下；选择 db2uext2.tsm，归档日志就会自动归档到 TSM 保存，这里不再赘述。
备份 Content Manager OnDemand 磁盘缓存
磁盘高速缓存存放的是 Content Manager OnDemand 报表近线数据。一般数据会被装载到高速缓存磁盘和 TSM 管理的存储介质。但是如果报表设置为只是存储在高速磁盘缓存，那高速磁盘缓存备份就显现的非常重要和关键。
Content Manager OnDemand 可以配置多个磁盘高速缓存，对应操作系统上的一个文件系统。可以使用 tar 或是 cpio 等操作系统命令备份磁盘缓存；也可以使用 TSM 等备份软件备份。
在实例中，使用 TSM 的备份命令，备份磁盘缓存。
dsmc selective /archive/arscache/cache1/ -subdir=yes
dsmc selective /archive/arscache/cache2/ -subdir=yes
dsmc selective /archive/arscache/cache3/ -subdir=yes |
在备份磁盘高速缓存的时候不要破坏其目录结构，Content Manager OnDemand 是根据 retr 目录中连接文件来定位报表，并把报表内容返回给客户端。
备份 Content Manager OnDemand 定制文件
在运行中的 Content Manager OnDemand 报表系统中，存在用户定制的各种文件，同样需要对他们进行备份。定制文件主要包括下面几种类型：
- Content Manager OnDemand 配置文件
- ars.cfg 是 Content Manager OnDemand 报表系统的服务器配置信息文件
- ars.dbfs 是 Content Manager OnDemand 报表系统的数据库表空间配置信息文件
- ars.cache 是 Content Manager OnDemand 报表系统的高速缓存配置信息文件
- ars.ini 是 Content Manager OnDemand 报表系统实例配置文件
- Content Manager OnDemand 出口程序。 Content Manager OnDemand 报表系统提供了多种出口程序，帮助用户客户化和定制自己的需求处理。 Content Manager OnDemand 有以下几类出口程序：
- 安全性用户出口程序
- 检索浏览用户出口程序
- 报表规范归档定义出口程序
- 系统日志出口程序
- 表空间创建出口程序
- 下载用户出口程序
- Content Manager OnDemand 资源文件的备份。资源文件主要指的是 AFP 文档需要的页定义，表格定义以及字库等文件。
备份这些文件既可以使用操作系统命令，也可以使用备份软件提供的方法。
在我们的实例中，使用 TSM 的备份命令对 Content Manager OnDemand 配置文件进行备份。
dsmc selective /usr/lpp/ars/config/ars.cfg /usr/lpp/ars/config/ars.dbfs
/usr/lpp/ars/config/ars.cache /usr/lpp/ars/config/ars.ini |
备份 TSM 系统
Content Manager OnDemand 作为 TSM 的客户端通过 TSM API 与 TSM 服务器通信，将报表数据存放在相应的存储池中，存储池根据各个方案设计不同，可能关联不同的存储介质， 磁盘，磁带或者光盘库。对于 TSM 的备份主要备份两个方面：TSM 数据库和 TSM 存储池。
对于 TSM 数据库，存在前滚（roll-forward）模式和正常模式两种选择。对于前滚模式，数据库可以恢复到损坏前的时间点；对于正常模式，数据库仅可以恢复到最后备份时的时间点。在我们的例子中，用下面的命令来备份 TSM 数据库。
tsm: SERVER1>set logmode rollforward
ANR2294I Log mode set to ROLLFORWARD.
tsm: SERVER1>backup db type=full devclass=filedevclass
ANR2280I Full database backup started as process 2.
ANS8003I Process number 2 started.
|
在备份数据库时使用的设备类 filedevclass 需要使用 TSM 命令提前定义好，请参考 TSM 相关文档。
备份 TSM 数据库后，建议备份 TSM 卷历史文件（volume history file）和设备类配置文件（device configuration file）。
tsm: SERVER1>backup volhist
Do you wish to proceed? (Yes (Y)/No (N)) y
ANR2463I BACKUP VOLHISTORY: Server sequential volume history
information was written to all configured history files.
tsm: SERVER1>backup devconf
Do you wish to proceed? (Yes (Y)/No (N)) y
ANR2394I BACKUP DEVCONFIG: Server device configuration
information was written to all device configuration files. |
对于 TSM 主存储池，可以将其备份到拷贝存储池中。在例子中，使用下面的命令来备份 TSM 主存储池。
tsm: SERVER1>backup stgpool dbstgpool1 odcopypool
ANS8003I Process number 2 started. |
其中，dbstgpool1 为主存储池，odcopypool 为拷贝存储池。关于存储池的定义，请参考 TSM 文档。该命令的执行结果可以在 TSM 服务器的日志中查到。
Content Manager OnDemand 报表系统恢复方案
本部分结合实际的例子来讨论 Content Manager OnDemand 报表系统的恢复方案。
恢复操作系统
如果硬件损坏或是操作系统软件损坏，我们需要恢复操作系统。对于不同的操作系统，可以使用不同的方法进行恢复。
通过磁带机设备对 AIX 操作系统的恢复，可以按照以下步骤恢复操作系统。
- 将操作系统 CD 放入光驱，并重新引导系统。
- 按 F1 键定义系统控制台
- 按 1 键选择英文并回车
- 按 3 键启动维护模式
- 放入 mksysb 磁带，按 4 键从系统备份安装
- 选择磁带机所对应的设备
- 按 1 键开始安装
- 按 1 键继续安装，在系统恢复全部完成后，系统将会自动重启。
用户也可以通过 NIM 进行网络恢复。
在操作系统恢复完成后，需要检查当前操作系统的软件更新情况、已安装软件（例如 DB2、Content Manager OnDemand、TSM）、已安装软件的版本和更新情况，如果与目标系统有不一致的情况，需要安装合适的软件更新。
恢复 TSM 系统
我们首先介绍 TSM 系统的恢复方法。在 Content Manager OnDemand 系统的备份过程中，数据库和磁盘缓存的备份都有可能保存在 TSM 中，因此在恢复数据库和磁盘缓存之前，需要首先恢复 TSM 系统。 TSM 的恢复包括数据库和存储池的恢复。
恢复 TSM 数据库
恢复前，请确认 TSM 配置文件（dsmserv.opt, dsmserv.dsk），卷历史文件和设备配置文件放入各自相应的目录中。具体设备配置文件和卷历史文件的位置可以在 dsmserv.opt 文件中找到。
dsmserv.opt 和 dsmserv.dsk 文件通常位于 AIX 上的 /usr/tivoli/tsm/server/bin 目录。
恢复数据库之前，如果数据库卷和日志卷已经损坏，使用 dsmfmt 命令来创建数据库和日志卷，使用 dsmserv format 命令来初始化数据库和日志卷。
dsmfmt -m -db /usr/tivoli/tsm/server/bin/db.dsm 16
/usr/tivoli/tsm/server/bin/db2.dsm 256
dsmfmt -m -log /usr/tivoli/tsm/server/bin/log.dsm 8
/usr/tivoli/tsm/server/bin/log2.dsm 72
dsmserv format 2 /usr/tivoli/tsm/server/bin/log.dsm /usr/tivoli/tsm/server/bin/log2.dsm
2 /usr/tivoli/tsm/server/bin/db.dsm /usr/tivoli/tsm/server/bin/db2.dsm |
在我们的例子中，使用 dsmserv restore 恢复数据库到最新的状态。
恢复 TSM 中的存储池
如果保留 Content Manager OnDemand 报表的 TSM 主存储池发生损坏，只要对应的 TSM 拷贝存储池处于在线状态，Content Manager OnDemand 可以从拷贝存储池中存取报表。
尽管如此，为了保证 TSM 系统的高可用性，在 TSM 系统不繁忙的时候使用下面的命令恢复主存储池。
tsm: SERVER1>restore stgpool dbstgpool1 copystgpool=odcopypool
ANR2040W This command attempts to restore all files in storage pool DBSTGPOOL1
which have previously been found to be damaged or which reside on a volume with
access mode "destroyed"; existing references to files in storage
pool DBSTGPOOL1 will be deleted from the database after the files have been restored.
Do you wish to proceed? (Yes (Y)/No (N)) y
ANR2110I RESTORE STGPOOL started as process 3.
ANS8003I Process number 3 started. |
其中，dbstgpool1 为主存储池，odcopypool 为拷贝存储池。
恢复 DB2 数据库
Content Manager OnDemand 提供 ARSDB 程序来备份 DB2 数据库，但是并没有用以恢复 DB2 数据库的定制命令 , 用户需要使用 DB2 的命令来恢复 Content Manager OnDemand 数据库。
如果 DB2 是通过 TSM 进行备份，需要首先配置正确的环境变量，确认 dsm.opt.db2 和 dsm.sys 文件是有效的。在 AIX 操作系统上，dsm.opt.db2 位于 /usr/tivoli/tsm/client/api/bin 目录中，dsm.sys 位于 /usr/tivoli/tsm/client/ba/bin 目录中。
用户可以使用 db2adutl 命令来查询 TSM 中的数据库备份。
此外，可以用以下命令来查询数据库的备份历史：
#db2 list history backup all for archive |
在我们的例子中，首先恢复保存在 TSM 上的 DB2 数据库的在线备份。
# db2 restore db archive use tsm taken at 20090513010855
SQL2539W Warning! Restoring to an existing database that is the same as the
backup image database. The database files will be deleted.
Do you want to continue ? (y/n) y
DB20000I The RESTORE DATABASE command completed successfully. |
接下来，前滚 DB2 数据库的日志，使数据库恢复到最近的一致时间点。：
# db2 rollforward db archive to end of logs and stop Rollforward Status
Input database alias = archive
Number of nodes have returned status = 1
Node number = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0000006.LOG - S0000006.LOG
Last committed transaction
= 2009-05-12-17.08.57.000000 UTC
DB20000I The ROLLFORWARD command completed successfully. |
恢复缓存目录
将已备份的文件复制回原来的位置就可以完成缓存目录的恢复。在实例中，使用 TSM 的恢复命令，恢复文件到磁盘缓存。
dsmc restore /archive/arscache/cache1/ -subdir=yes
dsmc selective /archive/arscache/cache2/ -subdir=yes
dsmc selective /archive/arscache/cache3/ -subdir=yes |
恢复 Content Manager OnDemand 定制文件
成功恢复 Content Manager OnDemand 的数据库、磁盘缓存和 TSM 系统后，为了使 Content Manager OnDemand 服务器能够正常运行，需要恢复 Content Manager OnDemand 的定制文件，包括服务器配置文件，用户出口程序，AFP 资源文件等等。
在例子中，使用 TSM 命令恢复 Content Manager OnDemand 的服务器配置文件。
dsmc restore /usr/lpp/ars/config/ars.cfg
dsmc restore /usr/lpp/ars/config/ars.dbfs
dsmc restore /usr/lpp/ars/config/ars.cache dsmc restore /usr/lpp/ars/config/ars.ini |
恢复完成后的操作
在所有恢复操作成功完成之后，需要运行下面的维护命令，既可以检查数据的完整性，又可以提高报表系统访问的性能。
表 3. 恢复完成后执行的命令
| 命令 | 说明 | | arsmaint -r | 优化应用程序组索引数据并使信息访问更加高效 | | arsmaint -v | 验证磁盘缓冲存储区所在文件系统，确认连接和权限的正确性 | | arsdb -m | 重组系统的数据表并优化数据库的信息访问 | | arsdb -s | 优化系统索引数据并使信息访问更加高效 |
备份恢复的最佳实践
数据一致性的考虑
在进行 Content Manager OnDemand 备份操作时，为了保证数据的一致性。请不要运行报表装载，迁移和过期操作。因为在这些操作运行过程中，磁盘缓存文件系统的内容和权限都处于不断变化的过程中。
在 Content Manager OnDemand 恢复操作完成后，有可能出现各个组件中数据不一致的情况。为了最大可能的恢复到最近的数据一致点，建议保留一个星期或者更长时间的原始报表数据，这样当恢复完成后，可以重新装载需要的报表数据。
磁盘缓存小文件的备份
磁盘高速缓存中保存的是大量的小文件，如果我们逐个备份这些文件到 TSM 上，在系统运行初期数据量小的情况也许是可行的。随时时间的推移，数据的累计，备份这些文件会变成费时费力的工作；另一方面，TSM 数据库需要更多的资源来管理这些备份。
因此，我们推荐办法是：把这些小文件打包成一个大文件，然后备份到 TSM 存储系统中。在恢复时，首先恢复这个大文件，然后再解包到相应的目录中。
tar -cvf cach1.tar /archive/arscache/cache1
dsmc selective cach1.tar |
Content Manager OnDemand 对象定义的备份
Content Manager OnDemand 服务器端包含各种对象定义，包括用户，组，应用程序，应用程序组，文件夹等。当备份 Content Manager OnDemand 数据库的时候，会同时备份这些对象定义。但是，如果用户仅仅是对象定义损坏，那么恢复整个数据库的代价太大。 Content Manager OnDemand 提供了本地服务器导出导入功能，可以将服务器对象的定义导出到本地服务器中备份。建议用户将本地服务器备份离线保存，在必要时再导入到原始服务器。
图 3. 导出对象定义
Content Manager OnDemand 组件的分散存储
Content Manager OnDemand 的报表数据分布于数据库系统、磁盘缓存和 TSM 系统中，建议将操作系统、数据库、磁盘缓存、TSM 数据库放置于不同的磁盘上。这样当某一组件的数据发生损坏时，可以单独进行恢复，无需恢复整个系统；另一方面，分散磁盘读写也可以提高 Content Manager OnDemand 系统访问的性能。
各种场景的恢复策略
在大多数情况下，我们并不需要重建整个 Content Manager OnDemand 系统，而是要根据具体情况来决定恢复策略。
- 人为因素：这是备份恢复操作最常见的场景，也是情况最为复杂的情况。由于管理员或是操作人员的不当操作，可能引起重要文件丢失等情况。如果只涉及软件不涉及数据，可以仅恢复操作系统即可；如果相关数据同样收到影响，则可以情况做数据库恢复、缓存恢复和 TSM 数据恢复。
- 硬件事故：如果是库服务器发生硬件事故，可以进行操作系统和数据库恢复操作。如果是对象服务器发生硬件事故，可能需要进行 TSM 数据恢复。
- 事务失败：基本上是 DB2 的事务处理过程中出现失败的情况，在这种情况下，没有必要进行恢复操作，可以利用 DB2 自身的机制进行回滚或者再次提交操作。
- 灾难：灾难意味着一切都不存在，幸存的数据可能也无法使用。灾难后的恢复是最大规模的恢复操作，所有的部分均需要做恢复，包括操作系统的恢复，数据库恢复、缓存恢复和 TSM 数据恢复。
结束语
Content Manager OnDemand 是 IBM 提供的企业级报表管理产品，本文讨论了 Content Manager OnDemand 产品的备份恢复解决方案，并给出了备份恢复方案的最佳实践。用户在实际的应用中，需要结合 Content Manager OnDemand 具体应用的场景，设计规划好相应的备份恢复方案。
免责声明
本文仅代表作者的个人观点，不代表 IBM 公司的立场。
参考资料 学习
获得产品和技术
- 使用可直接从 developerWorks 下载的 IBM 试用软件 构建您的下一个 Linux 开发项目。
讨论
作者简介  | | | 李扬是 IBM CSDL 的软件工程师，从事企业内容管理产品的测试工作。您可以通过 liyangbj@cn.ibm.com 与他联系。 |
| | | 韩海燕， IBM CSDL 的软件工程师，目前从事企业内容管理产品的测试工作，可通过 hanhy@cn.ibm.com 与其联系。 |
| | | 蔡翔，就职于 IBM 中国开发中心，主要负责 IBM ECM 企业内容管理产品线的测试工作。对 IBM 企业内容管理软件产品家族中各类产品均有测试经验，目前是 IBM 认证的 Content Manager 解决方案设计师和 DB2 数据库高级管理员。 |
对本文的评价
| 
