简介这份文档面向企业级备份运维人员与数据库管理员聚焦 TSM 6.3 环境下虚拟带库与数据库备份恢复的完整测试流程适合具备一定 Linux 与存储基础、需要搭建备份验证环境的中高级技术人员参考。压缩包内仅含 1 个 docx 文件约 1.83MB内容按四大模块组织Mhvtl 虚拟带库在 Centos 6.5 上的编译安装与 iSCSI 映射、TSM 主服务器安装及存储设备与卷策略配置、基于 TSM 的 Oracle 备份、以及 Oracle 异机恢复的完整操作链路。文档目录结构清晰涵盖带库可用性测试、NUB 客户端配置、Rman 与 TSM 命令恢复 Spfile、控制文件及数据文件等关键环节并附有拓扑与需求模型说明便于读者对照搭建实验环境、理解备份策略落地与灾难恢复的排错思路。目前已有 241 人学习下载可作为 TSM 与 Oracle 备份恢复方案验证的实操参考。1. TSM6.3 在 Linux 上接 Mhvtl 虚拟带库一套能反复重来的备份恢复验证环境很多做企业备份的同行都遇到过同一个尴尬TSMTivoli Storage Manager现在叫 Spectrum Protect但一线还是习惯叫 TSM的备份策略配好了Oracle 和 DB2 的脚本也跑通了可一旦要验证「恢复到底行不行」就得占用真实物理带库和真机资源排一次恢复窗口要协调存储、DBA、运维三方成本高到没人愿意做第二次。标题里这套组合——TSM6.3 Linux Mhvtl Oracle DB2——本质上是把「备份恢复测试」从生产环境里剥离出来用一台 Linux 机器加一套虚拟带库把整条链路完整复现。Mhvtl 是 Linux 上的虚拟磁带库模拟器它把磁带、机械手、驱动器都用软件模拟出来TSM 看到的是一台标准带库实际数据落在本地磁盘上。这套环境适合两类人一类是要给 Oracle/DB2 做恢复演练但拿不到物理带库的 DBA另一类是刚接手 TSM 想搞懂「备份成功」和「恢复成功」之间差多少的运维。下面按我实际搭过一遍的顺序讲参数和坑都写清楚。2. 先把 Mhvtl 虚拟带库立起来设备映射和 TSM 识别是两道坎Mhvtl 的核心价值在于它模拟的是 SCSI 磁带设备不是文件系统层面的「假磁带」。TSM 通过操作系统看到的/dev/sg*、/dev/st*设备节点和接一台真带库没有区别。这意味着 TSM 的 device class、path、drive 定义全都不用改测试环境验证过的配置可以直接搬到生产。但代价是 Mhvtl 的安装和内核模块加载比普通软件麻烦设备映射错了 TSM 就认不到驱动器。2.1 Mhvtl 安装与内核模块加载常见做法是从源码编译因为发行版仓库里的版本往往偏旧和较新的内核配合容易出问题。编译前先确认内核头文件已安装否则make到内核模块那一步会直接失败。# 安装编译依赖不同发行版包名略有差异 yum install -y kernel-devel kernel-headers gcc make git # 获取 Mhvtl 源码并编译 git clone https://example.com/mhvtl.git cd mhvtl make make install # 加载内核模块注意顺序先加载 mhvtl再加载其依赖的 scsi 相关模块 modprobe mhvtl lsmod | grep mhvtl # 确认虚拟设备节点已生成 ls -l /dev/sg* /dev/st* /dev/sch*逻辑说明make install会把mhvtl内核模块和用户态守护进程mhvtl一起装好。modprobe mhvtl加载后内核会创建虚拟的 SCSI 主机适配器操作系统随即枚举出磁带设备节点。参数上Mhvtl 的库数量、驱动器数量、磁带槽位都在/etc/mhvtl/device.conf和/etc/mhvtl/library_contents.conf里定义默认是 1 个库、2 个驱动器、10 个槽位。如果ls /dev/st*没有任何输出先看dmesg | tail有没有 SCSI 枚举报错八成是内核模块版本和当前内核不匹配。2.2 用 mt 和 lsscsi 验证虚拟带库可用性设备节点出来了不代表能用得用mt命令实际操作一下磁带确认读写和定位都正常。这一步是后面 TSM 能识别的前提。# 查看 SCSI 设备拓扑确认虚拟带库的机械手和驱动器都在 lsscsi -g # 对第一个驱动器做状态查询和倒带 mt -f /dev/st0 status mt -f /dev/st0 rewind # 写入测试数据再读回验证磁带可读写 tar -cf /dev/st0 /etc/hosts mt -f /dev/st0 rewind tar -tf /dev/st0逻辑说明lsscsi -g会列出 SCSI 设备及其对应的通用设备节点/dev/sg*TSM 配置 path 时用的就是这些节点。mt status返回的是驱动器状态包括当前磁带是否加载、是否写保护。tar写入再读回是最朴素的验证方式如果这一步报 I/O 错误说明虚拟磁带的后端存储路径权限有问题——Mhvtl 默认把磁带数据放在/var/lib/mhvtl/下这个目录的属主必须是运行 Mhvtl 守护进程的用户。2.3 TSM 服务端识别虚拟带库的关键配置TSM 识别带库分三步定义 library、定义 drive、定义 path。顺序不能乱path 是把 drive 和 library 关联到操作系统设备节点的桥梁。# 在 TSM 管理命令行中执行 # 定义带库libtype 选 SCSI因为 Mhvtl 模拟的是标准 SCSI 带库 DEFINE LIBRARY MHVTL_LIB LIBTYPESCSI # 定义驱动器element 号要和 Mhvtl 配置里的驱动器编号对应 DEFINE DRIVE MHVTL_LIB DRV0 ELEMENT1 DEFINE DRIVE MHVTL_LIB DRV1 ELEMENT2 # 定义路径把驱动器和操作系统设备节点绑定 DEFINE PATH SERVERNAME MHVTL_LIB DRV0 SRCTYPESERVER DESTTYPEDRIVE \ DEVICE/dev/st0 ONLINEYES DEFINE PATH SERVERNAME MHVTL_LIB DRV1 SRCTYPESERVER DESTTYPEDRIVE \ DEVICE/dev/st1 ONLINEYES # 定义机械手路径 DEFINE PATH SERVERNAME MHVTL_LIB SRCTYPESERVER DESTTYPELIBRARY \ DEVICE/dev/sg2 ONLINEYES逻辑说明ELEMENT号必须和 Mhvtl 的library_contents.conf里定义的驱动器 element 地址一致否则 TSM 发搬运指令时机械手会去抓一个不存在的位置。DEVICE参数填的是操作系统设备节点驱动器用/dev/st*机械手用/dev/sg*。定义完用Q PATH检查状态ONLINEYES且没有报错才算通。这里最常见的翻车是机械手路径填成了驱动器的/dev/st*TSM 会报「library not ready」排查时先Q PATH看每个 path 的 device 对不对。3. Oracle 和 DB2 的备份脚本怎么接进 TSM两种数据库两条路子数据库备份接 TSMOracle 和 DB2 的机制完全不同。Oracle 走 RMAN通过SBT_TAPE通道把备份集直接写给 TSMDB2 走db2 backup命令的UTIL_IMPACT_PRIORITY和 TSM 的dsm.opt配置。两者共同点是都要装 TSM 的 API 客户端tivoli.tsm.client.api区别在于 Oracle 用libobk.soDB2 用libtsmdb2.so。3.1 Oracle RMAN 通道配置与 TSM 对接RMAN 不直接认 TSM它认的是SBT_TAPE类型的通道这个通道背后由libobk.so实现而libobk.so是 Oracle 提供的它再去调 TSM API。所以配置分两层Oracle 侧配libobk.so的软链接TSM 侧配dsm.opt。# Oracle 侧把 TSM API 的库链接成 Oracle 期望的 libobk.so # 注意路径要和 Oracle 的 ORACLE_HOME/lib 对应 ln -s /usr/lib/libtsm.so $ORACLE_HOME/lib/libobk.so # 配置 TSM API 客户端参数 cat /opt/tivoli/tsm/client/api/bin64/dsm.opt EOF SERVERNAME tsm_server COMMMETHOD TCPIP TCPPORT 1500 NODENAME oracle_node PASSWORDACCESS GENERATE EOF # RMAN 脚本示例全库备份到 TSM rman target / EOF CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE PARMS ENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt); CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; BACKUP DATABASE PLUS ARCHIVELOG; EOF逻辑说明libobk.so是 Oracle 的 SBT 接口规范任何第三方带库厂商都要提供符合这个规范的库文件。TSM 的 API 库libtsm.so通过软链接伪装成libobk.soRMAN 调用时实际走的是 TSM 的 API。dsm.opt里的PASSWORDACCESS GENERATE让 TSM 自动管理密码避免脚本里写明文。tdpo.opt是 Oracle 专用的 TSM 配置文件里面指定DSMI_DIR和DSMI_LOG路径错了 RMAN 会报ORA-19554: error allocating device。参数上RECOVERY WINDOW OF 7 DAYS控制备份保留策略测试环境可以设短一点避免虚拟磁带被占满。3.2 DB2 备份到 TSM 的配置与命令DB2 接 TSM 比 Oracle 简单因为 DB2 内置了对 TSM 的支持只要装好 TSM API 客户端在db2.conf里指定DSMI_DIR就行。DB2 的备份命令直接带USE TSM选项。# 配置 DB2 的 TSM 接口参数 cat /home/db2inst1/sqllib/db2dump/db2.conf EOF DSMI_DIR /opt/tivoli/tsm/client/api/bin64 DSMI_LOG /home/db2inst1/sqllib/db2dump DSMI_CONFIG /opt/tivoli/tsm/client/api/bin64/dsm.opt EOF # 执行 DB2 全库备份到 TSM db2 backup db sample use tsm # 查看备份历史确认备份已写入 TSM db2 list history backup all for sample # 恢复测试从 TSM 恢复全库 db2 restore db sample use tsm taken at 20250101120000逻辑说明db2.conf里的DSMI_DIR指向 TSM API 的库目录DB2 启动备份时会去这个目录加载libtsmdb2.so。use tsm告诉 DB2 把备份介质交给 TSM 管理而不是写到本地文件系统。list history能看到备份的时间戳和介质类型如果介质类型显示TTape说明确实走了 TSM。恢复时taken at后面跟的是备份时间戳必须和list history里看到的完全一致差一秒都会报「SQL2542N No matching backup image found」。这里有个血泪经验DB2 的 TSM 接口对DSMI_LOG目录的写权限很敏感如果 DB2 实例用户没有写权限备份会静默失败日志里只留一行很含糊的SQL2071N。3.3 备份策略与虚拟磁带容量规划虚拟带库虽然不花真金白银买磁带但后端磁盘空间是有限的。Mhvtl 默认每个磁带 100MB 到 2GB 不等在library_contents.conf里定义。Oracle 全库加归档日志、DB2 全库加起来很容易超过单盘容量需要规划磁带数量和 TSM 的存储池。项目建议值说明单盘虚拟磁带容量2GB太小会导致频繁换带太大恢复时定位慢磁带槽位数20够放一轮全备加增量TSM 存储池PRIMARYPOOL指向虚拟带库不要用 DISK 池备份保留版本3 份测试环境够用多了占空间回收阈值60%低于此值触发磁带回收逻辑说明TSM 的存储池分 DISK 和 TAPE 两类测试环境如果只做恢复验证可以直接用 TAPE 池省掉从 DISK 迁移到 TAPE 的步骤。但要注意TSM 的磁带回收reclamation在虚拟带库上同样会触发机械手搬运如果 Mhvtl 的机械手模拟有 bug回收过程可能卡住。我一般会在测试环境把回收阈值设高一点减少回收频率等恢复验证做完再调回来。4. 恢复验证怎么做才算数从「备份成功」到「数据可用」的最后一公里备份成功不等于恢复成功这是做这行最贵的一课。TSM 的Q BACKUP显示备份完成只代表数据写进了存储池不代表能读回来。恢复验证要分三层TSM 层面能定位到备份对象、数据库层面能识别备份集、数据层面能打开并查询。三层都过才算这套环境真的可用。4.1 TSM 侧恢复前的对象定位与检查在动数据库之前先在 TSM 里确认备份对象还在、可访问。这一步能过滤掉大部分「备份早就过期了」的低级问题。# 在 TSM 管理命令行中查询 Oracle 节点的备份对象 Q BACKUP oracle_node * * * # 查询 DB2 节点的备份对象 Q BACKUP db2_node * * * # 检查存储池中可用的磁带卷 Q VOL stgpoolPRIMARYPOOL # 如果卷状态是 FULL 或 PENDING需要确认是否可读 Q VOL volume_name FORMATDETAILED逻辑说明Q BACKUP的输出里OBJECT列是备份对象的逻辑路径Oracle 的备份集通常显示为/*/backupset/...DB2 显示为/sample/NODE0000/...。如果这里查不到数据库侧再怎么恢复都是白费。Q VOL看卷状态FULL表示写满了但可读PENDING表示有问题需要AUDIT VOLUME修复。参数上Q BACKUP的星号通配符顺序是「节点名 文件空间 对象名」测试环境直接用* * *全查。4.2 Oracle 恢复演练从控制文件到全库Oracle 的恢复分两步先恢复控制文件如果控制文件也丢了再恢复数据文件。测试环境一般控制文件还在直接RESTORE加RECOVER就行。# RMAN 恢复脚本从 TSM 恢复全库 rman target / EOF # 先确认备份集可见 LIST BACKUP SUMMARY; # 恢复数据文件到默认位置 RESTORE DATABASE; # 应用归档日志做不完全恢复测试环境常用 RECOVER DATABASE UNTIL TIME TO_DATE(2025-01-01 12:00:00,YYYY-MM-DD HH24:MI:SS); # 打开数据库 ALTER DATABASE OPEN RESETLOGS; EOF逻辑说明LIST BACKUP SUMMARY是恢复前的必做动作确认 RMAN 能从 TSM 读到备份集元数据。RESTORE DATABASE从 TSM 拉回数据文件这一步的耗时取决于虚拟磁带后端磁盘的 IO 性能。RECOVER DATABASE UNTIL TIME做不完全恢复测试环境常用因为不需要把归档日志全部应用完。OPEN RESETLOGS之后数据库就可用但注意这会重置日志序列生产环境要谨慎。参数上如果恢复时报ORA-19870说明 TSM 的tdpo.opt里DSMI_LOG路径不可写RMAN 无法记录恢复日志。4.3 DB2 恢复演练与时间点一致性检查DB2 的恢复比 Oracle 简单但时间点一致性要求更严格。db2 restore之后必须rollforward否则数据库处于前滚挂起状态不可用。# 从 TSM 恢复 DB2 全库 db2 restore db sample use tsm taken at 20250101120000 # 前滚到日志末尾 db2 rollforward db sample to end of logs and stop # 检查数据库状态 db2 connect to sample db2 select count(*) from syscat.tables db2 terminate逻辑说明taken at的时间戳必须和list history里看到的完全一致这是 DB2 恢复最容易翻车的地方。rollforward to end of logs把归档日志全部应用and stop让数据库脱离前滚状态。select count(*) from syscat.tables是最简单的可用性验证能查出数就说明系统表空间没问题。参数上如果rollforward报SQL1268N说明归档日志路径不对检查db2 get db cfg for sample里的LOGPATH和OVERFLOWLOGPATH。5. 避坑与排查这套环境里最容易翻车的五个地方这套环境搭起来不难难的是出问题的时候知道往哪看。下面五条是我自己踩过或者帮别人排查过的按「现象 → 原因 → 解决」写遇到类似症状可以直接对号入座。现象一TSM 定义 path 时报「ANR8779E Unable to open drive」原因/dev/st*设备节点的权限不对TSM 服务端进程用户没有读写权限。Mhvtl 创建的设备节点默认属主是 root而 TSM 通常以非 root 用户运行。 解决用chown把设备节点属主改成 TSM 实例用户或者把 TSM 用户加入disk组。改完用mt -f /dev/st0 status确认 TSM 用户能操作。现象二Oracle RMAN 备份报「ORA-19554: error allocating device」原因libobk.so软链接指向错误或者tdpo.opt里的DSMI_DIR路径不对。RMAN 找不到 TSM API 库。 解决ls -l $ORACLE_HOME/lib/libobk.so确认链接目标存在tdpo.opt里DSMI_DIR指向/opt/tivoli/tsm/client/api/bin64DSMI_LOG指向一个 Oracle 用户可写的目录。现象三DB2 备份成功但list history里介质类型显示DDisk而不是TTape原因db2.conf没生效DB2 回退到了默认的磁盘备份。常见于DSMI_CONFIG指向的dsm.opt文件路径写错。 解决确认db2.conf里三个DSMI_*参数都指向真实存在的路径重启 DB2 实例让配置生效。用db2 get dbm cfg | grep -i tsm检查。现象四Mhvtl 机械手搬运磁带时报「Medium not found」原因library_contents.conf里的槽位号和 TSM 的ELEMENT号不匹配。TSM 以为磁带在 1 号槽实际 Mhvtl 把它放在 10 号槽。 解决对照library_contents.conf和 TSM 的Q LIBRARY输出把ELEMENT号一一对齐。改完Q LIBRARY确认槽位状态。现象五恢复时 TSM 报「ANR8355E I/O error reading label」原因虚拟磁带的后端存储文件损坏通常是磁盘满了导致 Mhvtl 写入不完整。 解决df -h看/var/lib/mhvtl/所在分区清理空间后AUDIT VOLUME修复卷修不好就删掉重建虚拟磁带。测试环境数据不重要重建最快。6. 把这套环境用成肌肉记忆几个让验证更省事的技巧搭一次环境不难难的是让这套环境变成随时能用的验证平台。我自己的习惯是把它做成一个可重复的流程每次验证新策略之前先跑一遍基线确认环境本身没问题再动数据库配置。这样出问题的时候能快速区分是环境挂了还是策略写错了。第一个技巧是给 Mhvtl 的虚拟磁带做快照。虚拟磁带本质上是/var/lib/mhvtl/下的文件在跑恢复验证之前用tar把整个目录打包备份验证搞砸了直接解包还原比重新定义 TSM 库和驱动器快得多。这个操作在物理带库上想都不敢想是虚拟带库最大的优势。# 验证前快照虚拟磁带目录 tar -czf /backup/mhvtl_snapshot_$(date %Y%m%d).tar.gz /var/lib/mhvtl/ # 搞砸了还原 tar -xzf /backup/mhvtl_snapshot_20250101.tar.gz -C /第二个技巧是给 TSM 的恢复验证单独建一个管理类。生产环境的备份策略不动测试环境用独立的MGMTCLASS保留版本设少一点回收阈值设高一点避免测试数据把虚拟磁带占满。这样生产和测试互不干扰验证完直接删掉测试管理类就行。第三个技巧是记录每次恢复的耗时。虚拟带库的恢复速度取决于后端磁盘但 TSM 的元数据查询、机械手搬运、数据库前滚这些环节的耗时是相对固定的。把每次恢复的时间记下来形成基线下次恢复明显变慢的时候就知道是磁盘 IO 出问题了还是 TSM 数据库膨胀了。这个习惯帮我提前发现过一次 TSM 数据库日志满的问题当时恢复时间从 8 分钟涨到 40 分钟一查果然是dsmserv.opt里的ACTIVELOGSIZE设太小。最后一个习惯是每次验证完把 TSM 的Q ACTLOG导出一份。TSM 的活动日志是排查问题的黑匣子恢复过程中任何异常都会在这里留痕。导出命令很简单但养成习惯之后下次出问题不用从头猜。# 导出最近的活动日志 dsmadmc -idadmin -passwordxxx Q ACTLOG BEGINDATETODAY BEGINTIME00:00 /tmp/tsm_actlog_$(date %Y%m%d).log这套环境我用了很久最大的体会是备份恢复测试的价值不在于「跑通一次」而在于「随时能再跑一次」。物理带库做不到随时重来虚拟带库可以。把 Mhvtl 的快照、TSM 的独立管理类、恢复耗时基线这三件事做成习惯这套环境就从「搭过一次的 Demo」变成了真正能支撑日常验证的平台。希望帮到你。本文还有配套的精品资源点击获取
简介这份文档面向企业级备份运维人员与数据库管理员聚焦 TSM 6.3 环境下虚拟带库与数据库备份恢复的完整测试流程适合具备一定 Linux 与存储基础、需要搭建备份验证环境的中高级技术人员参考。压缩包内仅含 1 个 docx 文件约 1.83MB内容按四大模块组织Mhvtl 虚拟带库在 Centos 6.5 上的编译安装与 iSCSI 映射、TSM 主服务器安装及存储设备与卷策略配置、基于 TSM 的 Oracle 备份、以及 Oracle 异机恢复的完整操作链路。文档目录结构清晰涵盖带库可用性测试、NUB 客户端配置、Rman 与 TSM 命令恢复 Spfile、控制文件及数据文件等关键环节并附有拓扑与需求模型说明便于读者对照搭建实验环境、理解备份策略落地与灾难恢复的排错思路。目前已有 241 人学习下载可作为 TSM 与 Oracle 备份恢复方案验证的实操参考。1. TSM6.3 在 Linux 上接 Mhvtl 虚拟带库一套能反复重来的备份恢复验证环境很多做企业备份的同行都遇到过同一个尴尬TSMTivoli Storage Manager现在叫 Spectrum Protect但一线还是习惯叫 TSM的备份策略配好了Oracle 和 DB2 的脚本也跑通了可一旦要验证「恢复到底行不行」就得占用真实物理带库和真机资源排一次恢复窗口要协调存储、DBA、运维三方成本高到没人愿意做第二次。标题里这套组合——TSM6.3 Linux Mhvtl Oracle DB2——本质上是把「备份恢复测试」从生产环境里剥离出来用一台 Linux 机器加一套虚拟带库把整条链路完整复现。Mhvtl 是 Linux 上的虚拟磁带库模拟器它把磁带、机械手、驱动器都用软件模拟出来TSM 看到的是一台标准带库实际数据落在本地磁盘上。这套环境适合两类人一类是要给 Oracle/DB2 做恢复演练但拿不到物理带库的 DBA另一类是刚接手 TSM 想搞懂「备份成功」和「恢复成功」之间差多少的运维。下面按我实际搭过一遍的顺序讲参数和坑都写清楚。2. 先把 Mhvtl 虚拟带库立起来设备映射和 TSM 识别是两道坎Mhvtl 的核心价值在于它模拟的是 SCSI 磁带设备不是文件系统层面的「假磁带」。TSM 通过操作系统看到的/dev/sg*、/dev/st*设备节点和接一台真带库没有区别。这意味着 TSM 的 device class、path、drive 定义全都不用改测试环境验证过的配置可以直接搬到生产。但代价是 Mhvtl 的安装和内核模块加载比普通软件麻烦设备映射错了 TSM 就认不到驱动器。2.1 Mhvtl 安装与内核模块加载常见做法是从源码编译因为发行版仓库里的版本往往偏旧和较新的内核配合容易出问题。编译前先确认内核头文件已安装否则make到内核模块那一步会直接失败。# 安装编译依赖不同发行版包名略有差异 yum install -y kernel-devel kernel-headers gcc make git # 获取 Mhvtl 源码并编译 git clone https://example.com/mhvtl.git cd mhvtl make make install # 加载内核模块注意顺序先加载 mhvtl再加载其依赖的 scsi 相关模块 modprobe mhvtl lsmod | grep mhvtl # 确认虚拟设备节点已生成 ls -l /dev/sg* /dev/st* /dev/sch*逻辑说明make install会把mhvtl内核模块和用户态守护进程mhvtl一起装好。modprobe mhvtl加载后内核会创建虚拟的 SCSI 主机适配器操作系统随即枚举出磁带设备节点。参数上Mhvtl 的库数量、驱动器数量、磁带槽位都在/etc/mhvtl/device.conf和/etc/mhvtl/library_contents.conf里定义默认是 1 个库、2 个驱动器、10 个槽位。如果ls /dev/st*没有任何输出先看dmesg | tail有没有 SCSI 枚举报错八成是内核模块版本和当前内核不匹配。2.2 用 mt 和 lsscsi 验证虚拟带库可用性设备节点出来了不代表能用得用mt命令实际操作一下磁带确认读写和定位都正常。这一步是后面 TSM 能识别的前提。# 查看 SCSI 设备拓扑确认虚拟带库的机械手和驱动器都在 lsscsi -g # 对第一个驱动器做状态查询和倒带 mt -f /dev/st0 status mt -f /dev/st0 rewind # 写入测试数据再读回验证磁带可读写 tar -cf /dev/st0 /etc/hosts mt -f /dev/st0 rewind tar -tf /dev/st0逻辑说明lsscsi -g会列出 SCSI 设备及其对应的通用设备节点/dev/sg*TSM 配置 path 时用的就是这些节点。mt status返回的是驱动器状态包括当前磁带是否加载、是否写保护。tar写入再读回是最朴素的验证方式如果这一步报 I/O 错误说明虚拟磁带的后端存储路径权限有问题——Mhvtl 默认把磁带数据放在/var/lib/mhvtl/下这个目录的属主必须是运行 Mhvtl 守护进程的用户。2.3 TSM 服务端识别虚拟带库的关键配置TSM 识别带库分三步定义 library、定义 drive、定义 path。顺序不能乱path 是把 drive 和 library 关联到操作系统设备节点的桥梁。# 在 TSM 管理命令行中执行 # 定义带库libtype 选 SCSI因为 Mhvtl 模拟的是标准 SCSI 带库 DEFINE LIBRARY MHVTL_LIB LIBTYPESCSI # 定义驱动器element 号要和 Mhvtl 配置里的驱动器编号对应 DEFINE DRIVE MHVTL_LIB DRV0 ELEMENT1 DEFINE DRIVE MHVTL_LIB DRV1 ELEMENT2 # 定义路径把驱动器和操作系统设备节点绑定 DEFINE PATH SERVERNAME MHVTL_LIB DRV0 SRCTYPESERVER DESTTYPEDRIVE \ DEVICE/dev/st0 ONLINEYES DEFINE PATH SERVERNAME MHVTL_LIB DRV1 SRCTYPESERVER DESTTYPEDRIVE \ DEVICE/dev/st1 ONLINEYES # 定义机械手路径 DEFINE PATH SERVERNAME MHVTL_LIB SRCTYPESERVER DESTTYPELIBRARY \ DEVICE/dev/sg2 ONLINEYES逻辑说明ELEMENT号必须和 Mhvtl 的library_contents.conf里定义的驱动器 element 地址一致否则 TSM 发搬运指令时机械手会去抓一个不存在的位置。DEVICE参数填的是操作系统设备节点驱动器用/dev/st*机械手用/dev/sg*。定义完用Q PATH检查状态ONLINEYES且没有报错才算通。这里最常见的翻车是机械手路径填成了驱动器的/dev/st*TSM 会报「library not ready」排查时先Q PATH看每个 path 的 device 对不对。3. Oracle 和 DB2 的备份脚本怎么接进 TSM两种数据库两条路子数据库备份接 TSMOracle 和 DB2 的机制完全不同。Oracle 走 RMAN通过SBT_TAPE通道把备份集直接写给 TSMDB2 走db2 backup命令的UTIL_IMPACT_PRIORITY和 TSM 的dsm.opt配置。两者共同点是都要装 TSM 的 API 客户端tivoli.tsm.client.api区别在于 Oracle 用libobk.soDB2 用libtsmdb2.so。3.1 Oracle RMAN 通道配置与 TSM 对接RMAN 不直接认 TSM它认的是SBT_TAPE类型的通道这个通道背后由libobk.so实现而libobk.so是 Oracle 提供的它再去调 TSM API。所以配置分两层Oracle 侧配libobk.so的软链接TSM 侧配dsm.opt。# Oracle 侧把 TSM API 的库链接成 Oracle 期望的 libobk.so # 注意路径要和 Oracle 的 ORACLE_HOME/lib 对应 ln -s /usr/lib/libtsm.so $ORACLE_HOME/lib/libobk.so # 配置 TSM API 客户端参数 cat /opt/tivoli/tsm/client/api/bin64/dsm.opt EOF SERVERNAME tsm_server COMMMETHOD TCPIP TCPPORT 1500 NODENAME oracle_node PASSWORDACCESS GENERATE EOF # RMAN 脚本示例全库备份到 TSM rman target / EOF CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE PARMS ENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt); CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; BACKUP DATABASE PLUS ARCHIVELOG; EOF逻辑说明libobk.so是 Oracle 的 SBT 接口规范任何第三方带库厂商都要提供符合这个规范的库文件。TSM 的 API 库libtsm.so通过软链接伪装成libobk.soRMAN 调用时实际走的是 TSM 的 API。dsm.opt里的PASSWORDACCESS GENERATE让 TSM 自动管理密码避免脚本里写明文。tdpo.opt是 Oracle 专用的 TSM 配置文件里面指定DSMI_DIR和DSMI_LOG路径错了 RMAN 会报ORA-19554: error allocating device。参数上RECOVERY WINDOW OF 7 DAYS控制备份保留策略测试环境可以设短一点避免虚拟磁带被占满。3.2 DB2 备份到 TSM 的配置与命令DB2 接 TSM 比 Oracle 简单因为 DB2 内置了对 TSM 的支持只要装好 TSM API 客户端在db2.conf里指定DSMI_DIR就行。DB2 的备份命令直接带USE TSM选项。# 配置 DB2 的 TSM 接口参数 cat /home/db2inst1/sqllib/db2dump/db2.conf EOF DSMI_DIR /opt/tivoli/tsm/client/api/bin64 DSMI_LOG /home/db2inst1/sqllib/db2dump DSMI_CONFIG /opt/tivoli/tsm/client/api/bin64/dsm.opt EOF # 执行 DB2 全库备份到 TSM db2 backup db sample use tsm # 查看备份历史确认备份已写入 TSM db2 list history backup all for sample # 恢复测试从 TSM 恢复全库 db2 restore db sample use tsm taken at 20250101120000逻辑说明db2.conf里的DSMI_DIR指向 TSM API 的库目录DB2 启动备份时会去这个目录加载libtsmdb2.so。use tsm告诉 DB2 把备份介质交给 TSM 管理而不是写到本地文件系统。list history能看到备份的时间戳和介质类型如果介质类型显示TTape说明确实走了 TSM。恢复时taken at后面跟的是备份时间戳必须和list history里看到的完全一致差一秒都会报「SQL2542N No matching backup image found」。这里有个血泪经验DB2 的 TSM 接口对DSMI_LOG目录的写权限很敏感如果 DB2 实例用户没有写权限备份会静默失败日志里只留一行很含糊的SQL2071N。3.3 备份策略与虚拟磁带容量规划虚拟带库虽然不花真金白银买磁带但后端磁盘空间是有限的。Mhvtl 默认每个磁带 100MB 到 2GB 不等在library_contents.conf里定义。Oracle 全库加归档日志、DB2 全库加起来很容易超过单盘容量需要规划磁带数量和 TSM 的存储池。项目建议值说明单盘虚拟磁带容量2GB太小会导致频繁换带太大恢复时定位慢磁带槽位数20够放一轮全备加增量TSM 存储池PRIMARYPOOL指向虚拟带库不要用 DISK 池备份保留版本3 份测试环境够用多了占空间回收阈值60%低于此值触发磁带回收逻辑说明TSM 的存储池分 DISK 和 TAPE 两类测试环境如果只做恢复验证可以直接用 TAPE 池省掉从 DISK 迁移到 TAPE 的步骤。但要注意TSM 的磁带回收reclamation在虚拟带库上同样会触发机械手搬运如果 Mhvtl 的机械手模拟有 bug回收过程可能卡住。我一般会在测试环境把回收阈值设高一点减少回收频率等恢复验证做完再调回来。4. 恢复验证怎么做才算数从「备份成功」到「数据可用」的最后一公里备份成功不等于恢复成功这是做这行最贵的一课。TSM 的Q BACKUP显示备份完成只代表数据写进了存储池不代表能读回来。恢复验证要分三层TSM 层面能定位到备份对象、数据库层面能识别备份集、数据层面能打开并查询。三层都过才算这套环境真的可用。4.1 TSM 侧恢复前的对象定位与检查在动数据库之前先在 TSM 里确认备份对象还在、可访问。这一步能过滤掉大部分「备份早就过期了」的低级问题。# 在 TSM 管理命令行中查询 Oracle 节点的备份对象 Q BACKUP oracle_node * * * # 查询 DB2 节点的备份对象 Q BACKUP db2_node * * * # 检查存储池中可用的磁带卷 Q VOL stgpoolPRIMARYPOOL # 如果卷状态是 FULL 或 PENDING需要确认是否可读 Q VOL volume_name FORMATDETAILED逻辑说明Q BACKUP的输出里OBJECT列是备份对象的逻辑路径Oracle 的备份集通常显示为/*/backupset/...DB2 显示为/sample/NODE0000/...。如果这里查不到数据库侧再怎么恢复都是白费。Q VOL看卷状态FULL表示写满了但可读PENDING表示有问题需要AUDIT VOLUME修复。参数上Q BACKUP的星号通配符顺序是「节点名 文件空间 对象名」测试环境直接用* * *全查。4.2 Oracle 恢复演练从控制文件到全库Oracle 的恢复分两步先恢复控制文件如果控制文件也丢了再恢复数据文件。测试环境一般控制文件还在直接RESTORE加RECOVER就行。# RMAN 恢复脚本从 TSM 恢复全库 rman target / EOF # 先确认备份集可见 LIST BACKUP SUMMARY; # 恢复数据文件到默认位置 RESTORE DATABASE; # 应用归档日志做不完全恢复测试环境常用 RECOVER DATABASE UNTIL TIME TO_DATE(2025-01-01 12:00:00,YYYY-MM-DD HH24:MI:SS); # 打开数据库 ALTER DATABASE OPEN RESETLOGS; EOF逻辑说明LIST BACKUP SUMMARY是恢复前的必做动作确认 RMAN 能从 TSM 读到备份集元数据。RESTORE DATABASE从 TSM 拉回数据文件这一步的耗时取决于虚拟磁带后端磁盘的 IO 性能。RECOVER DATABASE UNTIL TIME做不完全恢复测试环境常用因为不需要把归档日志全部应用完。OPEN RESETLOGS之后数据库就可用但注意这会重置日志序列生产环境要谨慎。参数上如果恢复时报ORA-19870说明 TSM 的tdpo.opt里DSMI_LOG路径不可写RMAN 无法记录恢复日志。4.3 DB2 恢复演练与时间点一致性检查DB2 的恢复比 Oracle 简单但时间点一致性要求更严格。db2 restore之后必须rollforward否则数据库处于前滚挂起状态不可用。# 从 TSM 恢复 DB2 全库 db2 restore db sample use tsm taken at 20250101120000 # 前滚到日志末尾 db2 rollforward db sample to end of logs and stop # 检查数据库状态 db2 connect to sample db2 select count(*) from syscat.tables db2 terminate逻辑说明taken at的时间戳必须和list history里看到的完全一致这是 DB2 恢复最容易翻车的地方。rollforward to end of logs把归档日志全部应用and stop让数据库脱离前滚状态。select count(*) from syscat.tables是最简单的可用性验证能查出数就说明系统表空间没问题。参数上如果rollforward报SQL1268N说明归档日志路径不对检查db2 get db cfg for sample里的LOGPATH和OVERFLOWLOGPATH。5. 避坑与排查这套环境里最容易翻车的五个地方这套环境搭起来不难难的是出问题的时候知道往哪看。下面五条是我自己踩过或者帮别人排查过的按「现象 → 原因 → 解决」写遇到类似症状可以直接对号入座。现象一TSM 定义 path 时报「ANR8779E Unable to open drive」原因/dev/st*设备节点的权限不对TSM 服务端进程用户没有读写权限。Mhvtl 创建的设备节点默认属主是 root而 TSM 通常以非 root 用户运行。 解决用chown把设备节点属主改成 TSM 实例用户或者把 TSM 用户加入disk组。改完用mt -f /dev/st0 status确认 TSM 用户能操作。现象二Oracle RMAN 备份报「ORA-19554: error allocating device」原因libobk.so软链接指向错误或者tdpo.opt里的DSMI_DIR路径不对。RMAN 找不到 TSM API 库。 解决ls -l $ORACLE_HOME/lib/libobk.so确认链接目标存在tdpo.opt里DSMI_DIR指向/opt/tivoli/tsm/client/api/bin64DSMI_LOG指向一个 Oracle 用户可写的目录。现象三DB2 备份成功但list history里介质类型显示DDisk而不是TTape原因db2.conf没生效DB2 回退到了默认的磁盘备份。常见于DSMI_CONFIG指向的dsm.opt文件路径写错。 解决确认db2.conf里三个DSMI_*参数都指向真实存在的路径重启 DB2 实例让配置生效。用db2 get dbm cfg | grep -i tsm检查。现象四Mhvtl 机械手搬运磁带时报「Medium not found」原因library_contents.conf里的槽位号和 TSM 的ELEMENT号不匹配。TSM 以为磁带在 1 号槽实际 Mhvtl 把它放在 10 号槽。 解决对照library_contents.conf和 TSM 的Q LIBRARY输出把ELEMENT号一一对齐。改完Q LIBRARY确认槽位状态。现象五恢复时 TSM 报「ANR8355E I/O error reading label」原因虚拟磁带的后端存储文件损坏通常是磁盘满了导致 Mhvtl 写入不完整。 解决df -h看/var/lib/mhvtl/所在分区清理空间后AUDIT VOLUME修复卷修不好就删掉重建虚拟磁带。测试环境数据不重要重建最快。6. 把这套环境用成肌肉记忆几个让验证更省事的技巧搭一次环境不难难的是让这套环境变成随时能用的验证平台。我自己的习惯是把它做成一个可重复的流程每次验证新策略之前先跑一遍基线确认环境本身没问题再动数据库配置。这样出问题的时候能快速区分是环境挂了还是策略写错了。第一个技巧是给 Mhvtl 的虚拟磁带做快照。虚拟磁带本质上是/var/lib/mhvtl/下的文件在跑恢复验证之前用tar把整个目录打包备份验证搞砸了直接解包还原比重新定义 TSM 库和驱动器快得多。这个操作在物理带库上想都不敢想是虚拟带库最大的优势。# 验证前快照虚拟磁带目录 tar -czf /backup/mhvtl_snapshot_$(date %Y%m%d).tar.gz /var/lib/mhvtl/ # 搞砸了还原 tar -xzf /backup/mhvtl_snapshot_20250101.tar.gz -C /第二个技巧是给 TSM 的恢复验证单独建一个管理类。生产环境的备份策略不动测试环境用独立的MGMTCLASS保留版本设少一点回收阈值设高一点避免测试数据把虚拟磁带占满。这样生产和测试互不干扰验证完直接删掉测试管理类就行。第三个技巧是记录每次恢复的耗时。虚拟带库的恢复速度取决于后端磁盘但 TSM 的元数据查询、机械手搬运、数据库前滚这些环节的耗时是相对固定的。把每次恢复的时间记下来形成基线下次恢复明显变慢的时候就知道是磁盘 IO 出问题了还是 TSM 数据库膨胀了。这个习惯帮我提前发现过一次 TSM 数据库日志满的问题当时恢复时间从 8 分钟涨到 40 分钟一查果然是dsmserv.opt里的ACTIVELOGSIZE设太小。最后一个习惯是每次验证完把 TSM 的Q ACTLOG导出一份。TSM 的活动日志是排查问题的黑匣子恢复过程中任何异常都会在这里留痕。导出命令很简单但养成习惯之后下次出问题不用从头猜。# 导出最近的活动日志 dsmadmc -idadmin -passwordxxx Q ACTLOG BEGINDATETODAY BEGINTIME00:00 /tmp/tsm_actlog_$(date %Y%m%d).log这套环境我用了很久最大的体会是备份恢复测试的价值不在于「跑通一次」而在于「随时能再跑一次」。物理带库做不到随时重来虚拟带库可以。把 Mhvtl 的快照、TSM 的独立管理类、恢复耗时基线这三件事做成习惯这套环境就从「搭过一次的 Demo」变成了真正能支撑日常验证的平台。希望帮到你。本文还有配套的精品资源点击获取
