问题
对于 IDS 实例 ids10，根 dbspace 的 0 级备份将命名为：
增量备份（1 级和 2 级）将有以下与之关联的备份对象名称：
- /ids10/ids10/rootdbs/1
- /ids10/ids10/rootdbs/2
Dbspace 备份对象将自动进入不活动状态，因为相同级别（例如 0 级、1 级、2 级）的一个新的备份将拥有和之前一致的备份对象名称，因而之前的那个版本将进入不活动状态。
乍一看来，为 dbspaces 重用备份对象名称似乎是一种好方法，因为之前的版本将自动切换至不活动状态。在这种情况下，TSM 根据底层备份拷贝组的设置使那些对象到期。
但是，当您想用不同的管理类存储备份时，这种技术就显现出一个陷阱。如果每周做一次 0 级备份，每天做一次 1 级备份，并且都是为期一个月（例如 TSM 管理类 MC31）。在一个季度的季末，要做一次 0 级备份，并且为期 1 年（例如 TSM 管理类 MC365）。一种可行的方法是使用两个不同的 inclexcl.def
文件，其中默认的 inclexcl.def 将包含以下关于每日备份的条目：
- include /ids10/.../[0-2] MC31
对于每季一次的备份，应该在 inclexcl.def 中将以上条目替换为：
- include /ids10/.../[0-2] MC365
这时出现的问题是，TSM 将对所有具有相同名称的备份对象执行管理类的重新绑定。因此，之前每周执行的 0 级备份现在将被绑定到管理类 MC365。顺便说一下，所有具有相同备份对象名称的版本，不管是活动的版本还是不活动的版本，都将被重新绑定。
这还不算糟糕，真正的问题是在以后用初始的 inclexcl.def 条目做每周的 0 级备份时出现的。现在每季度做的 0 级备份将被重新从管理类
MC365 绑定到 MC31。所以，当您将来需要恢复每季度的备份时，这个备份却很可能不可用了。
解决方案
为了防止上述行为，必须为每季度的备份注册一个专用的节点名。通常，TSM 节点名与客户机的主机名相对应，但是也可以为同一台客户机注册好几个节点名。TSM 管理员必须在 TSM 服务器上执行新节点名的注册。完成注册之后，就可以在专用的 TSM 节点名下执行每季度的备份了。
由于无法直接告诉 OnBar 去使用这个专用节点名，所以必须更改客户机系统选项文件（dsm.sys）。在 dsm.sys 文件中更改（或添加）与专用节点名相关的 NODENAME 参数。然后，便可以使用 OnBar 执行 0 级备份。这个过程可以确保备份是在专用节点名之下进行的，从而可以防止已有备份对象被重新绑定管理类。
值得一提的是，您应该以完全系统备份的形式来执行每季度的备份，例如指定 OnBar 选项 '-w'。
完全系统备份确保能够在不应用逻辑日志的情况下恢复备份。修改后的 inclexcl.def 应该包含以下两个条目：
- exclude /.../*
- include /ids10/.../[0-2] MC365
exclude 条目确保逻辑日志不会备份在专用节点名之下，否则在恢复每日的备份时将出现麻烦。这种情况下将出现的问题是，有些逻辑日志存储在一般节点名下，另一些逻辑日志又存储在专用节点名下。因此，在逻辑恢复期间，OnBar 就能够发现存储在一般节点名之下的逻辑日志，而不是那些存储在专用节点名之下的逻辑日志，除非您使用 'dsmc set access...' 授予适当的访问权限（请参阅 导入恢复 一节）。
可取的做法是，总是将逻辑日志存储在一般节点名之下，省略用于日志的条目，并在修改的 inclexcl.def 中指定一个 exclude 条目。这种方法将导致在 0 级备份期间，当出现日志切换、触发 ALARMPROGRAM 并试图备份未保存的逻辑日志时，OnBar 活动日志中出现以下错误消息：
OnBar 活动日志中的错误消息
... Successfully connected to Storage Manager.
... XBSA Error (BSACreateObject): An unspecified XBSA error has occurred: 96
... /usr/informix/bin/onbar_d: process exit 96 (0x60)
|
这条错误消息可以忽略。在 0 级备份完成，并且恢复了 dsm.sys 中的初始节点名之后，逻辑日志将被保存。下一次的日志切换将使用 ALARMPROGRAM 机制（例如 'onbar -b -l'） 在初始节点名下备份所有未保存的日志。应确保配置了足够多的逻辑日志空间，以防在进行每季度的备份时出现日志已满的状况。
也可以创建一种完全去耦的 dsm.sys 配置，该配置只是为这种每季度的备份而考虑的。在运行每季度的 0 级备份时，逻辑日志仍然可以由 ALARMPROGRAM 备份。为实现这一点，可以创建一个专用目录，其中包含用于所有文件（除了 dsm.sys）到初始 DSMI_DIR 目录的符号链接。在这种新配置中，可以创建一个修改后的 dsm.sys 文件（更改 NODENAME 和 INCLEXCL 条目），然后在开始每季度的备份之前，将 DSMI_DIR 环境变量设置为该目录。
这样可确保修改过的 dsm.sys 设置仅用于这种专门的每季度的 0 级备份，而逻辑日志仍然由 ALARMPROGRAM 备份在初始节点名之下。这样便消除了在执行每季度备份时出现日志已满的状况的危险。在执行每季度的备份之后，您仍将收到上述 XBSA 0x96 错误，因为执行 0 级备份的 OnBar 进程试图将当前逻辑日志发送到 TSM（这个
OnBar 进程使用专用的节点名环境）。然而，如前所述，这一点不必担心，因为一旦出现下一次日志切换，受影响的逻辑日志将由 ALARMPROGRAM 保存起来。
上述过程并不妨碍您与在专用节点名之下执行的每季度备份一起使用这些逻辑日志，以执行时间点（Point-In-Time）恢复。
为完成该任务，需要将恢复过程划分成物理恢复和逻辑恢复，例如：
-
将节点名设置为用于每季度备份的专用节点名
-
只执行一次物理恢复
- 'OnBar -r -w -p -t <timestamp_of_quarterly_backup>'
-
重新将节点名设置为一般节点名
-
继续恢复操作，这次是逻辑恢复
- 'onbar -r -l -t <timestamp_for_point_in_time>'
如果您不想划分恢复操作，那么可以使用 'dsmc set access....'（请参阅 导入恢复 一节）授予适当的访问权限。
如果您想恢复一个 Whole-System-Backup（完全系统备份），那么并不需要指定 '-w' 标志。这是一种常见的误解。在恢复期间指定 '-w' 标志意味着应该由 OnBar 执行一次顺序的恢复（例如一个 dbspace 接一个 dbspace）。
如果省略 '-w' 选项，OnBar 仍可以恢复一个 Whole-System-Backup。在这种情况下，只有根 dbspace 被顺序地恢复，之后 OnBar 将派生出一些附加的 OnBar
进程（取决于 $ONCONFIG 参数 BAR_MAX_BACKUP）并且并行地恢复剩下的 dbspace。
在开始那样的并行恢复之前，必须在 $ONCONFIG 中将 LTAPEDEV 设置为与 /dev/null 不同的值。如果基础设施（磁盘、网络、TSM 服务器）合理的话，这样将大大减少恢复时间。在恢复过程的最后，在 OnBar 活动日志中可以看到一条如下所示的消息：
OnBar 活动日志中的警告消息
...WARNING: Physical restore complete. Logical restore required before work
|
这很容易使人产生误解。您不能恢复任何日志，因为您已经恢复了一个 Whole-System-Backup（以并行方式），而不是 Parallel-Backup。这时，可以执行 'onmode -m' 命令，使 IDS 数据库服务器上线。这个过程可能要花费几分钟的时间，因为要清除物理日志和逻辑日志。执行 'onstat -D -r' 监视相关 dbspace/块上的写操作。
Whole-System-Backup 由 emergency bootfile 的第 4 个位置中的 1 来标识。Parallel-Backup 在这个位置上的标识是 0：
Emergency Boot 文件
ids10 rootdbs R 1 117 0 0 .........
ids10 rootdbs R 0 112 0 0 .........
|
下面是 OnBar 活动日志的摘录，展示了顺序恢复与并行恢复之间的不同之处：
顺序物理恢复 ('onbar -r -w -p')
2006-01-01 17:00:25 45242 38228 Completed cold level 0 restore rootdbs.
2006-01-01 17:00:25 45242 38228 Begin cold level 0 restore logdbs.
2006-01-01 17:00:25 45242 38228 Completed cold level 0 restore logdbs.
2006-01-01 17:00:25 45242 38228 Begin cold level 0 restore physdbs.
2006-01-01 17:00:25 45242 38228 Completed cold level 0 restore physdbs.
2006-01-01 17:00:26 45242 38228 Completed whole system restore.
|
在单个 OnBar 进程中一个接一个地恢复 dbspace。子进程 ID 显示在第 3 个位置，在一次顺序恢复期间一直保持不变。
并行物理恢复('OnBar -r -p')
2006-01-01 17:04:02 42612 25106 Begin cold level 0 restore rootdbs.
2006-01-01 17:05:27 42612 25106 Completed cold level 0 restore rootdbs.
2006-01-01 17:05:27 52488 42612 Process 52488 42612 successfully forked.
2006-01-01 17:05:27 56058 42612 Process 56058 42612 successfully forked.
2006-01-01 17:05:27 52488 42612 Successfully connected to Storage Manager.
2006-01-01 17:05:27 56058 42612 Successfully connected to Storage Manager.
2006-01-01 17:05:27 52488 42612 Begin cold level 0 restore logdbs.
2006-01-01 17:05:27 56058 42612 Begin cold level 0 restore physdbs.
2006-01-01 17:05:29 56058 42612 Completed cold level 0 restore physdbs.
2006-01-01 17:05:29 52488 42612 Completed cold level 0 restore logdbs.
2006-01-01 17:05:29 56058 42612 Process 56058 42612 completed.
2006-01-01 17:05:29 52488 42612 Process 52488 42612 completed.
2006-01-01 17:05:29 42612 25106 WARNING: Physical restore complete. Logical restore required
before work can continue.
|
在恢复根 dbspace 之后，OnBar 派生出一些附加的 OnBar 进程，其他的 dbspaces 将被并行地处理（基于 BAR_MAX_BACKUP）。在 OnBar 活动日志的第 3 个位置中包含多个进程 ID。当物理恢复完成之后，就会显示那条令人容易产生误解的警告信息。在物理恢复之后执行 'onmode -m'（忽略逻辑恢复）将导致 online.log 中出现以下消息：
执行 'onmode -m' 后 online.log 中的消息
17:06:54 No logical log restore will be performed.
17:06:54 Clearing the physical and logical logs has started
17:07:26 Cleared 129 MB of the physical and logical logs in 31 seconds
17:07:26 Physical Recovery Started.
17:07:26 Physical Recovery Complete: 0 Pages Restored.
17:07:26 Logical Recovery Started.
17:07:28 Logical Recovery Complete.
0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks
17:07:29 Bringing system to On-Line Mode with no Logical Restore.
17:07:30 On-Line Mode
|
物理日志和逻辑日志完全清除之后，IDS 将处于在线模式。
