简介面向企业级备份/灾备工程师这份原创文档系统演示了在 CentOS 6.5 环境中如何用 TSM 6.3 结合 Mhvtl 开源虚拟带库完成备份恢复测试。全文围绕四部分展开Mhvtl 的编译安装与带库可用性验证、TSM 主服务器端配置含存储设备、卷、备份策略、基于 NUB 客户端的 Oracle 备份以及通过 Rman 与 TSM 命令实现的 Oracle 异机恢复。文档虽以 Oracle 备份恢复为主线但其中 TSM 与虚拟带库的配置思路对 DB2 等备份场景同样有参考价值。资源包为 1 个 docx 文档大小约 1.83MB内容目录清晰步骤按操作顺序编写包含从 iSCSI 映射、客户端配置到恢复数据库的完整操作可直接对照实验环境操作。目前已有 241 人学习下载是学习 TSM 备份体系与 Oracle 恢复流程的实用参考。1. 为什么选 TSM6.3 Mhvtl 这套组合先别急着买磁带库做企业备份测试的都知道TSM6.3 是很多老机房还在跑的靠谱版本但想拿它联调一个真实的 LTO 带库成本和时间都不划算。Mhvtl 这个 Linux 下的开源虚拟带库恰好能在没有磁带机的情况下模拟出机械手、驱动器和磁带卷把 TSM 的备份恢复链路完整跑通。这份测试文档就是围绕 TSM6.3.5 Mhvtl Oracle DB2 的组合写出来的前半部分解决“有没有带库”的问题后半部分解决“备份能不能恢复”的问题。适合正在搭备份测试环境、或者准备把老系统从其他备份体系迁移到 TSM 体系的运维工程师直接照着复现尤其适合刚接触虚拟带库的人。我也是在真实带库排不上档期时靠这套组合把 Oracle 异机恢复练熟的所以分享一下拆解感受。2. Mhvtl 虚拟带库搭建从编译安装到 iSCSI 映射2.1 Mhvtl 的工作原理与选型理由Mhvtl 全名是 Multi-Host Virtual Tape Library它不像普通软件那样只做文件模拟而是直接在 Linux 内核里挂一个 SCSI 模拟驱动配合用户态的vtllibrary和vtlmedia进程给上层应用呈现一个真正可以识别出的“磁带库实体”。文档里生成的两个库体一个模拟 STK L7004 个驱动器、43 个槽位另一个模拟 STK L804 个驱动器、44 个槽位。为什么同时模拟两个因为在测试里一个库放备份集另一个库放归档或克隆卷是常见用法这样 TSM 的容池、拷贝池逻辑能一次验证到位。选型理由很直接TSM 的define library可以直接把/dev/sg10当机械手、/dev/st0当磁带机整套命令和真实带库几乎是一样写的。文档里也提到 Mhvtl 已被用于 NetBackup、BackupExec、TSM、Oracle 备份这就说明它模拟得足够像主流备份软件都认它。但要注意边界Mhvtl 的 I/O 最终落到宿主机磁盘性能上限取决于磁盘速度和内核 SCSI 模拟层适合“链路验证”和“恢复演练”不适合拿它测带机吞吐极限。我一般把它定位成一台不需要开机柜的测试带库容量、槽位数、带机类型都可以通过改配置调。另一个现实原因是成本。真实 LTO5 带机一台就要上万还另算光纤通道的成本。Mhvtl 用一台普通虚拟机就能模拟 LTO1 到 LTO5、STK T10000 等型号文档里默认用的就是 IBM ULT3580-TD5、TD4 和 STK T10000B覆盖了主流企业备份设备的分类。对于要写 TSM 策略、调磁带回收、做异机恢复的人来说这套环境比找真实硬件要少很多沟通成本和排障时间。2.2 编译安装 Mhvtl依赖包、内核模块与服务启动文档的安装路径是/opt/mhvtl虚拟存储和/etc/mhvtl配置这个划分很关键后面换机器时把这两个目录一起打包就很方便。先装依赖再建用户# yum install lsscsi mt-st mtx zlib-devel sg3_utils zlib kernel-devel kernel-headers gcc # useradd vtl # passwd vtl # mkdir -p /opt/mhvtl /etc/mhvtl # chown -R vtl:vtl /opt/mhvtl /etc/mhvtl这里lsscsi用于查看 SCSI 设备mt-st是磁带控制工具mtx是机械手控制工具sg3_utils处理 SCSI 通用设备。创建vtl用户是让 Mhvtl 的进程以普通用户身份跑避免权限事故。/opt/mhvtl是磁带镜像文件存放地/etc/mhvtl是配置目录所有权都给了vtl。注意最后这个chown不能省否则启动进程写不了库体配置启动完一堆Permission denied。然后编译内核模块# rpm -ivh mhvtl-utils-1.5-2.x86_64.rpm # unzip mhvtl-1.5-2.zip # cd markh794-mhvtl-d9f6115/kernel # make make install # service mhvtl start # chkconfig mhvtl on拆解一下先装mhvtl-utils里面带了mtx、vtl管理工具和配置文件模板解压源码包后进入kernel目录编译把mhvtl.ko内核模块装进系统。service mhvtl start会启动vtllibrary和vtlmedia两个守护进程第一次启动会提示Could not locate library config file这是正常的它会生成默认的library_contents.10和library_contents.30。此时不要急着改先停服务再编辑配置文档里也写了“Please stop mhvtl edit ... to suit your requirements”。启动完成后立刻用lsscsi -g看新设备# lsscsi -g [3:0:0:0] mediumx STK L700 0105 /dev/sch0 /dev/sg10 [3:0:1:0] tape IBM ULT3580-TD5 0105 /dev/st0 /dev/sg2 [3:0:8:0] mediumx STK L80 0105 /dev/sch1 /dev/sg11 [3:0:9:0] tape STK T10000B 0105 /dev/st4 /dev/sg6/dev/sg10和/dev/sg11是机械手对应的sch0/sch1是 changer 设备/dev/st0到/dev/st7是磁带驱动器。TSM 认的是/dev/sgX和/dev/stX所以后面 iSCSI 导出时千万别把sch设备漏了。另外文档里有一个很容易看花眼的地方st和sg的对应关系不是严格递增的/dev/st0可能对应/dev/sg2/dev/st1对应/dev/sg3配置时要一句句核对不能凭序号猜。磁带默认容量是 500MB测试大备份集肯定不够文档里给了改法# cat /etc/mhvtl/mhvtl.conf MHVTL_CONFIG_PATH/etc/mhvtl CAPACITY2046CAPACITY2046表示每盘磁带默认容量约 2GB改完必须重启mhvtl服务而且已经生成的磁带镜像不会变只有新入库的卷才用新容量。想批量调大建议先把/opt/mhvtl下旧卷清掉再重启否则你会看到一盘磁带写着 2G 容量写一半就报满的诡异现象。2.3 验证带库可用性mtx 机械手与 tar 读写安装完别急着接 TSM先用mtx和tar做一次裸读写确认带库本身没毛病。查看机械手状态# mtx -f /dev/sg10 status Storage Changer /dev/sg10:4 Drives, 43 Slots ( 4 Import/Export ) Data Transfer Element 0:Empty Storage Element 1:Full :VolumeTagE01001L4 Storage Element 2:Full :VolumeTagE01002L4这一步能同时确认驱动器和槽位是否被内核正确枚举。如果显示“Full”且卷标签正常说明默认配置已经预置了不少卷。把 1 号槽位的磁带加载进 0 号驱动器# mtx -f /dev/sg10 load 1 0 # mtx -f /dev/sg10 status | grep Data Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag E01001L4然后写数据# tar -cvf /dev/st0 /boot # tar -tvf /dev/st0 | head/dev/st0指向 0 号驱动器。第一次写会看到tar: Removing leading / from member names这是正常的磁带 tar 默认去根路径。能写能读就说明内核 SCSI 模拟、机械手联动、驱动器读写都正常。这一步是我在接入 TSM 前必做的相当于给带库通电自检。2.4 基于 tgt 的 iSCSI 映射把虚拟带库共享给备份服务器测试环境里 Mhvtl 和 TSM 服务器经常分两台虚拟机这时就需要把 Mhvtl 的 SCSI 设备通过 iSCSI 共享给备份服务器。文档用的是tgt这是内核里的 iSCSI target 实现。先装服务端# yum install scsi-target-utils # chkconfig tgtd on然后编辑/etc/tgt/targets.conf把机械手和驱动器都导出target iqn.2024-06.test:mhvtl backing-store /dev/sg10 backing-store /dev/sg11 backing-store /dev/st0 backing-store /dev/st1 initiator-address 192.168.81.0/24 /target注意backing-store填的是 Mhvtl 宿主机的设备文件。/dev/sg10是 SCSI 通用设备导出去之后备份服务器上会用lsscsi -g看到对应的 mediumx 和 tape 设备。initiator-address建议写成具体备份服务器的网段别写ALL否则测试环境里其他机器会看到你的假带库干扰排查。这里有个文档里没细说的点iSCSI target 每次导出的设备名和顺序取决于 target 配置文件的顺序建议按先机械手后驱动的顺序写减少备份服务器端设备枚举的混乱。备份服务器上装 initiator# yum install iscsi-initiator-utils # service iscsi start # iscsiadm -m discovery -t sendtargets -p 192.168.81.6 # iscsiadm -m node -T iqn.2024-06.test:mhvtl -p 192.168.81.6 -l-m discovery用于发现远端 target-m node加-l是登录 LUN。登录后建议再跑一次lsscsi -g确认设备编号。这里有个易错点iSCSI 登录后设备号是内核动态分配的Mhvtl 宿主机上的/dev/sg10在备份服务器上可能变成/dev/sg4TSM 配置时不要照抄源端设备名要用备份服务器上看到的实际设备名。这也是我在第 5 章要单独说的坑。3. TSM 6.3 服务器配置从安装到第一条备份策略3.1 TSM 主服务器安装与初始化TSM 6.3.5 在 CentOS 6 上的安装不算复杂但目录规划别马虎。文档里没展开安装包细节按我拆文档的习惯会把数据库目录、日志目录、磁盘池目录分到不同挂载点避免一个分区被日志和备份数据同时撑爆。安装完成后的初始化命令大致是# useradd tsminst1 # mkdir -p /tsm/db /tsm/log /tsm/diskbackup /tsm/tape # /opt/tivoli/tsm/server/bin/dsmserv format dbdir/tsm/db logdir/tsm/log # /opt/tivoli/tsm/server/bin/dsmserv -p 1500 参数含义dbdir指定 TSM 数据库目录logdir指定活动日志目录-p 1500是让 TSM 服务监听在 1500 端口。默认 1500 是 TSM 的惯例端口后面客户端dsmc节点配置里tcpserveraddress也会用到。如果机器内存不大建议活动日志目录单独放因为 TSM 的日志增长很猛尤其第一次全量备份时。启动后进入管理控制台# /opt/tivoli/tsm/server/bin/dsmadmc -idadmin -passwordadmin初始管理员账号密码是安装时设置的文档里没给具体值我在测试环境一般用admin/admin生产环境第一件事就是改掉它。登录后先用q status看一眼版本和服务器状态确认监听正常。TSM 的版本、实例信息都在这里后续排查备份失败时第一件事就是看这里。3.2 定义存储设备机械手、驱动器与卷TSM 里带库是逐个定义的机械手、驱动器、路径、卷四样都要配齐。第 2 章已经把/dev/sg10机械手和/dev/st0驱动器映射给了备份服务器这里直接在 dsmadmc 里执行define library lib01 librarytypescsi device/dev/sg10; define drive lib01 drive01 device/dev/st0; define path server1 lib01 srctypeserver desttypelibrary device/dev/sg10;解释一下define library告诉 TSM 用一个 SCSI 机械手/dev/sg10是控制路径define drive给驱动器命名device/dev/st0是数据路径define path把服务器到库的控制路径显式绑定。这里最容易翻车的是设备名写错尤其是 iSCSI 映射后设备名变化所以我在配置前一定会跑一次lsscsi -g并截图保存。TSM 里定义的顺序也有讲究必须先建库再建 drive再建 path否则报“library not defined”。定义完驱动器和路径接着把磁带卷入带库。文档里默认库体里已经有卷了比如E01001L4、F01030L5这些卷标签在 Mhvtl 的配置里能对上。TSM 侧需要用 checkin 把它们登记进来checkin libvolume lib01 searchbulk statusscratch;searchbulk表示扫描整个库体把槽位上所有带卷一次性登记statusscratch表示这些卷作为可用暂存卷后台容量池自动使用。如果库体槽位很多这一步会耗时但不用担心TSM 会打印“checkin completed”。检查一下卷状态q libvolume lib01;状态应该是Scratch如果看到Private说明之前有备份数据标记了所有权需要重新checkin或delete volume处理。3.3 配置备份策略并执行第一次备份TSM 的策略模型是策略域policy domain→ 策略集policy set→ 管理类management class→ 副本组copygroup。文档里提到的“文件备份策略”最简配置就是建一个域和默认管理类然后激活define domain domain01; define policy domain01 standard; define mgmtclass domain01 standard mc01; define copygroup domain01 standard mc01 typebackup frequency0 verexist2 vernondexist1; activate policy domain01 standard;这里frequency0表示不限制备份频率verexist2表示同一文件保留 2 个备份版本vernondexist1表示文件删除后备份再保留 1 个版本。实际生产可以按保留周期改但测试环境建议用这个简单配置先把链路跑通。激活策略后注册一个备份客户端节点register node client01 password01;客户端装好 TSM API 后用dsmc命令发起备份。先做一个文件系统备份# dsmc incr /home -nodeclient01 -passwordpassword01incr是增量备份首次相当于全量后面再次执行就会走增量。备份完成后用q backup查一下备份版本# dsmc q backup /home -nodeclient01能列出文件版本就说明 TSM 的调度链路通了。如果备份任务量大可以加一个调度define schedule domain01 sched1 actionincremental objecttypeclient options-nodeclient01 starttime02:00;调度是 TSM 日常备份的核心但初学阶段先手工跑通再碰调度排查会轻松很多。3.4 本地磁盘备份不接带库时的替代方案没有 Mhvtl 或 iSCSI 还没调通时TSM 也可以把备份写到本地磁盘文档里单独写了“配置本地磁盘备份”。TSM 的做法是定义一个 FILE 类型的设备类再建一个存储池指向它define devclass filebkp devtypefile directory/tsm/diskbackup; define stgpool diskpool filebkp maxsize1024;directory/tsm/diskbackup是磁盘池文件落地目录maxsize1024表示单个卷文件最大 1GB。TSM 会把逻辑卷映射到目录下的物理文件。使用磁盘池和带库池的最大区别是带库池要考虑机械手和卷的装载策略磁盘池完全靠 TSM 自行管理适合测试和应急备份。我习惯在调通带库前先用磁盘池把客户端备份链路验证一遍然后再切换到带库池这样排查问题时能把“TSM 配置”和“带库设备”两个故障域隔开。配置完后把备份目标指向磁盘池update stgpool diskpool maxscratch50; update copygroup domain01 standard mc01 typebackup destinationdiskpool;注意update copygroup会改变默认目标池如果还用带库的话记得后面再改回来。磁盘池的备份集同样可以用dsmc restore恢复这对验证 TSM 客户端功能非常友好。文档里这部分写得比较靠后但我建议测试时先做磁盘池备份再做带库备份能明显缩短排障链路。4. 基于 TSM 的 Oracle 备份与异机恢复从 NUB 客户端到 RMAN4.1 客户端环境准备与 NUB 安装Oracle 备份需要在数据库服务器上装 TSM 的 Oracle 组件文档里叫 NUB其实就是 TSM for Oracle 那一套客户端。版本必须和 TSM 6.3.5 配套装完后核心是tdpotco.opt配置文件和 RMAN 的sbt_tape库。环境变量写在/etc/profile.d/oracle_tdp.shexport TDP_DIR/opt/tivoli/tsm/client/oracle export TDP_OPTFILE$TDP_DIR/tdpotco.opt export LD_LIBRARY_PATH$TDP_DIR/lib:$LD_LIBRARY_PATHTDP_OPTFILE指向配置文件RMAN 调用 TSM 插件时会从这里读取节点名和参数。我把路径写在/etc/profile.d里是为了让 oracle 用户每次登录都能自动加载不然 cron 调度备份时环境变量缺失RMAN 会报TDPO_OPTFILE not set。配置文件内容# vi $TDP_DIR/tdpotco.opt TDPO_ORACLE_HOME/u01/app/oracle/product/11.2.0/dbhome_1 TDPO_FSorabackup TDPO_NODEorabaseTDPO_ORACLE_HOME是 Oracle 软件目录TDPO_FS是 TSM 文件空间名TDPO_NODE是 TSM 节点名。这三个必须和 TSM 服务器端注册的节点一致否则授权过不了。4.2 客户端与服务端的节点授权配置在 TSM 服务器端注册 Oracle 备份节点register node orabackup orapass userinfooracle backup; grant proxynode orabackup targetorabase;register node建立备份节点grant proxynode是 TSM 做 Oracle 备份的关键授权。Oracle 客户端以orabase身份连接数据库但备份数据要写到orabackup这个节点下没有 proxynode 授权RMAN 备份连第一阶段都过不去。文档里提到的“修改 TSM 异机恢复授权文件”本质上是在新机器上把节点名和密码配置成与源端一致或者临时增加 proxy 授权关系。客户端dsm.sys里也需要配置# grep -v ^# /opt/tivoli/tsm/client/ba/bin/dsm.sys SERVERNAME tsm61 TCPPORT 1500 TCPSERVERADDRESS 192.168.81.7 NODENAME orabackup PASSWORDACCESS generate这里NODENAME要与服务器注册节点一致PASSWORDACCESS generate让客户端自动保存加密后的密码否则每次备份都需要交互输密码RMAN 里就非常难受。我用-passwordorapass手工执行一次后密码文件自动生成后续 RMAN 调用就不会卡在密码输入上。4.3 手工发起备份RMAN 调用 TSM 插件先在客户端测试连通性# dsmc q node -servertsm61能列出节点信息就 OK。然后进 RMAN 执行备份rman target / run { allocate channel c1 type sbt_tape parmsENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/tdpotco.opt); backup database include current controlfile format ora_%d_%T_%s.bkp; release channel c1; }type sbt_tape告诉 RMAN 用 TSM 的处理库parms里必须把TDPO_OPTFILE传进去否则加载库时找不到配置。format里的%d是库名%T是日期%s是备份集号建议保留方便后面恢复时识别备份集。备份完成后可以验证# dsmc q backup /u01/app/oracle/product/11.2.0/dbhome_1 -nodeorabackup看到 RMAN 备份集文件就说明备份已经落到 TSM 带库里了。这一步我通常会顺便看下带库卷的使用情况确认数据真的写进了 Mhvtl而不是落在了本地磁盘池。4.4 异机恢复目录、Spfile、控制文件、数据文件与打开库异机恢复是整个文档最值钱的部分。文档目录里已经把顺序拆得很清楚创建目录 → 恢复 spfile → 恢复 controlfile → mount → 恢复数据文件 → recover → open。先在新机器上准备目录# mkdir -p /u01/app/oracle/oradata/orcl /u01/app/oracle/fast_recovery_area/orcl # chown oracle:oinstall /u01/app/oracle -R接着用 RMAN 连接实例到 nomountrman target / startup nomount; restore spfile from ora_orcl_20240101_1.bkp;如果不知道备份集文件名可以用list backup of spfile查到。恢复 spfile 后数据库会带可识别参数重启到 nomountrestore controlfile from ora_orcl_20240101_1.bkp; alter database mount;控制文件恢复后数据库可以 mount。接着恢复数据文件和归档日志restore database; recover database;recover database会自动从 TSM 取需要的归档日志只要备份时控制了 current controlfile这一步不需要额外指定日志路径。最后打开数据库alter database open resetlogs;resetlogs是异机恢复或不完全恢复的必选项因为 redo log 的 thread 编号和 SCN 与原来机器不一致。打开后立刻跑一遍select count(*) from dual;验证可用性。文档里还提到 DB2 的异机恢复但具体命令没展开我理解是同一套 TSM 机制只是客户端换成了 TSM for DB2恢复流程要按 DB2 的db2dart或rollforward走涉及 TSM 部分的命令是相似的。5. TSM Mhvtl 环境常见问题五个让人翻车的场景5.1 带库启动与设备发现三个高频故障我在拆这份文档时按“现象 → 原因 → 解决”整理了五个最容易卡住的地方每一个都真实遇到过。现象一启动service mhvtl start后lsscsi看不到sg10设备。原因通常是内核模块没加载成功编译时kernel-devel版本与运行内核不一致make install虽然没报错但模块放到了错误目录。解决方法是先执行modprobe mhvtl看报错缺依赖就重新编译一次。文档里的make make install其实隐含了“先确认内核版本”的前提。现象二mtx -f /dev/sg10 status能看到机械手但所有槽位都显示 Empty或者报Invalid element。原因大概率是/etc/mhvtl/library_contents.10里的槽位配置与 Mhvtl 默认初始化的卷不匹配比如你把槽位数从 43 改成了 50但卷只初始化到 43 槽。解决方法是停掉mhvtl服务检查配置文件里slot定义再手动加载或重置卷。文档里第一次启动时自动生成的 volume 标签其实就是初始化的结果不要随意清空。现象三iSCSI 登录后备份服务器上的/dev/sg10和 Mhvtl 宿主机不是同一个设备。原因很简单设备号由内核动态分配远端不会保留宿主机设备号。解决方法是登录后立刻用lsscsi -g记录设备清单然后修改 TSM 里的 library、drive 定义不要照抄源端配置文件。这也是文档里“备份服务器客户端安装配置”没细写但特别容易翻车的一环。5.2 TSM 与 Oracle 交互两个隐蔽的配置错误现象四RMAN 备份执行到allocate channel就报错日志里有ANS1035E Invalid option。原因一般是TDPO_OPTFILE路径写错或者没把ENV(TDPO_OPTFILE...)放在 parms 参数里。解决方法是先手工敲一遍dsmc q node确认客户端配置正常再检查 RMAN 脚本里的路径是否和/etc/profile.d/oracle_tdp.sh完全一致。这个错最坑的地方在于 RMAN 客户端日志里只给ANS1035E不告诉你具体哪行不行需要开dsm.sys里的ERRORLOGNAME看详细日志。现象五异机恢复时提示Server out of date with client或者RMAN-10038。原因通常是新装的 Oracke 客户端版本与源端不一致TDP 插件版本和 TSM 服务器版本不匹配。解决方法是把客户端 TDP 版本升到与源端相同再检查dsm.sys里的NODENAME是否与授权节点一致。文档里“修改 TSM 异机恢复授权文件”那一步实际就是在源服务器上执行grant proxynode如果在异机恢复前漏掉这步恢复会在读取备份集时直接失败。每个案例我都写进了自己的测试笔记后面再搭新环境会先检查设备编号、再检查环境变量这五个坑基本能避开大半。6. 备份验证的两件小事恢复演练与日志复核6.1 用 RMAN validate 定期验证备份集可恢复性备份成功不等于能恢复这是备份领域最常听到的教训。我建议在你把 Mhvtl 备份策略调通后立刻做一次restore验证rman target / run { allocate channel c1 type sbt_tape parmsENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/tdpotco.opt); restore database validate; }restore database validate不实际写数据只检查备份集是否完整可读。加上这一句就能提前发现磁带损坏、卷丢失、TSM 文件空间权限等问题。我以前跳过这步结果恢复时才遇到某天的归档日志没备份进去只能后悔没趁早验证。6.2 异机恢复手册化的三个检查点除了 RMAN 验证我还会把异机恢复流程做成一张 checklist每次演练都强制走一遍检查 TSM 节点名和密码恢复机和源机上的dsm.sys是否一致TSM 端是否已grant proxynode。检查备份集清单用list backup拉出 spfile、controlfile、datafile 的备份集确认没有缺少关键文件。检查环境变量路径TDPO_OPTFILE、LD_LIBRARY_PATH是否指向同版本客户端库避免加载到旧版libobk.so。做完这三项再跑restore database就基本不会卡在“找不到备份集”或“节点未授权”这类常见问题上。从那以后我每次搭完 TSMMhvtl都会强制走一遍异机恢复哪怕只是 restore 到 mount 阶段也会把 TSM 日志和 RMAN 日志都存一份。这套流程虽然多花二十分钟却能省下真出故障时通宵排障的功夫希望帮到你。本文还有配套的精品资源点击获取