目前，关系数据库服务器为许多公司建立了信息主干。这些公司依赖于其数据库服务器的顺利运作，任何储运损耗都会给他们的业务带来极大的影响。需要谨记的是，备份对于每位 DBA 来说都是最重要的方面之一。必须经常进行备份。如果在紧急情况下无法从备份中还原，对于公司而言，会带来很严重的后果，对于负责这些任务的 DBA 而言，后果可能也很严重。

这是由两部分组成的系列文章的第 1 部分，该系列将讨论如何使用 IBM Tivoli Storage Manager (TSM) 实现 IBM Informix Dynamic Server (IDS) 的备份。本文将向您展示如何使用这些 IBM 工具实现备份解决方案，并提供关于如何实现它的一些有用提示。

在下面的文章中您将发现一些使用 TSM 产品时常见的术语。为了了解 TSM 与 IDS 的相互关系，有必要了解这些术语。

归档和备份对象

TSM 有两种不同的存储对象，分别称为归档和备份对象。二者之间的主要不同是备份对象可以处于活动或非活动状态，而归档对象则没有这种区分。

活动备份文件永远都不会到期；只有非活动备份对象才会到期（基于已在基础备份副本组中设置的属性）。

归档和备份副本组

下表总结了归档和备份副本组的属性以及它们位于 TSM 层次结构中的位置：

TSM 服务器
策略域
策略集
管理类
备份副本组	归档副本组
VEREXISTS 为仍然存在于客户机上的文件保留的最大备份版本号。不过，如果到达由 RETEXTRA 指定的保留时间，则忽略 VEREXISTS	RETVER 归档副本被保留的天数
VERDELETED 为已从客户机上删除的文件保留的最大备份版本号	RETINIT 在 CREATION 或 EVENT 指定的保留时间开始时指定
RETEXTRA 备份版本变为非活动后保留该版本的天数	RETMIN 保留归档副本的最大天数
RETONLY 保留已从客户机上删除的某一对象的最新备份版本的天数

策略域是一个逻辑分组实体。TSM 提供了一个指定为标准策略域的默认策略域。TSM 管理员可以定义其他策略域。

在策略域中存在一些策略集。策略集是一个或多个管理类的逻辑分组。只有单个策略集在某一时间可以是活动的。

每个策略集都包含一个默认管理类，以及一个或多个其他管理类。管理类由归档和备份副本组组成。这些副本组包含一些至关重要的属性，这些属性控制着某种类型的对象（归档或备份对象）的到期时间。关于已配置管理类的细节信息，可以通过 'dsmc query mgmtclass -detail' 命令获得。

在注册 TSM 客户机节点期间，该节点将被绑定到单个策略域（默认情况下为标准策略域），并对此策略域使用活动策略集。因此，在此 TSM 客户机节点名称下备份的对象将分配给此策略域的活动策略集中定义的管理类。

IDS 备份实用程序

Informix 提供了两个独立的备份实用程序：

ontape
onbar

过去还有一个名为 onarchive 的一个备份实用程序。不过，onarchive 实用程序不再随 IDS V9.4 和 IDS 以后的版本提供。

Ontape 实用程序

有了 ontape，就可以进行在线备份。这些备份可以发送到磁带（本地或远程）、磁盘或使 ontape 非常灵活的管道。不过，不能将备份并行化，并且没有直接到存储管理器的接口。

为了在 TSM 中存储 ontape 备份，可以在磁盘上做备份，然后使用 TSM dsmc 实用程序将备份发送到 TSM。有一些 Informix 客户就是以这种方式执行他们的备份；不过我们不打算在这里讨论这种可能性。

Onbar 实用程序

其他 Informix 备份实用程序被称为 onbar (Online Backup Archive)。Onbar 使用 XBSA 接口 (X/Open Backup Services API) 与第三方存储管理器通信。使用 onbar 可以将备份并行化，还能执行指定时间点的备份。Informix 存储管理器 (ISM) 与 IBM IDS 绑定在一起，后者允许客户在不脱离第三方存储管理器的情况下使用 onbar。

外部备份和还原

IDS 还能与复杂磁盘子系统提供的分离镜像 (split mirror) 技术一起使用。此方法称为 EBR (External Backup Restore)。对于这类备份，IDS 允许通过 'onmode -c block' 阻塞数据库服务器，从而实现一致状态。在还原期间，IDS 能够将外部物理还原与逻辑还原组合在一起。本文不再进一步讨论 EBR 方法。

如果正在使用 IDS V7.x 或 V9.x，要将备份从 onbar 发送到 TSM，则需要称为 Data Protection for Informix 的 IBM Tivoli 产品。Data Protection for Informix 现在与 IDS V10 绑定在一起。我们将在下面的章节中讨论此接口。

数据库服务器对象

以下示例将使用服务器编号为 67 的、名为 ids10 的一台 Informix 数据库服务器。

IDS 有两种可以使用 onbar 进行备份的数据库服务器对象：

Dbspaces
Logical logs

正如已经提到的那样，这两种类型都将存储为 TSM 备份对象，并且不可能定制此行为。IDS 总是生成备份对象。

备份储存库

IDS 在称为 sysutils 的数据库中存储关于每种备份操作（dbspaces 和 logical logs 备份）的信息。此数据库是在第一次初始化数据库服务器时自动创建的，它包含一些使用有关已执行备份的信息填充的表。可以使用 SQL 选择 sysutils 数据库中的数据。

除了 sysutils 数据库之外，IDS 还在称为紧急启动 文件的文本文件中存储信息。紧急启动文件 位于以下地方：

$INFORMIXDIR/etc/ixbar.

紧急启动文件 需要进行冷还原。冷还原是在数据库不可用且无法访问 sysutils 数据库的情况下进行的还原。Onbar 从紧急启动文件中获得必要的信息。在执行热还原期间，数据库服务器处于在线状态，并且 onbar 将查询 sysutils 数据库来获得关于备份的信息。

备份的类型

IDS 允许执行 dbspaces 和 logical logs 这两种类型的备份。这两种备份都将使用 onbar 实用程序来执行。logical logs 备份是使用 Informix ALARMPROGRAM 机制配置的。

Informix 对两种不同类型的 dbspace 备份进行了区分：

全系统备份 (Whole-system backup)
并行备份 (Parallel backup)

这两种类型的备份都可以在数据库服务器处于在线状态和执行事务时执行。

全系统备份

全系统备份是某一指定时间点（即归档检查点）上整个系统的快照。全系统备份是连续执行的（一个 dbspace 备份完成后接着另一个 dbspace 备份），并且可以不使用任何逻辑日志来还原它们。如果没有逻辑日志，则系统被还原到某个一致的点上，即归档检查点。归档检查点上存在的所有打开事务都将被回滚。

并行备份

并行备份允许同时进行几个 dbspaces 备份（由 $ONCONFIG 参数 BAR_MAX_BACKUP 控制），如果基础设施够用，那么这样做可缩短总体备份时间。不过，在执行这种备份时，将依靠逻辑日志到达某个一致的点。

如果计划执行并行备份或者希望能够执行指定到某一时间点的还原，则确保定期备份逻辑日志就非常重要。Informix 的 IDS V10 之前的版本不允许在没有保存逻辑日志的情况下进行并行备份。不过，在进行这种情况的还原时，无法使数据还原，因为需要逻辑日志来达到并行模式下执行的备份的某个一致点。

确保 $ONCONFIG 参数 LTAPEDEV 被设置为不同于 /dev/null 的值，并且配置好的 ALARMPROGRAM 能够使用 onbar 进行日志备份。如果 LTAPEDEV 被设置为 /dev/null，那么只要发生日志切换，逻辑日志就将被标记为已备份。逻辑日志不会被保存（请参阅 IDS/Onbar 的配置）。

备份级别

对于这两种类型的备份（全系统备份和并行备份），都可以指定备份级别，例如，如果此备份应该是一个完全备份或增量备份：

0 级备份 (Level-0-Backup)
- 对所有已使用页面进行备份
1 级备份 (Level-1-Backup)
- 只备份自上一次 0 级备份后发生更改的页面
2 级备份 (Level-2-Backup)
- 只备份自上一次 0 级备份后发生更改的页面。如果上一次备份是一个 0 级备份，则 2 级备份将与 1 级备份相同。

增量备份非常合理，因为它们减少了还原数据库服务器所需的时间。先应用 Level-0-Backup，然后再进行增量备份，这将比通过大量逻辑日志进行前滚更快。

还原的类型

IDS 对以下还原类型进行了区分：

冷还原

如果任何关键 dbspaces（比如根 dbspace，这些 dbspace 包含逻辑日志或物理日志）出错，则必须执行冷还原。在执行冷还原期间，数据库服务器将不可用。

热还原

热还原可以在只是非关键 dbspace 出错时执行。在执行热还原期间，数据库服务器是可用的，并且可以选择和更新没有包含在当前已还原 dbspace 中的任何数据。

混合还原

混合还原是冷还原和热还原的组合。关键 dbspace（和一些可能不太关键的 dbspace）是在脱机模式下还原的。完成此还原操作之后，数据库服务器回到在线模式下，然后将还原剩余的 dbspace。此方法允许 DBA 先还原最重要的数据，使用户在联机模式下还原较次要的重要数据之前可以使用它们。

Point-In-Time/Point-In-Log 还原

这些类型的还原依赖于逻辑日志中的信息。数据库服务器可以还原到某一特定时间点上，也可以还原到某一特定逻辑日志。以下这一点要重点注意，在两种情况下，整个数据库服务器都将被还原到指定的时间点或逻辑日志。个别 dbspace 无法还原到某一时间点或逻辑日志。

配置 TDP/OnBar

TDP 的配置

单独的 TDP for Informix 产品只需要使用 IDS 10 以上的版本即可。IBM 产品手册（请参阅参考资料）中描述了安装和配置 TDP for Informix 的完整过程。为了提供必需的配置值，您需要来自 TSM 系统管理员的协助。

请注意，32 位的 IDS 实例必须使用 32 位的 TDP/Informix 组件，而 64 位的 IDS 则必须使用 64 位的 TDP/Informix 组件。

32 位的 IDS 在版本号中有一个 U 标识符，例如：

10.00.UC4

64 位的 IDS 在版本号中有一个 F 标识符，例如：

10.00.FC4

32 位和 64 位的 TDP/Informix 通常安装在相同的基本目录中，64 位的 TDP/Informix 将标识符 64 追加到路径名的末尾，如下所示：

32-bit: /usr/tivoli/tsm/client/informix/bin
64-bit: /usr/tivoli/tsm/client/informix/bin64

以下是根用户应该执行的个别步骤的简要概括。如果正使用 IDS V10，则不需要执行步骤 2。TDP/Informix 也称为 TXBSA，它已经包含在 IDS 10 中。

安装 TSM/API
- TSM/API 是基础，TDP/Informix 使用 TSM/API 向 Tivoli Storage Manager 发送数据并接收来自 Tivoli Storage Manager 的数据。TSM/API 包可在 TDP/Informix 软件 CD ROM 上使用。安装是使用本机操作系统过程（参见下面部分）来执行的。
安装 TDP/Informix
- 该软件是使用本机操作系统包安装过程（如 smitty）来安装的，在 IBM AIX® 上使用的是 installp 命令，在 Sun Solaris 上使用的是 pkgadd 命令。默认安装目录取决于您的平台：
  - AIX (TSM API): /usr/tivoli/tsm/client/api/bin[64]
  - AIX (TDP/IFX): /usr/tivoli/tsm/client/informix/bin[64]
  - Solaris (TSM API): /opt/tivoli/tsm/client/api/bin[64]
  - Solaris (TDP/IFX): /opt/tivoli/tsm/client/informix/bin[64]
  在 IDS V10 中，TXBSA 库可从 $INFOMIXDIR/lib 中获得。
定义环境变量
- DSMI_CONFIG
  - 客户机用户选项文件的完全路径名 (dsm.opt)
- DSMI_DIR
  - TSM API 安装路径的完全路径名（只在不使用默认路径安装时是必需的）
- DSMI_INF_DIR
  - TDP/Informix 安装路径的完全路径名（只在不使用默认路径安装时是必需的）
- DSMI_LOG
  - 应该在其中创建 TSM API 错误日志文件 (dsierror.log) 的目录的完全路径名
编辑客户机系统选项文件 (dsm.sys)
- 为这组条目指定一个逻辑名称 (server stanza)。在 dsm.sys 文件中，可以有几个 server stanzas。将要使用的 server stanza 是通过以下降序排列的优先级顺序来确定的：
  1. 客户机用户选项文件 (dsm.opt) 中的 SERVERNAME 集
  2. 客户机系统选项文件 (dsm.sys) 中的 DEFAULTSERVER 条目
  3. 客户机系统选项文件 (dsm.sys) 中的第一个 server stanza
- 将 PASSWORDACCESS 设置为 GENERATE。这可以确保 TSM 不会询问口令，因为 onbar 无法处理它。加密口令存储在本地（文件名 TSM.PWD 的文件中），原有口令到期时，还会自动生成一个新口令并本地存储该口令。
- 指定 NODENAME，客户机应该在这之下联系 TSM 服务器。如果没有指定 NODENAME ，则使用机器的主机名。
- 将 INCLEXL 参数设置为 inclexcl.def 文件的完全路径。
- 为了标识 TSM 服务器，还需要设置其他几个参数，比如 COMMETHOD、TCPSERVERADDRESS 和 TCPPORT。TSM 管理员应该知道这些参数。
编辑客户机选项文件 (dsm.opt)
- 将 SERVERNAME 设置为指向客户机系统选项 (dsm.sys) 的适当 server stanza。
向 inclexcl.def 文件添加条目
- 添加条目，以便为 IDS 备份文件分配适当的管理类（请参阅管理类的分配）。inclexcl.def 文件的位置是使用 dsm.sys 文件中的 INCLEXCL 参数配置的。
在 TSM 服务器上注册客户机节点
- TSM 管理员应该在 TSM 服务上您所期望的 NODENAME 下注册 TSM 客户机节点。在请求注册节点时，不需要 BACKDEL（删除备份对象）权限，因为 onsmsync（IDS 提供的存储管理器同步实用程序）只对逻辑日志执行 BSAMarkObjectInactive() XBSA 调用。此调用可以在没有 BACKDEL 权限的情况下执行，因为这些对象是非活动，没有被删除。
初始化 TSM 口令
- 运行 tdpipswd，它是随 TDP/Informix 一起提供的。在 IDS V10 中，TXBSA 已经被绑定，以下程序将被调用：
  - $INFORMIXDIR/bin/txbsapswd

IDS/OnBar 的配置

对于 TDP/Informix，IDS 配置部分非常简单。应该在 $INFORMIXDIR/etc/$ONCONFIG 文件中设置以下参数：

BAR_BSALIB_PATH
- 如果正在使用 IDS 10 以前的版本，则将此参数设置为 TDP/Informix 提供的 XBSA 库的完全路径名：
  - AIX: /usr/tivoli/tsm/client/informix/bin[64]/bsashr10.o
  - Solaris: /opt/tivoli/tsm/client/informix/bin[64]/libTDPinf.so
  根据 AIX 上使用的 TDP/Informix 版本，对象文件 bsashr10.o 可能无法直接使用。如果是这种情况，则必须使用 ar 命令从 libTDPinf 库中提取此对象文件：
  - cd /usr/tivoli/tsm/client/informix/bin[64]
  - ar x libTDPinf.a
  如果没有设置 BAR_BSALIB_PATH，IDS 还将尝试在默认路径下打开 XBSA 库。不过，该默认路径取决于使用的 IDS 版本，因此定义的 BAR_BSALIB_PATH 是不明确的。如果已经在 IDS V10 上，则将 BAR_BSALIB_PATH 设置为：
  - AIX: $INFORMIXDIR/lib/libtxbsa.a
  - Solaris: $INFORMIXDIR/lib/libtxbsa.so
BAR_ACT_LOG
- onbar 活动日志的完全路径名。该日志文件是用于与 onbar 相关的所有消息的主要日志文件。此文章系列的第 2 部分中将讨论可用于启动调试的其他参数。
创建 sm_versions 文件
- cd $INFORMIXDIR/etc
- cp -p sm_versions.std sm_versions
将 sm_versions 文件中的一个配置行更改为：
- 1||tsm|
LTAPEDEV 和 ALARMPROGRAM
- 备份逻辑日志一直是一个好主意，如果计划执行并行备份或想要执行指定到某一点的还原。那么备份日志非常重要。将 LTAPEDEV 设置为不同于 /dev/null 的值，并将 ALARMPROGRAM 设置为 $INFORMIXDIR/etc/log_full.sh。
RESTARTABLE_RESTORE
- 应该将此 $ONCONFIG 参数设置为 ON。它能保存有价值的时间，这样您不必从头开始，就可以继续中断的或失败的还原操作。

在完成这些更改之后，重新启动 IDS (onmode -ky && oninit)。现在应该能够使用 onbar 将 IDS 实例备份到 TSM。

可以通过在 onbar 活动日志文件上执行 tail -f 来监视正在进行的备份操作。此外，可以执行 onstat -g arc 命令来监视备份的进度。

管理类的分配

正如上面已经提到的，onbar 总是生成 TSM 备份对象。这些备份对象被绑定到特定管理类，而这些对象的存储则是根据基础备份副本组的属性进行的。

在 IDS 中，没有可用来指定用于备份的明确管理类的参数。$ONCONFIG 参数 ISM_DATA_POOL 和 ISM_LOG_POOL 只由 ISM 使用，所包含的存储管理器集成在 IDS 中。

将备份对象绑定到特定管理类是通过比较备份对象名称与 inclexcl.def 文件中设置的模式来外部实现的 (TSM API)。inclexcl.def 文件的位置是由客户机选项文件 (dsm.sys) 中的 INCLEXCL 参数确定的。默认位置是：

AIX: /usr/tivoli/ tsm/client/api/bin[64]/inclexcl.def
Solaris: /opt/tivoli/tsm/client/api/bin[64]/inclexcl.def

备份对象的名称

存储在 TSM 中的所有备份对象都有一个与之相关的名称。客户机 (onbar) 控制着此名称的以下关键组件：

FileSpaceName
- 对于 dbspace 和 logical logs 备份，在这里使用的是 IDS 实例 (DBSERVERNAME) 的名称。在 TSM 将相关数据聚在一起时，文件空间名称很重要。某些 TSM operations 操作是在文件空间级别上进行操作的。
HighLevelName
- 对于 dbspaces 备份，在这里使用的是 IDS 实例名称和个别 dbspace 名称的组合。对于 logical log 备份，使用的则是 IDS 实例名称和 IDS 服务器编号的组合。
LowLevelName
- 对于 dbspaces 备份，在这里使用的是备份级别（例如，级别 0、级别 1 或级别 2）。对于 logical log 备份，使用的则是逻辑日志 ID。。

inclexcl.def 条目

这里有两个用于 IDS 实例的 inclexcl.def 条目，该实例名为 ids10，编号为 67，对于 dbspaces 和 logical logs 备份有不同的管理类：

include /ids10/.../* IFX_LOG
include /ids10/.../[0-2] IFX_DB

模式匹配是从 inclexcl.def 文件的底部向上进行的。尽管第一个条目会匹配所有对象（dbspaces 和 logical logs），但仍会将 dbspace 备份正确地分配给管理类 IFX_DB，因为匹配是从下往上进行的，一旦发现存在匹配，就会停下来，对于 dbspaces 备份，停在条目 2 上。Logical log 备份对象名称不会与条目 2 匹配，它们将与条目 1 匹配，因此将为它们分配管理类 IFX_LOG。

不过可以更改 inclexcl.def 中的条目 1 来阐明这一区别：

include /ids10/.../67/* IFX_LOG

没有发现匹配条目的备份对象被绑定到活动策略集中的默认管理类。

有可能将一个拒绝接纳的条目放置在 inclexcl.def 文件的第一行中，以防止到不匹配对象的默认管理类的隐式绑定，例如：

exclude /.../*

如果在 inclexcl.def 中发现不匹配条目，则向客户机返回一条错误，因为将每个备份对象绑定到管理类非常重要。如果无法做到这一点，则 TSM 将返回 XBSA 错误代码 96 (0x60)。

查询 TSM

可以使用 TSM 命令行工具 dsmc 控制管理类到备份对象的正确分配。以下是为名为 ids10、服务器编号为 67 的 IDS 实例检索备份对象名称的一些示例：

dsmc 命令	描述
query backup 'ids10/*'	显示所有活动备份对象的名称（dbspaces 和 logical logs 备份都适用）
query backup -inactive 'ids10/*'	显示所有活动和非活动备份对象的名称（dbspaces 和 logical logs 备份都适用）
query backup 'ids10/ids10/67/*'	只显示引用于 logical logs 备份的活动备份对象名称
query backup 'ids10/*' -fromnode=ifx_node	显示用于专用节点名称 ifx_node 下所执行备份的所有活动备份对象名称
query mgmtclass -detail	显示关于活动策略集中管理类的细节信息

来自 dsmc 命令的示例输出

				
dsmc query backup -inactive "/ids10/*"
	
Size               Backup Date        MgmtClass    A/I  File
----               -----------        ---------    ---  ----
API  4.194.304  B  09.11.2005 08:29:45    IFX_LOG   A   /ids10/ids10/67/100
API  1.892.352  B  21.12.2005 11:39:02    IFX_LOG   A   /ids10/ids10/67/101
API  4.194.304  B  08.11.2005 10:25:55    IFX_LOG   I   /ids10/ids10/67/95
API  4.194.304  B  08.11.2005 10:27:11    IFX_LOG   I   /ids10/ids10/67/96
API  4.194.304  B  08.11.2005 11:59:28    IFX_LOG   A   /ids10/ids10/67/97
API  4.194.304  B  08.11.2005 12:00:01    IFX_LOG   A   /ids10/ids10/67/98
API  4.194.304  B  08.11.2005 12:08:49    IFX_LOG   A   /ids10/ids10/67/99
API 13.438.976  B  21.12.2005 11:38:32    IFX_DB    A   /ids10/ids10/ehtest/0
API    184.320  B  03.08.2005 12:32:56    IFX_DB    A   /ids10/ids10/ehtest/1
API 42.160.128  B  21.12.2005 11:38:35    IFX_DB    A   /ids10/ids10/logdbs/0
API 42.147.840  B  03.08.2005 12:32:56    IFX_DB    A   /ids10/ids10/logdbs/1
API    217.088  B  21.12.2005 11:38:35    IFX_DB    A   /ids10/ids10/physdbs/0
API 10.690.560  B  03.08.2005 12:32:56    IFX_DB    A   /ids10/ids10/physdbs/1
API 27.549.696  B  21.12.2005 11:38:06    IFX_DB    A   /ids10/ids10/rootdbs/0
API 15.728.640  B  03.08.2005 12:27:02    IFX_DB    A   /ids10/ids10/rootdbs/1
API    738.900 KB  03.08.2005 14:38:21    IFX_DB    I   /ids10/ids10/logdbs/0
API    736.200 KB  08.11.2005 12:08:19    IFX_DB    I   /ids10/ids10/logdbs/1

除了分配的管理类之外，还可以查看列 A/I 中个别备份对象的状态（Active 或 Inative）。

IDS/OnBar 及TSM来实现功能强大的备份和还原