简介：面向企业级备份恢复演练场景的TSM 6.3 Linux实验文档，围绕Mhvtl虚拟带库、TSM备份平台与Oracle数据库恢复展开，适合存储备份运维、数据库管理员及需要复现实验环境的学习者参考。压缩包共1个docx文件，大小约1.83MB，以章节化方式组织安装配置、策略设置与恢复验证内容。正文覆盖Mhvtl编译安装及带库可用性测试、基于tgt的iSCSI映射、TSM主服务器与存储设备/卷/备份策略配置，并给出Oracle的NUB客户端配置、RMAN手工备份、异机恢复授权及Spfile、control file、数据文件和归档日志的恢复顺序。读者可据此梳理从虚拟带库到TSM再到Oracle的完整备份链路，理解异机恢复的关键目录、授权文件与打开数据库前的检查要点，积累排错思路。目前已有243人学习，适合作为中高级备份恢复实验的对照材料，尤其适合对照检查配置顺序与恢复路径。

1. 一台机器装齐 TSM6.3、Mhvtl 和 Oracle：先看清版本底牌

很多人第一次搭 TSM 备份环境，卡住的地方往往不是 TSM 本身，而是“没有带库”。真实磁带库贵、占地方，还要配光纤交换机；用 Mhvtl 在 Linux 上模拟一台 STK L700，再用 iSCSI 映射给备份服务器，这套组合在测试环境里非常常见。我见过的最典型翻车场面，就是 Centos 6.6 下 mhvtl 服务起来、lsscsi -g却看不到机械手，后面 TSM 里“配置存储设备”一整章全部白做。这篇安装笔记就是围绕 TSM 6.3.5 + Mhvtl + Oracle 11g + DB2 9.7 这套测试环境，把版本选择、虚拟带库编译、iSCSI 映射、TSM 设备与卷配置、NUB 客户端接入，一直到异机恢复验证，按能照着跑通的顺序记一遍。适合正在做备份方案验证、手里只有几台虚拟机的运维和 DBA。

2. 环境准备：Centos 6.6 三台机器的角色分工与依赖包

这套测试最少要三台机器：TSM 主服务器（192.168.81.7）、Mhvtl 虚拟带库机（192.168.81.6）、Oracle 客户端（192.168.81.11），如果要一起验证 DB2，再加一台 DB2 9.7 客户端（192.168.81.12）。角色分不清，最容易出现的错误是把 Mhvtl 装到 TSM 服务器上，再想用 iSCSI 映射回本机，调试链路直接翻倍。

2.1 本地 yum 源：离线环境的万能前提

这套系统版本（Centos 6.6、Linux 5.7）早过了官方源维护期，联网 yum 基本不可用，本地光盘源是唯一稳的路子。先把光驱挂到/mnt，把原有 repo 全部挪走，只留一个本地源文件：

mount /dev/cdrom /mnt mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak/ cat > /etc/yum.repos.d/CentOS-Media.repo <<'EOF' [c6-media] name=CentOS-$releasever - Media baseurl=file:///mnt gpgcheck=0 enabled=1 EOF

这里baseurl指向挂载点，gpgcheck=0是因为光盘源的签名校验在测试环境经常报错，跳过不影响包完整性判断。顺手把yum.conf的keepcache保持默认 0，缓存用完即清理，磁盘空间有限时更稳。

2.2 关掉防火墙与 SELinux：别让它成为后面所有问题的替罪羊

TSM 和 iSCSI 都要走固定端口，测试环境里留着 iptables 和 SELinux 只会让排错多绕两圈。SELinux 改成disabled后必须重启才彻底生效，只执行setenforce 0重启后又回来：

sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config service iptables stop chkconfig iptables off

确认方式别只看命令返回，getenforce输出Disabled、service iptables status显示not running才算数。我一般还会核对/etc/sysconfig/selinux，有些镜像这个文件和/etc/selinux/config是两套软链，改错文件重启等于没改。

2.3 时间同步与主机名解析：被忽略的两颗钉子

三台机器时间差超过几分钟，TSM 客户端握手就可能失败，报错信息还非常含糊。测试环境没条件上 NTP 服务器，至少手动date -s对齐，并在/etc/hosts里把四个主机名和 IP 写死。TSM 服务端配置里大量使用主机名，解析反了会导致客户端注册不上，这类问题排查起来完全是黑匣子。

3. Mhvtl 虚拟带库安装：从编译到 iSCSI 映射的全流程

Mhvtl 是一个基于 Linux 的开源虚拟磁带库，能模拟 IBM、HP 的 LTO1 到 LTO5，也能模拟 STK L180/L700、索尼 AIT4、STK T10000A/B/C 等带库。它被成功用在 NetBackup、BackupExec、TSM、Oracle 数据备份等产品上，测试环境里用它替代物理带库，性价比没有对手。这套文档用的版本是 mhvtl-1.5-2，搭配 tgt 做 iSCSI 服务端。

3.1 安装前准备：依赖包和目录权限一次到位

编译前要装的包不少，少一个kernel-devel就会在make阶段报内核头文件缺失：

yum install -y lsscsi mt-st mtx zlib-devel sg3_utils \ zlib kernel-devel kernel-headers gcc useradd vtl mkdir -p /opt/mhvtl /etc/mhvtl chown -Rf vtl:vtl /opt/mhvtl /etc/mhvtl

这里两个目录分工要记牢：/etc/mhvtl放库配置文件和mhvtl.conf，/opt/mhvtl是虚拟磁带数据的落盘路径。权限统一给vtl用户，是因为服务以这个身份运行，目录属主不对会在启动后写不进数据，但服务本身照样显示 running，属于典型的假活。

3.2 编译安装 Mhvtl 1.5：rpm 加源码两步走

安装分两步，先装mhvtl-utils的 rpm，再编译内核模块：

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

首次启动会提示找不到/etc/mhvtl/library_contents.10和.30，自动生成默认配置，这是正常现象，不是错误。默认配置会造出两台带库：一台 STK L700（4 驱动器、43 槽位）、一台 STK L80（4 驱动器、44 槽位）。make install装的是内核模块，所以必须和当前内核版本严格对应，升级内核后要重新编译，否则服务起不来。

3.3 用 lsscsi 和 mtx 验证带库真的可用

服务起来不等于带库可用，必须用 SCSI 工具确认设备节点。执行lsscsi -g，重点看mediumx和tape两类设备：

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

/dev/sg10、/dev/sg11是机械手，/dev/st0到/dev/st7是驱动器。接着用mtx看槽位内容：

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 :VolumeTag=E01001L4

槽位里有预置的 VolumeTag，这是默认配置生成的虚拟磁带。把 1 号槽的带子装入 0 号驱动器，再用 tar 写读验证一遍：

mtx -f /dev/sg10 load 1 0 tar -cvf /dev/st0 /boot tar -tvf /dev/st0

tar能写能读，说明虚拟带库链路完整。这里有个参数值得改：默认单盘容量只有 500MB，测试 Oracle 全备很快就满。编辑/etc/mhvtl/mhvtl.conf把CAPACITY=2046（单位 MB，即 2G），重启服务生效。容量改小了不要紧，改大了才够跑完整备份流程。

3.4 tgt 做 iSCSI 映射：把带库送给 TSM 服务器

Mhvtl 跑在 192.168.81.6 上，TSM 在 .7 上，中间用 iSCSI 连接。服务端装scsi-target-utils，把机械手和驱动器映射出去：

yum install -y scsi-target-utils # 编辑 /etc/tgt/targets.conf，把 /dev/sg10、/dev/st0~st7 逐个映射 service tgtd start chkconfig tgtd on tgtadm --mode target --op show

tgtadm show能看到 target 和挂载的 LUN 才算成功。客户端（TSM 服务器）装iscsi-initiator-utils，iscsiadm -m discovery发现目标后 login，再lsscsi -g应该能看到和带库机一致的设备。这里最常见的坑是映射了驱动器忘了映射机械手，TSM 里定义库时找不到 changer 设备，配置存储设备那一步直接卡死。

4. TSM 6.3.5 服务端配置：设备、卷、策略一条龙

TSM 服务端装好后，所有操作都在dsmadmc管理界面里完成。顺序不能乱：先定义库和驱动器，再定义卷并 checkin，然后建存储池、配策略域，最后才谈备份。跳过任何一步，后面都会以各种奇怪的报错还回来。

4.1 定义机械手与驱动器：路径写错一个字母都不行

进入管理界面后，先定义 library，再定义 path 和 drive：

dsmadmc DEFINE LIBRARY VTL1 LIBTYPE=SCSI DEFINE PATH TSM6 SERVER1 SRCTYPE=SERVER DESTTYPE=LIBRARY \ LIBRARY=VTL1 DEVICE=/dev/sg10 ONLINE=YES DEFINE DRIVE VTL1 DRV0 DEVICE=/dev/st0 ONLINE=YES DEFINE PATH TSM6 DRV0 SRCTYPE=SERVER DESTTYPE=DRIVE \ LIBRARY=VTL1 DEVICE=/dev/st0 ONLINE=YES

DEVICE必须是 iSCSI 客户端侧看到的真实设备名，ONLINE=YES少了会需要手动 online。定义完执行Q LIBRARY和Q DRIVE核对状态，Q PATH里 ONLINE 一栏全为 YES 才算通。驱动器只定义 1 到 2 个就够测试，全定义 8 个反而增加排查面。

4.2 定义卷并 checkin：让 TSM 认识带库里的带子

库和驱动器通了，接着把带子登记进 TSM：

DEFINE VOLUME E01001L4 CHECKIN LIBVOL VTL1 E01001L4 STATUS=SCRATCH CHECKLABEL=YES

STATUS=SCRATCH表示这盘带子作为可用的空带，CHECKLABEL=YES会读卷标，防止卷标和 TSM 记录不一致。带子多的时候可以用CHECKIN LIBVOL VTL1 SEARCH=YES STATUS=SCRATCH批量扫，省得一条条敲。checkin 后Q VOL能看到状态从Pending变Scratch，如果一直 Pending，多半是驱动器没 online 或者卷标读不出来。

4.3 存储池与策略域：备份落到哪、留多久

定义存储池指向 VTL1 的带子，再建策略域绑定管理和默认管理类：

DEFINE STGPOOL VTLPOOL VTL1 DEFINE DOMAIN ORADOM DESCRIPTION="Oracle backup domain" DEFINE POLICYSET ORADOM STANDARD DEFINE MGMTCLASS ORADOM STANDARD MC_ORA DEFINE COPYGROUP ORADOM STANDARD MC_ORA STANDARD TYPE=BACKUP \ DESTINATION=VTLPOOL VEREXISTS=2 VERDELETED=1 RETEXTRA=30 RETONLY=60

这套参数的意思是：同一文件保留 2 个版本，删除后保留 1 个版本，额外版本留 30 天，最后版本留 60 天。测试环境空间有限，别照抄生产参数，尤其RETONLY设太大会把虚拟带子全占满。同时配一个本地磁盘存储池作为第二落点，正好验证“备份到带库/本地磁盘”两种路径。

4.4 文件系统备份验证：先跑通最简单的再上数据库

在客户端注册并绑定策略域后，先备份一个小目录：

dsmc archive /etc -subdir=yes

dsmc是客户端命令行工具，第一次运行要按提示填服务器地址和节点名。备份能在dsmadmc里用Q ACTLOG看到成功记录，再去Q CONTENT VTLPOOL确认数据真的落在带库里，一条完整链路才算走通。很多人在这一步只看到客户端提示成功就收工，结果存储池根本没写进去，后面 Oracle 备份再报错就分不清是哪一层的问题。

5. Oracle 11g 接入 TSM：NUB 客户端与手工备份

Oracle 通过 RMAN 调用 TSM 的libobk库，也就是 NUB（Tivoli Data Protection for Oracle）客户端。版本必须和 TSM 客户端、Oracle 位数匹配，64 位库配 32 位实例是最经典的搭配错误。

5.1 NUB 客户端安装与 dsmi_config 配置

装完 TSM API 和 NUB 后，环境变量要落到位：

export DSMI_CONFIG=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt export DSMI_DIR=/usr/tivoli/tsm/client/api/bin64 export DSMI_LOG=/home/oracle/tsm/log export LD_LIBRARY_PATH=$DSMI_DIR:$LD_LIBRARY_PATH

tdpo.opt里写DSMI_ORC_CONFIG、DSMI_LOG、TDPO_NODE三项，节点名必须和服务端注册的一致。tdpo.opt权限给 oracle 用户可读，日志目录提前建好，否则 RMAN 一调用就报 log 打不开。

5.2 服务端授权与 RMAN 脚本

服务端给 Oracle 节点注册许可证：

REGISTER LICENSE FILE=/usr/tivoli/tsm/server/bin/oracle.lic REGISTER NODE ORACLE ORACLE_PASSW ORADOM

客户端侧 RMAN 里指定SBT_LIBRARY和ENV：

run { allocate channel c1 type 'sbt_tape' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)'; backup database plus archivelog; release channel c1; }

手工发起一次全备，成功后在服务端Q BACKUP和SELECT * FROM SUMMARY里能看到对象。第一次跑通的意义大于备份量本身，它证明 libobk、tdpo.opt、节点授权这条链全对。

5.3 Oracle 异机恢复的关键动作

异机恢复在另一台同版本 Oracle 上做，NUB 客户端要重新装，tdpo.opt里的节点名改成服务端授权过的恢复节点。恢复顺序是固定的：先恢复 spfile，再恢复 controlfile，然后MOUNT数据库，最后恢复数据文件和归档日志并OPEN。中间任何一步版本或路径不对，都会停在RMAN-06026这类错误上。恢复前把原库的目录结构在新机上建好，路径不一致要用SET NEWNAME重定向，这一步偷懒后面会白跑几小时。

6. 装完怎么验证跑通：三条自检线收尾

环境装完最怕“看着都绿、实际不通”，我一般会用三条线交叉验证，而不是只看某一个命令的返回。

第一条线是设备层。在 TSM 服务器上执行lsscsi -g和mtx -f /dev/sg10 status，机械手能报槽位、驱动器能装载带子，说明 iSCSI 到 SCSI 这一层没问题。建议把输出存成文件，恢复测试失败时先拿它和新输出对比，设备名漂移是重启后最常见的变量。

lsscsi -g > /tmp/scsi_before.txt mtx -f /dev/sg10 status > /tmp/mtx_before.txt tgtadm --mode target --op show iscsiadm -m session

第二条线是 TSM 层。依次Q LIBRARY、Q DRIVE、Q PATH、Q VOL，重点看 ONLINE 状态和卷状态。再执行一次Q STGPOOL VTLPOOL看存储池剩余空间，虚拟带子写满后状态会变Full，测试前不清理就会在备份中途报ANR0522W一类空间告警。

第三条线是端到端。做一次 Oracle 全备加一次异机恢复，恢复完成后在新库上执行SELECT COUNT(*)对比源表行数，数量对上才算真跑通。DB2 9.7 同理，备份到带库后恢复到另一实例，用db2 list tablespaces和行数核对。我踩过最贵的一个坑就是只验证了备份作业成功，没验证恢复，直到真出事才发现授权文件没同步到恢复节点。

从那以后，我每次搭完这类测试环境，都强制走一遍“备份、删库、异机恢复、核对行数”的全流程，而不是停在Q BACKUP显示成功那一步。虚拟带库的容量参数、iSCSI 映射的设备名、tdpo.opt 的节点授权，这三样只要有一处没跟上，恢复现场就是一团乱。希望帮到你。

本文还有配套的精品资源，点击获取