企业官网建设流程全解析

简介：面向Linux运维、备份管理员与系统架构师的TSM 6.3 + Mhvtl + Oracle + DB2备份恢复测试文档，基于CentOS 6.5环境，完整覆盖虚拟带库搭建到数据库异机恢复的测试链路。资源为单个docx文档，共53页，压缩包大小1.83MB，目前已有241人学习下载。文档分四大部分：Mhvtl虚拟带库软件的安装配置（含编译安装、带库可用性测试、iSCSI映射等）、TSM服务端安装配置（主服务器、存储设备、卷与备份策略）、基于TSM的Oracle备份（NUB客户端安装与服务器端配置）、基于TSM的Oracle异机恢复（环境准备、授权调整、RMAN恢复步骤）。全文以实操步骤和命令为主线，附带详细的配置示例与恢复验证流程，适合需要快速搭建备份测试环境、验证TSM对Oracle保护方案或排查恢复问题的工程师参考。

1. 从零搭一套 TSM 6.3 备份链路：Mhvtl 虚拟带库的价值在哪

手头没有真实磁带库，又想验证 TSM 的策略、归档、Oracle RMAN 联动和异机恢复，这套测试环境是成本最低的方案。Mhvtl 在 Linux 上用内核模块模拟出机械手和磁带驱动器，把虚拟磁带落成普通文件，TSM 6.3.5 把它当真实带库管理，测试完删文件就能重置环境。

这套测试记录覆盖了四个关键环节：Mhvtl 虚拟带库安装与 iSCSI 映射、TSM 服务器端初始化、Oracle 11g 通过 RMAN 接入 TSM 备份、Oracle 异机恢复全流程，DB2 9.7 部分走的是同一套思路。适合刚接手备份项目、需要在隔离环境里把命令跑通的工程师，也适合给客户做 POC 前先自测一遍预案。

2. Mhvtl 虚拟带库搭建：从本地源到 iSCSI 映射的完整过程

Mhvtl 之所以适合做测试，是因为它在内核态实现了 SCSI 磁带设备和中继器设备，用户态进程负责槽位、卷标签和机械手动作。备份软件看到的是一台完整的 SCSI 带库，可以随意加载、卸载、格式化磁带，所有数据实际落在/opt/mhvtl目录下的文件中。这套机制让备份软件的行为和真实带库一致，省掉硬件成本和排障时间。

2.1 安装前准备：本地源与依赖包

文档环境是 CentOS 6.6，离线环境居多，先配本地 yum 源。把系统光盘挂载到/mnt，备份原有 repo 文件，再写一个指向光驱的 Media repo。这个过程我在多台虚拟机上重复过，关键点是gpgcheck=0，否则离线环境会卡在 GPG 校验上。

mount /dev/cdrom /mnt mkdir /etc/yum.repos.d/bak mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak vi /etc/yum.repos.d/CentOS-Media.repo

CentOS-Media.repo 内容：

[c6-media] name=CentOS-$releasever - Media baseurl=file:///mnt gpgcheck=0 enabled=1

这段逻辑是先清掉网络源，避免 yum 去外网超时，再把光驱挂载点作为唯一软件源。参数里enabled=1必须确认，否则 yum 默认禁用的 Media 源不会生效，装依赖时会报找不到包。

接下来装依赖包并创建 vtl 用户和目录：

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

/etc/mhvtl存放库配置，/opt/mhvtl存放虚拟磁带镜像文件，权限必须归 vtl 用户，否则 mhvtl 进程启动后无权创建磁带文件。kernel-devel和gcc是编译内核模块的硬依赖，少了后面make一定报错。

2.2 编译安装 Mhvtl：内核模块与配置文件

Mhvtl 分两部分：内核模块负责 SCSI 设备仿真，用户态工具负责机械手和卷管理。安装顺序不能反，先装 utils 包提供mtx和vtl命令，再解压源码编译内核模块。

rpm -ivh mhvtl-utils-1.5-2.x86_64.rpm unzip mhvtl-1.5-2.zip cd mhvtl-xxx/kernel make make install service mhvtl start chkconfig mhvtl on

编译时必须在 kernel 子目录下执行，make install会把生成的.ko模块复制到当前内核的 modules 目录。首次启动会在/etc/mhvtl下自动生成library_contents.10和library_contents.30两个库配置文件，分别对应 L700 和 L80 两台虚拟带库。看到 “Creating a default one” 是正常现象，不是报错。

启动后修改容量参数，默认每盘磁带只有 500MB，备份 Oracle 很快写满。文档里改成了 2GB：

vi /etc/mhvtl/mhvtl.conf

MHVTL_CONFIG_PATH=/etc/mhvtl CAPACITY=2046 VERBOSE=1 VTL_DEBUG=0

CAPACITY=2046单位是 MB，对应单盘虚拟磁带 2GB。测试环境建议设成 8192 或更大，否则全库备份中途报卷满，容易误判成备份策略问题。修改后重启 mhvtl 服务才生效。

2.3 验证带库设备：lsscsi 与 mtx 状态确认

装完先看设备是否被内核正确识别。lsscsi -g可以同时看到块设备和 SCSI 通用设备号，TSM 和 mtx 操作机械手时用的是sg设备号，这里最容易搞混。

lsscsi -g

输出关键行解读：

/dev/sch0是机械手控制通道，/dev/st0到/dev/st7是磁带设备。备份软件写数据走 st 设备，控制机械手走 sg 设备。如果lsscsi -g看不到 mediumx 类型设备，说明内核模块没加载成功，优先排查 2.2 步的编译。

验证机械手状态：

mtx -f /dev/sg10 status

正常会输出 4 个 Data Transfer Element 和 43 个 Storage Element，槽位里已经有 Mhvtl 预生成的卷标签，例如E01001L4。加载一盘磁带并测试读写：

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

load 1 0的含义是把 1 号槽位的磁带加载到 0 号驱动器。tar 写入/dev/st0能列出/boot下的文件列表，说明带库链路基本通了。我习惯用 tar 先验证再交给 TSM，这样能把“虚拟带库问题”和“备份软件配置问题”隔离成两段排查。

2.4 基于 tgt 的 iSCSI 映射：把带库共享给备份服务器

虚拟带库搭在本机只能本机用，测试拓扑里 TSM 主服务器和 Oracle 客户端都可能需要独立访问带库，标准做法是用 tgt 把 sg 设备映射成 iSCSI target。

yum install scsi-target-utils vi /etc/tgt/targets.conf

<target iqn.2015-06.local.vtl:tsm> # L700 机械手 backing-store /dev/sg10 # 磁带驱动器 backing-store /dev/sg2 backing-store /dev/sg3 backing-store /dev/sg4 backing-store /dev/sg5 initiator-address 192.168.81.0/24 </target>

这段配置把一个机械手和四个驱动器导出为 iSCSI LUN，backing-store直接指向 sg 设备。initiator-address限制客户端网段，防止其他虚拟机误连。保存后重启服务并查看导出列表：

service tgtd restart tgt-admin --show

tgt-admin --show能看到 target 下导出的每个 LUN，以及连接的 initiator 列表。客户端测通后，TSM 就可以把远程带库当本地 SCSI 带库来定义 path。这里有个常见混淆点：iSCSI 导出的是 sg 设备，不是 st 设备，TSM 定义驱动器路径时同样要写 sg 节点。

3. TSM 服务器端初始化：设备、存储池与策略域怎么对齐

TSM 装好后，最先做的是让服务器“看见”带库。很多新手直接把 tape 设备路径写进定义，结果机械手和驱动器逻辑错乱，备份作业卡在挂载卷上。原因是 TSM 对带库的描述分两层：物理设备层用define library和define drive，逻辑存储层用define devclass和define stgpool，两层顺序不能乱。

3.1 服务器安装与进入管理命令行

TSM 6.3.5 的安装包里包含 server 和 storage agent，装完后用dsmins建实例。实例名和环境变量都在安装过程里交互完成，随后用 dsmadmc 进入管理命令行：

dsmadmc -se=tsm61 -id=admin -pa=admin -dataonly=yes

-se指定服务器实例名，-id和-pa是管理员账号，-dataonly=yes表示只输出数据不印表头，写脚本时方便 grep。如果登录报 ANS1001 之类的认证错误，检查是否有大写字母和特殊字符的转义，密码含!或#时建议用单引号包起来。

3.2 定义库、驱动器与设备类：让 TSM 认识虚拟带库

在 dsmadmc 里逐条定义。先把 L700 定义成 SCSI 库，再把两个驱动器加入库，最后给每个驱动器指定 sg 设备路径：

define library LIBTP scsi define drive LIBTP DR0 define drive LIBTP DR1 define path TSM61 DR0 srctype=server device=/dev/sg2 define path TSM61 DR1 srctype=server device=/dev/sg3

注意device参数填的是/dev/sg2，不是/dev/st0。TSM 控制机械手和驱动器走的是 SCSI 通用设备命令，st 设备只负责数据流。填错后define path能成功，但tsm查询驱动器状态时报“无法打开设备”。

设备类决定了存储池的类型和卷的格式。LTO 类型设备类要指向刚定义的库：

define devclass VTLIB devtype=lto library=LIBTP define stgpool BACKPOOL VTLIB

devtype=lto表示卷格式采用 LTO 磁带格式，TSM 会把虚拟磁带当 LTO 卷来读写。define stgpool创建后端存储池，后续所有备份数据默认流到这个池。

3.3 定义卷与策略域：给池子里塞磁带

存储池建好后是空的，需要手工定义卷。文档里 L700 库的槽位自带卷标签，TSM 可以直接按标签定义：

define volume BACKPOOL E01001L4 define volume BACKPOOL E01002L4 define volume BACKPOOL E01003L4

如果不知道卷标签，先执行q drive和q libvol查询库内卷。定义卷时 TSM 会检查卷是否在机械手槽位中，不在槽位里的卷会报“卷不可用”。此时用mtx -f /dev/sg10 status确认卷位置，再决定是否加载。

策略域和策略集是 TSM 的逻辑管理单元。文件系统备份和数据库备份建议分开两个域，方便独立设置保留版本：

define domain TEST define policy TEST TESTPOL define mgmtclass TEST TESTPOL STANDARD copygroup TEST TESTPOL STANDARD TYPE=BACKUP

copygroup决定数据保留几个版本、保留天数。测试环境我习惯设成 2 个版本、保留 7 天，避免虚拟带库磁盘被历史版本塞满。

3.4 文件系统与本地磁盘备份验证

策略配完后先做一次文件系统备份，验证整条链路。客户端安装 TSM BA Client 后，配置 dsm.sys 指向服务器，然后发起增量备份：

dsmc inc /opt/mhvtl -subdir=yes

这条命令把/opt/mhvtl下所有文件增量备份到 BACKPOOL 存储池。观察输出里的状态码：

本地磁盘备份是另一条路径。TSM 支持把数据备份到本地磁盘池，适合测试恢复速度或作为二级存储：

define stgpool DISKPOOL DISK dsmc inc /opt/mhvtl -stgpool=DISKPOOL

-stgpool指定目标存储池，不指定时走默认池 BACKPOOL。磁盘池的好处是恢复时不涉及机械手加载，测试恢复流程时能少一层变量。

4. Oracle 备份接入 TSM：客户端配置与 RMAN 通道参数

Oracle 接入 TSM 的核心是 RMAN 的 SBT 类型通道。RMAN 通过 TSM 提供的 Oracle 数据保护组件把备份数据写到带库，组件负责把 RMAN 的备份块转换成 TSM 的备份对象。这里最关键的配置是客户端 dsm.sys 与服务器端节点授权，两边节点名对不上，RMAN 通道分配会直接失败。

4.1 客户端环境与 NUB 客户端安装

Oracle 服务器的准备工作分两步：确认 TSM 客户端能连通服务器，再安装 Oracle 备份组件。文档里把这个组件记为 NUB 客户端，对应 TSM Oracle Agent。安装前确保 Oracle 用户能读到客户端配置目录：

rpm -ivh NUB-client*.rpm mkdir -p /opt/tivoli/tsm/client/oracle/bin64 chown -R oracle:dba /opt/tivoli/tsm/client/oracle

客户端安装路径里的bin64目录是 Oracle 模块的二进制目录，RMAN 在分配 SBT 通道时会从这里加载共享库。权限归 oracle 用户，否则数据库进程启动子进程时读不到库文件，报 ORA-27211。

4.2 客户端 dsm.sys 与服务器端节点授权

客户端 dsm.sys 是 TSM 连接参数的唯一来源，写错一项就联不通。典型配置：

SErvername tsm61 COMMmethod TCPip TCPPort 1500 TCPServeraddress 192.168.81.7 NODename oracle PASSWORDaccess generate

SErvername是客户端定义的服务名，NODename是这台客户端在 TSM 服务器上注册的节点名。PASSWORDaccess generate表示密码由客户端自动生成并保存，避免每次备份都要交互输入。注意TCPServeraddress必须是 TSM 服务器可达的 IP，不能写主机名（除非已配 DNS）。

服务器端注册节点：

register node oracle oracle_pw archclass=ORACLE domain=TEST grant proxynode target=oracle agent=tsmserver

archclass=ORACLE指定节点类别为 Oracle 数据保护，grant proxynode是给服务器节点授权访问 Oracle 节点的备份数据。这一步不做，RMAN 恢复时无法读取带库上的备份对象。

4.3 RMAN 通道参数与手工备份

RMAN 通道通过PARMS指定 TSM Oracle Agent 的参数文件路径。我习惯把参数文件放在 Oracle 用户目录下：

TDPO_NODE oracle TDPO_OWNER oracle TDPO_PSWDPATH /home/oracle

TDPO_NODE对应 dsm.sys 里的节点名，TDPO_OWNER是运行 RMAN 的数据库用户。然后发起一次手工备份：

rman target / nocatalog

run { allocate channel c1 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/home/oracle/tdpo.opt)'; backup database plus archivelog format 'bk_%U'; release channel c1; }

type 'sbt_tape'声明走 TSM 的磁带通道，TDPO_OPTFILE指向参数文件。plus archivelog连归档日志一起备份，这是恢复数据库到一致状态的前提。执行后看 RMAN 输出，出现channel c1: starting和备份完成信息就是通了；如果报RMAN-00569或ORA-27206，查客户端dsmerror.log和服务器端dsmserv.log的 ANR 编号。

5. TSM 备份测试避坑：五个典型现场问题与排查记录

这套环境我前后搭过好几次，真正花时间的不是安装，而是装好后第一个备份作业跑不通时的排查。下面五条是重复率最高的坑，每一条我都附了现象、原因和解决过程。

5.1 现象：lsscsi 看不到磁带设备，只有机械手

装了 mhvtl 并service mhvtl start后，lsscsi -g只显示 mediumx 类型设备，tape 类型的 st0、st1 全部缺席。驱动器和机械手不同时出现，TSM 定义驱动器时直接报设备不存在。

原因出在 kernel 子目录的编译模块没有适配当前内核版本。Mhvtl 的源码里，模块是针对旧内核 API 写的，CentOS 6.6 自带的内核头文件如果发生 API 偏移，make install虽然成功但模块加载失败。排查时执行lsmod | grep mhvtl，发现模块列表为空。

解决方法是重编内核模块，并确认加载后设备节点生成：

cd mhvtl-xxx/kernel make clean make make install depmod -a modprobe mhvtl service mhvtl restart lsscsi -g

make clean很关键，否则残留的.o文件会掩盖代码变更。depmod -a重新生成模块依赖树，modprobe mhvtl手动加载验证。看到 tape 设备出现在 lsscsi 输出里，再继续配置 TSM。

5.2 现象：mtx status 显示槽位全部 Empty

Mhvtl 启动正常，设备节点都在，但mtx -f /dev/sg10 status显示所有 Storage Element 都是 Empty，TSM 定义卷时提示找不到指定卷。

原因是首次启动自动生成的library_contents文件没有初始化槽位映射。Mhvtl 的默认库配置生成逻辑只在文件不存在时执行，如果启动过程中写入中断，或者文件被误删后重启，就会得到一份空槽位的库。

解决方法是停止服务，删除配置重新生成：

service mhvtl stop rm -f /etc/mhvtl/library_contents.10 service mhvtl start mtx -f /dev/sg10 status

重启后会重新生成默认库文件，槽位里出现 E01001L4 这类预置卷标签。如果不想用默认标签，可以编辑/etc/mhvtl/library_contents.10自定义卷集，改完后重启服务。

5.3 现象：iSCSI 客户端 discovery 正常但 login 失败

备份服务器执行iscsiadm -m discovery -t sendtargets -p 192.168.81.6能看到 target，但iscsiadm -m node -T iqn... -p ... -l登录时卡住或报连接超时。

原因是 tgt 的 ACL 限制。我在 2.4 节配置里写了initiator-address 192.168.81.0/24，如果客户端 IP 不在这个网段，或者 tgt 服务没有重新加载配置，登录就会超时。查看tgtadm --lld iscsi --op show --mode target能看到 target 下没有任何 active conn。

解决方法是先放通无限制测试，再收紧 ACL：

vi /etc/tgt/targets.conf # 注释掉 initiator-address 行 service tgtd reload tgt-admin --show

如果直接写initiator-address 192.168.81.11精确到单机，检查客户端 IP 是否有变化。另外 CentOS 6.6 的 iptables 如果开着，tgt 的 3260 端口会被挡，放行后重试。一般我搭建时会先service iptables stop，全部调通后再按需打开策略。

5.4 现象：TSM define path 成功，但驱动器状态为 unavailable

用/dev/st0定义了驱动器路径，q drive显示路径存在，但q path里驱动器状态一直是 unavailable，备份作业报“驱动器打开失败”。

原因很明显，TSM 控制磁带驱动器走 SCSI 通用设备层，st 设备是字符流设备，不支持 TSM 需要的 SCSI 控制命令。TSM 文档里明确要求 device 参数填 sg 设备号，我用/dev/st0是照搬 tar 命令的习惯。

解决方法是把路径里的 st 设备替换成 sg 设备，删除重定义：

delete path TSM61 DR0 srctype=server define path TSM61 DR0 srctype=server device=/dev/sg2

如果 sg 设备号不确定，执行lsscsi -g对照。L700 库的第三列是 st 设备，第四列是 sg 设备，定义时只看第四列。这个坑排掉后，q drive里驱动器很快变成 available。

5.5 现象：RMAN 备份报 ANR0404 或连接超时

Oracle 客户端能 ping 通 TSM 服务器，但 RMAN 分配通道后报 ANR0404 或cannot open shared library，备份无法启动。

原因分两类：一是 dsm.sys 里的TCPPort和服务器端dsmserv.opt的端口不一致，二是 NUB 组件路径权限不对导致共享库加载失败。ANR0404 更多指向 TSM 服务器无法连接客户端节点，常见于节点名大小写不符。

排查顺序我一般从服务器端日志入手：

grep "ANR0404\|ANR9999D" /opt/tivoli/tsm/server/dsmserv.log | tail -50

看到报错里带节点名，回客户端检查 dsm.sys 的NODename是否与 register node 一致。端口问题则用netstat -anp | grep 1500确认监听端口。共享库问题执行：

ls -l /opt/tivoli/tsm/client/oracle/bin64/*.so

如果属主不是 oracle，用chown oracle:dba修正。RMAN 通道分配是动态加载库的过程，权限和属主不对必然失败。这套排查路径适用于大部分 SBT 通道连接类错误。

6. Oracle 异机恢复演练：授权、RMAN 与验证三板斧

异机恢复的本质是把原节点的备份数据，通过 TSM 授权机制交给新主机读取。授权不到位，RMAN 能启动但找不到备份集。做完以下三步，恢复流程基本可以固化下来。

# 服务器端注册新主机节点并授权代理访问原节点 register node newhost newhost_pw archclass=ORACLE domain=TEST grant proxynode target=oracle agent=newhost

grant proxynode把原节点 oracle 的备份数据授权给 newhost 节点读取。新主机装好相同版本的 Oracle Agent 后，创建恢复目录并启动 RMAN：

mkdir -p $ORACLE_HOME/dbs mkdir -p $ORACLE_HOME/oradata

RMAN 执行四个阶段恢复：

startup nomount; restore spfile from autobackup; restore controlfile from autobackup; alter database mount; restore database; recover database; alter database open resetlogs;

这里的from autobackup要求备份时启用了控制文件自动备份，原环境如果没有开启，RMAN 会报找不到备份。验证阶段我一般查询实例状态和表空间文件：

select status from v$instance; select name, open_mode from v$database; select name from v$datafile;

open resetlogs打开数据库后，数据文件路径如果和原机不一致，需要手工set newname重映射。这一步最容易因为路径不一致恢复失败，我的习惯是在restore database之前先report schema对比路径，差异项提前处理。从那以后我每次做异机恢复演练，都把授权、路径核对、自动备份检查这三件事放最前面，先把最容易翻车的地方钉死再动 RMAN。这套流程熟练后，Oracle 异机恢复基本能从半小时压缩到十五分钟，希望帮到你。

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