Informix OnBar 和 Tivoli Storage Manager
配置和使用 IDS/OnBar 及 Tivoli Storage Manager 来实现功能强大的备份和恢复
IDS允许数据库管理员将数据库备份直接发送到外部存储管理器。IDS V10 已经包含将其连接到 IBM Tivoli Storage Manger (TSM) 所必需的
库。
TSM 术语
归档和备份对象:
TSM 有两种不同的存储对象，分别称为归档 和备份 对象。二者之间的主要不同是备份对象可以处于活动或非活动状态，而归档对象则没有这
种区分。
活动备份文件永远都不会到期；只有非活动备份对象才会到期（基于已在基础备份副本组中设置的属性）。
归档和备份副本组:
下表总结了归档和备份副本组的属性以及它们位于 TSM 层次结构中的位置：
TSM 服务器
策略域
策略集
管理类
备份副本组 归档副本组
VEREXISTS
为仍然存在于客户机上的文件保留的最大备份版本号。不过，如果到达由 RETEXTRA 指定的保留时间，则忽略 VEREXISTS
RETVER
归档副本被保留的天数
VERDELETED
为已从客户机上删除的文件保留的最大备份版本号
RETINIT
在 CREATION 或 EVENT 指定的保留时间开始时指定
RETEXTRA
备份版本变为非活动后保留该版本的天数
RETMIN
保留归档副本的最大天数
RETONLY
保留已从客户机上删除的某一对象的最新备份版本的天数
策略域是一个逻辑分组实体。TSM 提供了一个指定为标准策略域的默认策略域。TSM 管理员可以定义其他策略域。
在策略域中存在一些策略集。策略集是一个或多个管理类的逻辑分组。只有单个策略集在某一时间可以是活动的。
每个策略集都包含一个默认管理类，以及一个或多个其他管理类。管理类由归档和备份副本组组成。这些副本组包含一些至关重要的属性，这
些属性控制着某种类型的对象（归档或备份对象）的到期时间。关于已配置管理类的细节信息，可以通过 'dsmc query mgmtclass -detail'
命令获得（请参阅查询 TSM）。
在注册 TSM 客户机节点期间，该节点将被绑定到单个策略域（默认情况下为标准策略域），并对此策略域使用活动策略集。因此，在此 TSM
客户机节点名称下备份的对象将分配给此策略域的活动策略集中定义的管理类。
IDS 备份实用程序
Informix 提供了两个独立的备份实用程序：ontape.onbar
过去还有一个名为 onarchive 的一个备份实用程序。不过，onarchive 实用程序不在IDS V9.4及 以后的版本提供。
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 能够将外部物理恢复与逻辑恢复组合在一起。
如果正在使用 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 在称为 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 以上的版本即可。
请注意，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 命令默认安装目录取决于您的平台：
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 是通过以下
降序排列的优先级顺序来确定的：
客户机用户选项文件 (dsm.opt) 中的 SERVERNAME 集
客户机系统选项文件 (dsm.sys) 中的 DEFAULTSERVER 条目
客户机系统选项文件 (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 将相关数据聚在一
起时，文件空间名称很重要。某些 TSM operations 操作是在文件空间级别上进行操作的。
HighLevelName
对于 dbspaces 备份，在这里使用的是 IDS 实例名称和个别 dbspace 名称的组合。对于 logical log 备份，使用的则是 IDS 实例名称和
IDS 服务器编号的组合。（请参阅 查询 TSM）
LowLevelName
对于 dbspaces 备份，在这里使用的是备份级别（例如，级别 0、级别 1 或级别 2）。对于 logical log 备份，使用的则是逻辑日志 ID。（
请参阅 查询 TSM）。
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）。
