企业官网建设流程全解析

简介：这份文档面向企业级备份运维人员与存储工程师，聚焦 TSM 6.3 在 Linux 环境下结合 Mhvtl 虚拟带库完成 Oracle、DB2 备份恢复的完整测试流程，适合需要搭建实验环境或验证灾备方案的中高级技术人员参考。资源包共 1 个 docx 文件，约 1.83MB，内容按四大模块组织：Mhvtl 虚拟带库的编译安装与 iSCSI 映射、TSM 主服务器安装及存储设备与卷配置、基于 TSM 的 Oracle 备份实施，以及借助 RMAN 与 TSM 命令完成的 Oracle 异机恢复，涵盖 Spfile、控制文件、数据文件与归档日志的逐步恢复操作。文档结构清晰、步骤连贯，可作为虚拟带库与 TSM 联调的实操手册，也便于读者对照排查配置与恢复环节的常见问题。目前已有 242 人学习下载，适合用于备份恢复方案验证与技能提升。

1. 从一台“假带库”说起：TSM6.3 环境搭建到底难在哪

很多人第一次搭 TSM 备份环境，卡住的地方不是 TSM 本身，而是没有真带库。采购一台物理磁带库成本高、占地大，测试阶段根本不现实，于是 Mhvtl 这套开源虚拟带库就成了绕不开的选择。我见过不止一个开发者，在 CentOS 上装完 Mhvtl，lsscsi -g能看到机械手和驱动器，结果 TSM 里define library一执行就报设备不可用，折腾一整天找不到原因。这套 TSM6.3 + Mhvtl + Oracle + DB2 的备份恢复测试环境，核心难点集中在三块：虚拟带库的设备映射、iSCSI 把带库导出给备份服务器、以及 TSM 服务端对机械手和驱动器的识别。装不好，轻则备份任务挂起，重则恢复时找不到卷，测试等于白做。这篇笔记面向需要在本机或实验环境复现整套备份链路的开发者，从操作系统准备一路写到 Oracle 异机恢复验证，版本、参数、踩坑点都按实际装过的路径记录。

2. 环境准备：CentOS 6.6 基础配置与依赖清单

整套测试环境跑在虚拟机上，角色划分很清楚：一台做 TSM 主服务器，一台做 Mhvtl 虚拟带库并兼 iSCSI 服务端，另外两台分别跑 Oracle 11g 和 DB2 9.7 作为备份客户端。操作系统统一用 CentOS 6.6，这个版本和 TSM6.3.5、Mhvtl 1.5 的兼容性经过大量实际部署验证，不要图新去上 CentOS 7，后面 systemd 和内核模块编译会多出一堆麻烦。

先把四台机器的地址和角色定下来，后面所有配置都围绕这张表展开：

2.1 本地 yum 源与依赖包

实验环境通常没有外网，先把光盘挂上做本地源，否则后面编译 Mhvtl 缺依赖会反复卡住。

# 挂载光驱到 /mnt mount /dev/cdrom /mnt # 备份原有 repo，避免干扰 mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak/ # 新建本地源文件 vi /etc/yum.repos.d/CentOS-Media.repo

文件内容按下面写，baseurl指向挂载点，gpgcheck=0是因为实验环境不校验签名，省去导入 key 的步骤：

[c6-media] name=CentOS-$releasever - Media baseurl=file:///mnt gpgcheck=0 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6

baseurl只保留file:///mnt一个路径就够了，原模板里还有file:///media/CentOS_6.6_Final，那个目录不存在会导致 yum 报错。改完执行yum clean all && yum repolist，能看到 c6-media 源里有包列表才算通。

2.2 关闭防火墙与 SELinux

TSM 服务端和客户端之间走 1500 端口，iSCSI 走 3260，实验环境里直接关掉防火墙最省事，生产环境再按端口放行。

# 临时关闭并禁止开机启动 service iptables stop chkconfig iptables off # 关闭 SELinux，改配置文件后需重启生效 vi /etc/selinux/config # 将 SELINUX=enforcing 改为 SELINUX=disabled

SELinux 这一项特别容易漏。Mhvtl 启动时会往/etc/mhvtl和/opt/mhvtl写配置文件，SELinux 开着的情况下vtllibrary进程可能被拦，日志里只看到权限拒绝，不熟悉的人会以为是目录属主问题。改完getenforce显示 Disabled 才放心。

2.3 Mhvtl 编译依赖

Mhvtl 需要内核头文件和 SCSI 工具链，一次性装齐：

yum install -y lsscsi mt-st mtx zlib-devel sg3_utils zlib \ kernel-devel kernel-headers gcc make

lsscsi和mtx是后面验证带库设备的关键工具，sg3_utils提供 SCSI 通用设备操作，kernel-devel和kernel-headers版本必须和当前运行内核一致，否则make编译内核模块会报找不到头文件。装完用uname -r和rpm -q kernel-devel对一下版本号，不一致就yum install kernel-devel-$(uname -r)补装。

3. Mhvtl 虚拟带库安装：从编译到设备识别

Mhvtl 是一个基于 Linux 的开源虚拟磁带库，能模拟 IBM、HP 的 LTO 系列以及 STK L700、L80 等带库的机械手和驱动器行为。它已经被 NetBackup、BackupExec、TSM 等主流备份软件验证过，测试环境里用它替代物理带库完全够用。这一章的重点不是“装上”，而是让系统正确识别出机械手和驱动器设备节点，这是后面 TSM 能定义带库的前提。

3.1 创建 vtl 用户与目录

Mhvtl 默认以vtl用户运行，配置文件和虚拟磁带存储目录要提前建好并授权：

useradd vtl passwd vtl mkdir -p /opt/mhvtl mkdir -p /etc/mhvtl chown -Rf vtl:vtl /opt/mhvtl chown -Rf vtl:vtl /etc/mhvtl

/etc/mhvtl放配置文件，/opt/mhvtl放虚拟磁带的实际数据文件。两个目录属主都必须是vtl，否则服务启动后写library_contents会失败。我一般还会chmod 755确认目录可进入，避免权限位过严导致进程读不到配置。

3.2 编译安装 Mhvtl 1.5

先装 utils 包，再解压源码编译内核模块：

# 安装管理工具 rpm -ivh mhvtl-utils-1.5-2.x86_64.rpm # 解压源码 unzip mhvtl-1.5-2.zip cd markh794-mhvtl-d9f6115/kernel # 编译并安装内核模块 make make install

make阶段如果报No such file or directory: /lib/modules/.../build，说明kernel-devel没装或版本不匹配，回到 2.3 节补装。make install会把mhvtl.ko装到当前内核的模块目录，装完depmod -a刷新模块依赖。

启动服务并设为开机自启：

service mhvtl start chkconfig mhvtl on

首次启动会看到类似下面的提示，这是正常现象——服务发现没有library_contents.10和library_contents.30，自动创建了默认配置：

Could not locate library config file: /etc/mhvtl/library_contents.10 Creating a default one Please stop mhvtl & edit /etc/mhvtl/library_contents.10 to suit your requirements

默认配置会模拟两台带库：一台 STK L700（4 驱动器、43 槽位）和一台 STK L80（4 驱动器、44 槽位）。测试环境直接用默认配置就行，需要调整槽位数或驱动器数量时再改library_contents.*文件，改完必须service mhvtl restart才生效。

3.3 确认设备节点与磁带容量

服务起来后用lsscsi -g看 SCSI 设备，重点找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 [3:0:9:0] tape STK T10000B 0105 /dev/st4 /dev/sg6

/dev/sg10和/dev/sg11是两个机械手的通用 SCSI 节点，/dev/st0到/dev/st7是八个驱动器。TSM 定义带库时用的是sg节点，不是sch节点，这一点后面配置时会再强调。

默认每盘虚拟磁带容量是 500MB，测试 Oracle 全库备份肯定不够。改/etc/mhvtl/mhvtl.conf：

# 配置文件路径 MHVTL_CONFIG_PATH=/etc/mhvtl # 默认磁带容量，单位 MB，2046 即约 2GB CAPACITY=2046 # 日志详细程度 VERBOSE=1 # 内核模块调试开关 VTL_DEBUG=0

CAPACITY按测试数据量调整，Oracle 全库加归档日志建议至少 2046，DB2 测试库小一些可以保持默认。改完service mhvtl restart，新容量对之后新加载的磁带生效，已经写过的磁带不会变。

3.4 用 mtx 和 tar 验证带库可用性

装完不能只看设备节点存在，要实际做一次“装带—写入—读取”的闭环。先看机械手状态：

mtx -f /dev/sg10 status

输出里Storage Element 1:Full :VolumeTag=E01001L4表示 1 号槽位有磁带，标签是 E01001L4。把 1 号槽位的磁带装到 0 号驱动器：

mtx -f /dev/sg10 load 1 0

再查状态，Data Transfer Element 0:Full (Storage Element 1 Loaded)说明装带成功。接着用 tar 往/dev/st0写数据：

tar -cvf /dev/st0 /boot

写完读回来验证：

tar -tvf /dev/st0

能列出/boot下的文件列表，说明虚拟带库的读写链路完全通了。这一步如果tar报Cannot open /dev/st0: Device or resource busy，通常是磁带没装到驱动器，回到mtx load重新装带；如果报Input/output error，检查dmesg里有没有mhvtl相关报错，多半是内核模块没加载成功。

4. iSCSI 导出与 TSM 服务端配置：让备份服务器认到带库

Mhvtl 装在本机只能本机用，实际拓扑里带库要导出给 TSM 主服务器。用 Linux 自带的tgt做 iSCSI target，把机械手和驱动器映射出去，TSM 服务器通过 iSCSI initiator 连上来，看到的就是一台“网络带库”。这一章把 target 配置、initiator 连接、TSM 定义设备三步串起来。

4.1 安装并配置 iSCSI target

在 Mhvtl 那台机器上装scsi-target-utils：

yum install -y scsi-target-utils service tgtd start chkconfig tgtd on

创建 target 配置，把两个机械手和八个驱动器都映射出去：

tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2024-01.local.mhvtl:library tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sg10 tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 -b /dev/sg11 tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 3 -b /dev/sg2 tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 4 -b /dev/sg3 tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

--lun 1和--lun 2对应两个机械手，--lun 3往后是驱动器。-b参数指定后端设备，这里必须用sg节点，用st节点 tgt 不认。--op bind -I ALL允许所有 initiator 连接，实验环境图省事，生产环境应该按 IQN 白名单限制。

配置持久化写到/etc/tgt/targets.conf，否则重启后 target 就没了：

<target iqn.2024-01.local.mhvtl:library> backing-store /dev/sg10 backing-store /dev/sg11 backing-store /dev/sg2 backing-store /dev/sg3 initiator-address 192.168.81.0/24 </target>

4.2 TSM 服务器连接 iSCSI 设备

在 TSM 主服务器（192.168.81.7）上装 initiator：

yum install -y iscsi-initiator-utils service iscsid start chkconfig iscsid on # 发现 target iscsiadm -m discovery -t sendtargets -p 192.168.81.6 # 登录 iscsiadm -m node -T iqn.2024-01.local.mhvtl:library -l

登录成功后lsscsi -g应该能看到从远端映射过来的机械手和驱动器，设备名可能是/dev/sg12、/dev/sg13这种，具体以实际输出为准。记下这些节点，下一步 TSM 定义设备要用。

提示：iSCSI 连接断开后设备节点会消失，TSM 里已定义的路径会变成 unavailable。测试环境重启顺序有讲究——先起 Mhvtl 和 tgtd，再起 TSM 服务器的 iscsid，最后起 TSM server，顺序错了要手动重新登录。

4.3 TSM 定义带库、驱动器和路径

进入 TSM 管理命令行dsmadmc，依次定义：

/* 定义带库，LIBTYPE 选 SCSI，设备用机械手的 sg 节点 */ DEFINE LIBRARY VTL_LIB LIBTYPE=SCSI SHARED=NO /* 定义路径，指向 iSCSI 映射过来的机械手 */ DEFINE PATH TSM61 VTL_LIB SRCTYPE=SERVER DESTTYPE=LIBRARY LIBRARY=VTL_LIB DEVICE=/dev/sg12 ONLINE=YES /* 定义四个驱动器 */ DEFINE DRIVE VTL_LIB DRV0 ONLINE=YES DEFINE DRIVE VTL_LIB DRV1 ONLINE=YES DEFINE DRIVE VTL_LIB DRV2 ONLINE=YES DEFINE DRIVE VTL_LIB DRV3 ONLINE=YES /* 为每个驱动器定义路径 */ DEFINE PATH TSM61 DRV0 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL_LIB DEVICE=/dev/sg14 ONLINE=YES DEFINE PATH TSM61 DRV1 SRCTYPE=SERVER DESTTYPE=DRIVE LIBRARY=VTL_LIB DEVICE=/dev/sg15 ONLINE=YES

DEVICE参数填的是 iSCSI 登录后lsscsi -g看到的实际节点，每台机器可能不同，照抄会翻车。定义完执行AUDIT LIBRARY VTL_LIB，TSM 会去扫描带库里的磁带，输出里能看到ANR8447E之类的信息，扫描完成后Q LIBVOL能列出所有卷。

4.4 定义卷与存储池

扫描到的卷要CHECKIN进 TSM 才能用：

/* 批量检入卷，以 E01001L4 为例 */ CHECKIN LIBVOL VTL_LIB SEARCH=BULK STATUS=SCRATCH CHECKLABEL=YES /* 定义主存储池，关联带库 */ DEFINE STGPOOL VTLPOOL VTL_LIB MAXSCRATCH=20 /* 定义磁盘存储池作为一级缓存 */ DEFINE STGPOOL DISKPOOL DISKDIRECTORY=/tsm/disk

MAXSCRATCH=20限制这个存储池最多占用 20 盘 scratch 卷，测试环境够用。CHECKLABEL=YES会让 TSM 读磁带标签，Mhvtl 默认生成的标签格式是E01001L4这种，和 TSM 的标签规则兼容。如果CHECKIN报ANR8801E标签不匹配，检查library_contents.10里的VOL1标签定义和 TSM 期望的格式是否一致。

5. Oracle 与 DB2 客户端接入：备份配置与异机恢复

服务端和带库通了，接下来把 Oracle 和 DB2 接进来。TSM 对数据库的备份靠 TDP（Tivoli Data Protection）模块，Oracle 用tdpo，DB2 用tdpdb2，客户端装的是同一个 BA Client 包，区别在环境变量和配置文件。这一章按“客户端安装—服务端授权—手工备份—异机恢复”的顺序走。

5.1 客户端安装与 dsmi 配置

在 Oracle 客户端（192.168.81.11）上装 TSM BA Client：

rpm -ivh TIVsm-BA.x86_64.rpm rpm -ivh TIVsm-API64.x86_64.rpm

装完配置/opt/tivoli/tsm/client/ba/bin/dsm.sys，指定 TSM 服务器地址和节点名：

SErvername tsm61 COMMmethod TCPip TCPPort 1500 TCPServeraddress 192.168.81.7 NODENAME oracle_node PASSWORDDIR /opt/tivoli/tsm/client/ba/bin

NODENAME是服务端识别客户端的唯一标识，后面服务端REGISTER NODE要用同一个名字。PASSWORDDIR指定密码文件目录，首次dsmc连接时会提示输入密码并生成TSM.PWD。

服务端注册节点并设置备份策略：

REGISTER NODE oracle_node oracle_pass DOMAIN=ORACLE DEFINE SCHEDULE STANDARD DAILY_ORACLE ACTION=BACKUP STARTTIME=02:00

DOMAIN=ORACLE让这个节点走 Oracle 的备份策略域，和文件系统备份区分开。

5.2 Oracle TDPO 配置与手工备份

Oracle 客户端装TIVsm-TDPO包，配置tdpo.opt：

DSMI_ORC_CONFIG /opt/tivoli/tsm/client/oracle/bin64/dsm.opt DSMI_LOG /opt/tivoli/tsm/client/oracle/bin64 TDPO_NODE oracle_node TDPO_PSWDPATH /opt/tivoli/tsm/client/oracle/bin64

TDPO_NODE必须和dsm.sys里的NODENAME一致，不一致会报ANS1025E认证失败。配置完用 RMAN 发起一次全备：

rman target /

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

parms里指定TDPO_OPTFILE路径，RMAN 通过这个文件找到 TSM 的连接参数。备份跑起来后，服务端Q SESSION能看到oracle_node的会话，Q ACTLOG里能看到数据往VTLPOOL写。

5.3 Oracle 异机恢复的关键步骤

异机恢复是这套环境里最容易出问题的环节。目标机上装同样的 BA Client 和 TDPO，dsm.sys里NODENAME改成源节点的名字，服务端执行：

GRANT PROXY NODE TARGET=oracle_node AGENT=oracle_node

这条授权让目标机可以读源节点的备份数据。然后按顺序恢复：

/* 恢复 spfile */ RMAN> restore spfile to '/tmp/spfile.ora' from autobackup; /* 恢复 control file */ RMAN> restore controlfile from autobackup; /* 挂载数据库 */ RMAN> alter database mount; /* 恢复数据文件和归档 */ RMAN> restore database; RMAN> recover database; /* 打开数据库 */ RMAN> alter database open resetlogs;

restore spfile和restore controlfile依赖自动备份，如果源库没开CONTROLFILE AUTOBACKUP ON，这两步会失败，只能手工指定备份片。open resetlogs之后记得重新做一次全备，否则归档链断了。

5.4 DB2 客户端接入

DB2 客户端（192.168.81.12）装TIVsm-TDPDB2，配置dsm.opt和tdpdb2.opt，服务端注册节点db2_node。DB2 的备份命令：

db2 backup db sample use tsm

恢复用：

db2 restore db sample use tsm taken at <timestamp>

DB2 的 TSM 集成比 Oracle 简单，坑主要在db2set环境变量DSMI_CONFIG和DSMI_DIR要指向正确的路径，指错了会报SQL2036N找不到 TSM 配置。

6. 装完怎么验证：三条链路跑通才算数

环境装完，别急着说“好了”。这套东西的价值在于恢复，验证必须覆盖三条链路：虚拟带库读写、TSM 备份到带库、数据库异机恢复。我一般按下面的顺序走一遍，任何一步不通就停下来查，不要跳步。

6.1 带库链路验证

在 Mhvtl 机器上确认机械手和驱动器状态：

mtx -f /dev/sg10 status | head -20 lsscsi -g | grep -E 'mediumx|tape'

机械手status里Data Transfer Element和Storage Element都有输出，lsscsi能看到mediumx和tape两类设备，说明带库层正常。再在 TSM 服务器上AUDIT LIBRARY VTL_LIB，输出里没有ANR8447E之类的错误，卷列表完整。

6.2 备份链路验证

服务端查存储池和卷使用情况：

Q STGPOOL VTLPOOL F=D Q VOLHISTORY Q ACTLOG SEARCH=ANR

Q STGPOOL里Pct Util有增长，Q VOLHISTORY能看到备份卷的记录，Q ACTLOG里没有ANR9999D内部错误，说明数据确实写进去了。Oracle 端用RMAN> list backup summary;确认备份集存在，DB2 端用db2 list history backup all for sample确认。

6.3 恢复链路验证

异机恢复的验证标准不是“命令没报错”，而是“数据库能打开且数据对得上”。恢复完成后在目标库执行：

SELECT COUNT(*) FROM <业务表>; SELECT MAX(created_time) FROM <业务表>;

和源库对比行数和最新时间戳，一致才算恢复成功。DB2 同理，db2 connect to sample后查关键表。

有一次我在测试环境里恢复完 Oracle，alter database open resetlogs成功了，但业务表查出来少了几百行，最后发现是归档日志没恢复全，recover database时少指定了一个归档路径。从那以后我每次做异机恢复，都强制在recover之后、open之前跑一遍RMAN> validate database;，确认所有数据块和归档都校验通过再打开库。这个习惯帮我拦下过好几次“看起来成功、实际数据不全”的假恢复。希望这套流程能帮到你，少走我踩过的弯路。

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