简介面向企业备份与灾备技术人员这份原创资源围绕TSM6.3、Mhvtl、Oracle及DB2备份恢复测试场景提供从虚拟带库搭建到TSM配置、再到数据库备份与异机恢复的完整操作文档适合系统管理员、DBA、存储备份工程师以及虚拟带库测试平台搭建人员阅读。压缩包内为1份docx格式文档整体大小1.83MB文档以四大模块展开首先介绍Mhvtl虚拟带库在CentOS 6.5上的编译安装、带库可用性测试及基于tgt的iSCSI映射与客户端连接配置其次介绍TSM主服务器安装与配置包括存储设备、卷和备份策略的定义随后基于NUB客户端和TSM服务器端配置演示Oracle数据库手工备份并介绍TSM本地磁盘备份配置最后通过Rman和TSM命令完成Oracle异机恢复覆盖spfile、控制文件、数据文件及归档日志的恢复与数据库重新打开等关键操作。目前已有239人学习文档按章节递进、步骤清晰既可直接参照搭建完整测试环境也可作为企业级备份恢复方案设计与测试的蓝本。1. TSM6.3 Linux MHVTL Oracle DB2备份恢复测试先把“能恢复”这个承诺做出来运维圈子里出现“TSM6.3 linuxMhvtlOracleDB2备份恢复测试”这种标题通常意味着手头已经凑齐了四样东西一台装好 IBM TSM 6.3 的 Linux 服务器、一套用软件仿出来的虚拟磁带库 MHVTL、以及两个必须按合规要求定期做恢复演练的数据库 Oracle 和 DB2。这套组合要解决的不是“数据能不能拷走”而是“在不去碰真磁带库的前提下让两个数据库的备份物知道该往哪里放、恢复时从哪里拿并且能反复验证恢复这条路是通的”。适合小运维团队、测试环境建设也适合做备份容灾方案选型评估的工程师照着复现——这套方案最大的好处是成本低、可反复演练最大的风险则是“备份成功但恢复翻车”后面会专门讲。2. 这套组合为什么成立MHVTL、TSM 6.3 与两个数据库的分工2.1 用 MHVTL 代替真磁带库虚拟介质在备份测试里的价值MHVTL 是跑在 Linux 上的开源虚拟磁带库实现底层依赖 SCSI target 框架在用户态模拟出“SCSI medium changer 多台 LTO 磁带机”的组合。对 TSM 6.3 来说这台机器就是一台标准的 IBM 磁带库TSM 通过 SCSI 指令操作它和操作物理库没有区别。换一句话说MHVTL 把“机械臂、磁带仓门、驱动器槽位”这些物理概念全部用目录下的镜像文件替代磁带变成文件换带变成文件操作。为什么值得用它来做 Oracle 和 DB2 的备份恢复测试首先是成本一台真实 LTO 磁带库加机械臂和驱动器几十万起步虚拟带库只需要一台普通 Linux 服务器。其次是速度虚拟磁带本质是磁盘读写备份和恢复比真实磁带快一个数量级做反复演练时不用等机械臂倒带。最后是可重复性你可以随时 checkin 一卷磁带、checkout 一卷磁带甚至故意让某卷带“损坏”来验证 TSM 的重试和恢复逻辑。但要划清边界MHVL 本质还是磁盘它适合验证备份流程和恢复流程不适合做生产级离线容灾。如果真有“勒索软件防删、异地离线介质”这类诉求虚拟磁带库覆盖不了最终还得有真实磁带或者对象存储做异地副本。这个定位想清楚后面所有参数都不会跑偏。2.2 TSM 6.3 管理平面节点、存储池、设备类三个概念先对齐TSM 6.3 虽然是老版本但 IBM Tivoli Storage Manager 的管理概念非常稳定先把三个词对齐后面命令才有意义。第一个是节点NodeTSM 给每一台要备份的主机发一个身份Oracle 的 RMAN 通道要注册一个节点DB2 的 TDP 插件也要注册一个节点节点名就是它在 TSM 世界里的身份证。第二个是存储池Storage Pool所有备份对象按池归类池决定数据写到哪一类介质上。第三个是设备类Device Class它把存储池和具体磁带机绑定起来设备类指向库、指向驱动器TSM 才能发出“往几号驱动器装几号带”这种指令。TSM 服务端自身带了一个 DB2 实例来存元数据节点信息、存储池状态、卷的归属全在这套元数据库里。这也是后来最容易爆雷的地方TSM 的日志目录和数据库目录如果放在小分区运行一段时间后 dsmadmc 会卡到怀疑人生。所以后面搭建章节里我会特别强调先看目录空间而不是先把服务跑起来再说。2.3 关键差异Oracle 走 RMAN 的 SBT 接口DB2 走 TDP 插件两个数据库虽然都“接 TSM”但接入路径完全不一样。Oracle 不需要额外装备份代理因为 RMAN 自带 SBTSystem Backup to Tape接口RMAN 通过环境变量 DSMI_ORC_CONFIG 找到 TSM 客户端的 API 库 libobk.so备份数据直接从数据库进程流向 TSM。配置相对轻量难点在环境变量路径和节点授权。DB2 则不一样。DB2 的 BACKUP 命令认识 TSM但需要一个中间层来调用 TSM API这个中间层就是 TSM for DB2俗称 TDPTDP for DB2。TDP 插件装在 DB2 实例所在的机器上提供 DB2 备份进程需要的库文件和 TSM 接口。它的配置比 Oracle 多一层要装插件、设环境变量、在 TSM 里注册独立节点还要保证 DB2 实例用户有权限读到 TDP 的库文件。这两条路径的差异直接决定了第四章和第五章的配置步骤长得完全不同也决定了排错时看的方向完全不同。3. 落地搭建MHVTL 虚拟带库与 TSM 6.3 服务端的对接3.1 安装 MHVTL 并用 lsscsi 验证设备识别TSM 6.3 时代的主流平台是 RHEL/CentOS 6/7MHVTL 在 6.x/7.x 上表现稳定。先确认内核里有 SCSI target 支持然后编译安装# 安装编译依赖和 SCSI 工具 yum install -y gcc make kernel-devel sg3_utils # 解压 mhvtl 源码后编译安装 tar -zxvf mhvtl-*.tar.gz cd mhvtl-* make make install # 启动虚拟带库服务 service mhvtl start # 验证能看到模拟出来的 IBM 磁带库和 LTO 驱动 lsscsi -g | grep -i IBM mt -f /dev/st0 status逻辑说明MHVTL 装好后内核里会多出 SCSI 设备lsscsi 输出的 IBM 设备就是虚拟磁带库其中磁带机对应 /dev/st0、/dev/nst0 这类顺序设备。mt status能读到驱动的详细信息比如密度代码和 LTO 类型。参数说明sg3_utils 里的sg_inq和tapeinfo是排查驱动识别问题的好帮手make install后默认把虚拟介质镜像放在/opt/mhvtl下后面容量问题都出在这里。如果 lsscsi 里什么都看不到最常见的原因是内核的 SCSI target 模块没加载用modprobe target_core_mod先补上再重启服务。注意这台主机上如果之前接过多路径存储建议先记录 lsscsi 输出避免把真实磁盘误认成虚拟磁带的镜像文件目录。3.2 安装 TSM 6.3 服务端并完成最小初始化TSM 6.3 服务端安装包在 Linux 上是 install.sh 引导装完核心程序在/opt/tivoli/tsm/server下。最小初始化要做的不是打开图形界面而是直接建实例# 用安装包内的脚本创建服务端实例实例名按主机职能来 /opt/tivoli/tsm/server/bin/dsmserv -u root createdb tsmsrv # 启动服务端实例 /opt/tivoli/tsm/server/bin/dsmserv -u root -i tsmsrv # 确认服务端进程起来端口默认 1500 ss -lnp | grep 1500逻辑说明createdb会初始化 TSM 自带的元数据库所有节点、存储池、备份对象索引都落在里面TSM 6.3 管理端和备份客户端在 Linux 上都是 64 位安装时注意别混装 32 位组件。参数说明-u指定运行用户root 是最简单选择但如果安全要求高建议单独建 tsm 用户并授权-i指定实例名。服务端配置文件的默认目录是/opt/tivoli/tsm/server/bin里面的 dsmserv.opt 控制端口、日志目录和数据库目录先把dsmdbdir和active log指到大分区这个动作能省掉第七章之前的好多麻烦。3.3 定义库、驱动器、设备类与存储池四条 define 命令打通数据路径服务端起来后用 dsmadmc 登录管理命令行做四件定义工作。这是整套环境里最关键的一段顺序不能乱# 登录管理命令行-dataonly 用于脚本里避免交互 dsmadmc -idadmin -passwordXXXXXX -dataonly yes # 1. 定义 SCSI 类型的磁带库 define library mhvtl_lib libtypescsi # 2. 定义驱动器MHVTL 有几个 st 设备就定义几条 define drive mhvtl_lib drive01 # 3. 定义设备类类型必须是 LTO绑定到上面定义的库 define deviceclass mhvtl_lto devtypelto librarymhvtl_lib # 4. 定义顺序存储池允许使用的空磁带数量 define stgpool POOL_MAIN mhvtl_lto maxscratch50 # 确认四项全部 ONLINE q library q drive q devclass q stgpool逻辑说明第 1 步用libtypescsi告诉 TSM 这台库是 SCSI 介质转换器TSM 会尝试通过 sg 设备发 SCSI 指令第 3 步最关键MHVTL 仿真的是 LTO 驱动设备类必须定义成 LTO如果定义成 DEVCLASSFILE 或 DISKTSM 会走磁盘文件路径完全绕开虚拟带库后面 Oracle 和 DB2 的恢复测试就失去意义了第 4 步的存储池是所有备份对象的最终落脚点。参数说明maxscratch50表示允许 TSM 自动从库中取用最多 50 卷空磁带测试环境里这个值给 20~50 都合理太小会导致备份作业排队等带。定义完可以用q path检查 TSM 到驱动器的路径是不是 ONLINE这一步是判定“TSM 和 MHVTL 是否真正握手成功”的唯一标准。下表是四个对象之间的对应关系排查时对着这个表看TSM 对象命令关键字对应 MHVTL 里的实体常见错误库LIBRARY模拟的 medium changer忘了加载 SCSI target 模块驱动器DRIVE/dev/st0 等磁带机设备类选错报“驱动器不可用”设备类DEVCLASSLTO 驱动物理类型devtype 写成 file数据写错路径存储池STGPOOL虚拟磁带卷集合maxscratch0备份一直等带4. Oracle 接入 TSMRMAN 的 sbt 通道与恢复验证4.1 配置 DSMI_ORC_CONFIG 与 TSM 节点Oracle 侧接入 TSM不需要装 TDP但必须装 TSM 的 API 客户端RMAN 运行时通过环境变量找 API 库。先给 Oracle 建一个独立的 TSM 节点# dsmadmc 里注册 Oracle 专用节点密码按策略设置 register node oracle_node oracle_pass # 设置 API 客户端使用的选项文件路径要有可读权限 cat /usr/tivoli/tsm/client/api/bin64/dsm.opt EOF NODE oracle_node PASSWORDACCESS generate TCPADDRESS 127.0.0.1 TCPPORT 1500 EOF逻辑说明PASSWORDACCESS generate是 TSM 客户端常见的密码管理方式客户端首次连上后自动生成加密密码文件避免把明文密码写死在脚本里TCPADDRESS 指向 TSM 服务端地址这里假设 Oracle 和 TSM 在同一台机器所以用回环地址。参数说明如果 Oracle 不在本机TCPADDRESS要改成 TSM 服务端真实 IPDSMI_ORC_CONFIG是 RMAN 调 libobk.so 时的关键环境变量必须在启动 Oracle 实例的同一个 shell 里生效。4.2 RMAN 的 sbt 通道配置与备份脚本RMAN 里配置 SBT 通道把备份输出导向 TSM-- 配置默认 SBT 设备并指定 DSMI 配置文件路径 RMAN CONFIGURE DEVICE TYPE SBT_TAPE PARMS ENV(DSMI_ORC_CONFIG/usr/tivoli/tsm/client/api/bin64/dsm.opt); -- 备份全库 归档日志备份完成后删除本地已备份归档 RMAN BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;逻辑说明PLUS ARCHIVELOG会在备份数据文件的同时把归档日志一起送进 TSM保证恢复时能到达一致点DELETE INPUT是血泪经验不删本地归档几天内arch目录就会涨满很多 Oracle 备份事故就是这么来的。参数说明SBT_TAPE是 RMAN 预定义的设备类型名称如果通道参数写错RMAN 报ORA-19511先回头检查 dsm.opt 里的节点名和 TCPADDRESS再检查 TSM 服务端该节点是否已经启用。备份完成后用dsmadmc -dataonly yes q content POOL_MAIN能看到 Oracle 的备份对象出现在虚拟带库里。4.3 恢复实测模拟数据文件损坏后完整拉回备份永远是为了恢复。这里做一次最直接的验证删一个数据文件再从 MHVTL 里恢复整库。# 破坏现场删除一个数据文件测试环境做演练用生产环境严禁整套操作 rm -f /u01/oradata/PROD/users01.dbfRMAN 里执行恢复RMAN STARTUP MOUNT; RMAN RESTORE DATABASE; RMAN RECOVER DATABASE; RMAN ALTER DATABASE OPEN;验证恢复结果SELECT STATUS FROM V$INSTANCE;逻辑说明STARTUP MOUNT让实例加载控制文件但不打开数据文件这是恢复的前提RESTORE DATABASE从 TSM 里把备份对象拉回来RECOVER DATABASE应用归档日志把数据文件追平到最后一致点。恢复过程中 TSM 会自动从虚拟带库调取对应卷如果卷被 checkout 或者存储池里根本没有对象这一步会直接失败。参数说明恢复时 RMAN 使用的通道配置必须和备份时一致否则 RMAN 找不到备份集ALTER DATABASE OPEN能成功说明数据文件和控制文件已经一致这一步是恢复测试的及格线。5. DB2 接入 TSMTDP 插件和 db2 use tsm 实测5.1 安装 TDP for DB2 并设置实例环境DB2 和 Oracle 的接入完全不同DB2 需要 TDP 插件作为中间层。TDP for DB2 安装后通常提供/opt/tivoli/tsm/client/tdp/db2目录的库文件。安装完成后给 DB2 实例用户配上环境变量# 在 DB2 实例用户的 .bash_profile 里追加 export DSM_CONFIG/home/db2inst1/dsm.opt export LD_LIBRARY_PATH/opt/tivoli/tsm/client/api/bin64:/opt/tivoli/tsm/client/tdp/db2/lib:$LD_LIBRARY_PATH # 同样先写一个 dsm.opt节点名和 Oracle 分开 cat /home/db2inst1/dsm.opt EOF NODE db2_node PASSWORDACCESS generate TCPADDRESS 127.0.0.1 TCPPORT 1500 EOF同时在 TSM 服务端给 DB2 注册独立节点register node db2_node db2_pass逻辑说明DB2 调用 TSM 时DSM_CONFIG必须指向当前 DB2 实例用户能读到的 dsm.optLD_LIBRARY_PATH要同时包含 TSM API 库和 TDP 库缺一个都会报“不能用 TSM”或找不到库文件的错。节点分开是必须的Oracle 和 DB2 共用一个节点会造成恢复时对象互相干扰。参数说明TDP 插件版本要和 DB2 版本匹配这个在选型时就要确认好常见的翻车现场是把 64 位 TDP 装到 32 位 DB2 实例上接口库加载失败。5.2 DB2 备份db2 backup db use tsm环境变量生效后备份命令非常简单# 在 DB2 实例用户下执行 db2 backup db SAMPLE use tsm逻辑说明use tsm让 DB2 调用 TDP 插件备份数据流经 TSM API 写入虚拟带库。备份对象在 TSM 里的记录可以用q content POOL_MAIN看到这能立刻确认备份是否真正落到了虚拟带库而不是本地盘。参数说明默认备份是离线一致性备份如果业务不能停需要加online参数并配合归档日志保留恢复时再 rollforward。测试环境建议先把离线备份流程跑通再考虑 online。5.3 恢复实测本地还原与恢复到新库先验证最简单的本机还原# 先删除旧库再完整还原 db2 drop db SAMPLE db2 restore db SAMPLE use tsm再验证重定向恢复到新库名这招在演练和容灾里非常常用db2 restore db SAMPLE use tsm into SAMPLE_NEW without prompting验证数据可读db2 connect to SAMPLE_NEW db2 list tablespaces show detail逻辑说明restore db SAMPLE use tsm会从 TSM 里找到该节点最近的完整备份并还原重定向恢复into SAMPLE_NEW适合在不覆盖原库的情况下验证备份可用性这一步能完美模拟“新主机恢复”的场景。恢复完成后用list tablespaces show detail检查表空间状态是不是 0x0000 正常态。参数说明如果备份后还有需要追平的归档日志restore 之后必须执行db2 rollforward db SAMPLE_NEW到时间点否则只能恢复到备份那一刻。测试环境如果归档没开离线备份恢复后直接可用这条不用纠结。6. 避坑从“备份成功”到“恢复成功”之间的高频问题6.1 重启后 TSM 找不到驱动器st 设备漂移了现象MHVTL 服务一重启lsscsi 里设备的编号变了原来 /dev/st0 变成了 /dev/st1TSM 的 q drive 状态变成 offline。原因MHVTL 是软件仿真设备内核按 SCSI 扫描顺序分配设备名重启后顺序可能变TSM 记录的是设备路径路径对不上就找不到驱动器。解决写 udev 规则按序列号固定设备名或者把 TSM 的驱动器路径重定义一遍。测试环境图省事可以直接重定义 path但长期跑建议上 udev# 根据 lsscsi -g 的输出用设备序列号写 udev 规则固定 /dev/st* 映射 # 规则写到 /etc/udev/rules.d/60-mhvtl.rules 后 reload udevadm control --reload-rules service mhvtl restart6.2 备份作业一直等带maxscratch 设成了 0现象Oracle 或 DB2 备份提交后TSM 侧显示“等待可用磁带”作业长时间挂起。原因存储池里既没有手动 checkin 的卷maxscratch 又是 0TSM 没有权限自动拿库里的空带。解决进入 dsmadmc把存储池的 maxscratch 调大或者手动 checkin 一卷空带update stgpool POOL_MAIN maxscratch50 checkin libvolume mhvtl_lib searchbulk statusscratch6.3 DB2 restore 报 object not found但 dsm.opt 明明对现象db2 restore 时提示 TSM 里找不到备份对象但备份时 dsmadmc 里能看到对象。原因最常见是使用了多个 dsm.opt备份时用 A 节点、恢复时环境变量指向 B 节点TSM 按节点隔离数据节点名对不上自然找不到。解决确认备份和恢复时 DSM_CONFIG 指向同一个文件在 TSM 服务端用q node检查节点用q content POOL_MAIN核实对象归属。6.4 备份到一半报写入失败df 一看宿主磁盘满了现象备份任务执行到某个百分比后报介质写错误TSM 作业失败。原因MHVTL 的“磁带”本质是宿主磁盘上的镜像文件镜像文件会按介质容量增长宿主磁盘满了虚拟带自然写不进去。解决给 MHVTL 的数据目录预留至少两倍于“备份集总量”的空间df -h /opt/mhvtl应该成为测试环境的标准巡检项之一。6.5 TSM 服务端越跑越慢dsmadmc 敲命令转圈现象没多少数据量但 dsmadmc 响应很慢q content 要等几十秒。原因TSM 的元数据库日志目录或者归档日志目录满了6.3 自带的 DB2 实例日志写不进去整个服务端被拖住。解决修改 dsmserv.opt把 active log 和 directory 指向大分区重启服务端日常观察/opt/tivoli/tsm/server所在分区的空间占用。7. 把恢复验证变成日常自动化脚本与双人复核技巧软件层面的验证结束了更值钱的是把“恢复测试”固化成例行动作。我的建议是每周做一次自动恢复演练不是每天否则测试数据会把存储池搅乱。做法是写一个组合脚本把 Oracle 和 DB2 的备份、恢复、结果检查串起来用 cron 调度#!/bin/bash # /opt/scripts/weekly_restore_drill.sh set -e # 1. Oracle 恢复到验证实例 su - oracle -c rman target / catalog ... EOF RESTORE DATABASE VALIDATE; EOF # 2. DB2 重定向恢复到新库不覆盖现有实例 su - db2inst1 -c db2 restore db SAMPLE use tsm into SAMPLE_DRILL without prompting # 3. 检查两个数据库的可访问性 su - oracle -c sqlplus / as sysdba SELECT 1 FROM DUAL; su - db2inst1 -c db2 connect to SAMPLE_DRILL; db2 list tablespaces show detail # 4. 结果写入日志文件交给第二个人复核 echo $(date): restore drill finished /var/log/restore_drill.log逻辑说明RESTORE DATABASE VALIDATE是 RMAN 里低成本的校验方式只验证备份集完整性不落盘DB2 用重定向恢复不影响正式库。最后一步的日志是给“双人复核”用的推荐一个人执行、另一个人检查日志并确认表空间状态这套仪式感能有效避免“恢复测试做了但没人认真看”的假合规。参数说明cron 时间建议选业务低谷期比如0 3 * * 0脚本里必须加set -e任何一步失败就停止避免把失败结果误报成成功。如果 TSM 侧卷空间吃紧演练后要集中删除 SAMPLE_DRILL 和临时验证库别让演练数据长期占着存储池。我自己在这类项目里吃过的最大教训就是把“备份成功”当成终点结果第一次真故障时耗了一个通宵才发现是 dsm.opt 节点指歪了。从搭建第一天起就把恢复脚本和自动校验写进 cron别放到出事前才准备。希望帮到你。本文还有配套的精品资源点击获取