TSM 6.3.5+Mhvtl虚拟带库搭建Oracle备份恢复测试环境

简介面向企业级备份恢复演练场景的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 映射回本机调试链路直接翻倍。主机角色主机名IP操作系统应用备份主服务器tsm6192.168.81.7Centos 6.6TSM 6.3.5虚拟带库mhvtl192.168.81.6Centos 6.6Mhvtl iSCSI备份客户端 1oracle192.168.81.11Linux 5.7Oracle 11g备份客户端 2db2192.168.81.12Linux 5.7DB2 9.72.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] nameCentOS-$releasever - Media baseurlfile:///mnt gpgcheck0 enabled1 EOF这里baseurl指向挂载点gpgcheck0是因为光盘源的签名校验在测试环境经常报错跳过不影响包完整性判断。顺手把yum.conf的keepcache保持默认 0缓存用完即清理磁盘空间有限时更稳。2.2 关掉防火墙与 SELinux别让它成为后面所有问题的替罪羊TSM 和 iSCSI 都要走固定端口测试环境里留着 iptables 和 SELinux 只会让排错多绕两圈。SELinux 改成disabled后必须重启才彻底生效只执行setenforce 0重启后又回来sed -i s/^SELINUX.*/SELINUXdisabled/ /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.5rpm 加源码两步走安装分两步先装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 L7004 驱动器、43 槽位、一台 STK L804 驱动器、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 :VolumeTagE01001L4槽位里有预置的 VolumeTag这是默认配置生成的虚拟磁带。把 1 号槽的带子装入 0 号驱动器再用 tar 写读验证一遍mtx -f /dev/sg10 load 1 0 tar -cvf /dev/st0 /boot tar -tvf /dev/st0tar能写能读说明虚拟带库链路完整。这里有个参数值得改默认单盘容量只有 500MB测试 Oracle 全备很快就满。编辑/etc/mhvtl/mhvtl.conf把CAPACITY2046单位 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 showtgtadm show能看到 target 和挂载的 LUN 才算成功。客户端TSM 服务器装iscsi-initiator-utilsiscsiadm -m discovery发现目标后 login再lsscsi -g应该能看到和带库机一致的设备。这里最常见的坑是映射了驱动器忘了映射机械手TSM 里定义库时找不到 changer 设备配置存储设备那一步直接卡死。4. TSM 6.3.5 服务端配置设备、卷、策略一条龙TSM 服务端装好后所有操作都在dsmadmc管理界面里完成。顺序不能乱先定义库和驱动器再定义卷并 checkin然后建存储池、配策略域最后才谈备份。跳过任何一步后面都会以各种奇怪的报错还回来。4.1 定义机械手与驱动器路径写错一个字母都不行进入管理界面后先定义 library再定义 path 和 drivedsmadmc DEFINE LIBRARY VTL1 LIBTYPESCSI DEFINE PATH TSM6 SERVER1 SRCTYPESERVER DESTTYPELIBRARY \ LIBRARYVTL1 DEVICE/dev/sg10 ONLINEYES DEFINE DRIVE VTL1 DRV0 DEVICE/dev/st0 ONLINEYES DEFINE PATH TSM6 DRV0 SRCTYPESERVER DESTTYPEDRIVE \ LIBRARYVTL1 DEVICE/dev/st0 ONLINEYESDEVICE必须是 iSCSI 客户端侧看到的真实设备名ONLINEYES少了会需要手动 online。定义完执行Q LIBRARY和Q DRIVE核对状态Q PATH里 ONLINE 一栏全为 YES 才算通。驱动器只定义 1 到 2 个就够测试全定义 8 个反而增加排查面。4.2 定义卷并 checkin让 TSM 认识带库里的带子库和驱动器通了接着把带子登记进 TSMDEFINE VOLUME E01001L4 CHECKIN LIBVOL VTL1 E01001L4 STATUSSCRATCH CHECKLABELYESSTATUSSCRATCH表示这盘带子作为可用的空带CHECKLABELYES会读卷标防止卷标和 TSM 记录不一致。带子多的时候可以用CHECKIN LIBVOL VTL1 SEARCHYES STATUSSCRATCH批量扫省得一条条敲。checkin 后Q VOL能看到状态从Pending变Scratch如果一直 Pending多半是驱动器没 online 或者卷标读不出来。4.3 存储池与策略域备份落到哪、留多久定义存储池指向 VTL1 的带子再建策略域绑定管理和默认管理类DEFINE STGPOOL VTLPOOL VTL1 DEFINE DOMAIN ORADOM DESCRIPTIONOracle backup domain DEFINE POLICYSET ORADOM STANDARD DEFINE MGMTCLASS ORADOM STANDARD MC_ORA DEFINE COPYGROUP ORADOM STANDARD MC_ORA STANDARD TYPEBACKUP \ DESTINATIONVTLPOOL VEREXISTS2 VERDELETED1 RETEXTRA30 RETONLY60这套参数的意思是同一文件保留 2 个版本删除后保留 1 个版本额外版本留 30 天最后版本留 60 天。测试环境空间有限别照抄生产参数尤其RETONLY设太大会把虚拟带子全占满。同时配一个本地磁盘存储池作为第二落点正好验证“备份到带库/本地磁盘”两种路径。4.4 文件系统备份验证先跑通最简单的再上数据库在客户端注册并绑定策略域后先备份一个小目录dsmc archive /etc -subdiryesdsmc是客户端命令行工具第一次运行要按提示填服务器地址和节点名。备份能在dsmadmc里用Q ACTLOG看到成功记录再去Q CONTENT VTLPOOL确认数据真的落在带库里一条完整链路才算走通。很多人在这一步只看到客户端提示成功就收工结果存储池根本没写进去后面 Oracle 备份再报错就分不清是哪一层的问题。5. Oracle 11g 接入 TSMNUB 客户端与手工备份Oracle 通过 RMAN 调用 TSM 的libobk库也就是 NUBTivoli 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_PATHtdpo.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和ENVrun { 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一类空间告警。检查项命令正常表现库与路径Q LIBRARY、Q PATH状态 Online路径 Online驱动器Q DRIVE全部 Online卷Q VOLScratch 或 Private无 Pending存储池Q STGPOOL有可用空间无 Full 告警第三条线是端到端。做一次 Oracle 全备加一次异机恢复恢复完成后在新库上执行SELECT COUNT(*)对比源表行数数量对上才算真跑通。DB2 9.7 同理备份到带库后恢复到另一实例用db2 list tablespaces和行数核对。我踩过最贵的一个坑就是只验证了备份作业成功没验证恢复直到真出事才发现授权文件没同步到恢复节点。从那以后我每次搭完这类测试环境都强制走一遍“备份、删库、异机恢复、核对行数”的全流程而不是停在Q BACKUP显示成功那一步。虚拟带库的容量参数、iSCSI 映射的设备名、tdpo.opt 的节点授权这三样只要有一处没跟上恢复现场就是一团乱。希望帮到你。本文还有配套的精品资源点击获取