简介资源包内含一份docx格式技术文档大小约1.83MB围绕TSM 6.3 Linux、Mhvtl、Oracle与DB2的备份恢复测试展开。内容面向系统运维、备份管理员及数据库DBA适合在企业级备份恢复方案验证或项目实施前参考。文档以CentOS 6.5为实验平台第一部分介绍Mhvtl虚拟带库软件包括在Linux下编译安装、配置以及带库可用性测试第二部分讲解TSM主服务器安装配置包括存储设备定义、卷配置、备份策略创建并执行备份。第三部分是基于TSM的Oracle备份从客户端环境准备、NUB客户端安装到服务器端配置再到手工发起备份。第四部分为Oracle异机恢复涉及环境准备、修改TSM授权文件并通过RMAN和TSM命令依次恢复Spfile、控制文件、数据文件、归档日志最后打开数据库。整份文档操作步骤完整命令具体可帮助读者搭建一套可运行的TSM加Mhvtl备份恢复测试环境掌握虚拟带库与TSM配合完成数据库备份恢复的关键方法。目前已有241人学习适合需要落地同类备份方案的工程师。1. 这套备份恢复测试在解决什么问题把标题拆开看这是一个典型的“没有物理磁带库也要把备份链路完整落地”的测试场景。TSM 6.3 是服务端Mhvtl 是跑在 Linux 上的虚拟磁带库Oracle 和 DB2 是真正要被保护的数据库。对绝大多数备份运维人员来说手头不一定有带库真机但项目验收、方案交付又必须证明备份能写进去、能读出来、数据库能恢复。这套组合解决的问题就是用一台普通 Linux 服务器模拟真实带库行为让 TSM 6.3 认认真真走完从服务端、存储池、策略到 Oracle RMAN/DB2 备份调度和恢复演练的完整闭环而且结果可以拿给项目方看。适合谁正在做备份方案选型测试、需要输出测试报告、或者想搞懂 TSM 与数据库备份机制的人。2. 用 Mhvtl 在 Linux 上搭一套虚拟磁带库最小可跑环境2.1 为什么数据库备份测试要用虚拟磁带库而不是直接写磁盘路径很多刚接触 TSM 的人会问反正都是存文件为什么不能让 TSM 直接把备份写到普通目录原因在于 TSM 6.3 的备份域模型里“磁带库”是一个带设备语义的对象。数据库客户端通过 SBTSystem Backup to Tape接口和带库驱动打交道驱动会向 TSM 请求挂载一卷磁带、定位到特定位置如果底层没有真正的磁带设备语义RMAN 和 DB2 的备份通道根本拉不起来。Mhvtl 做的就是把这层语义模拟出来它把文件按卷组织通过 SCSI 命令仿真让上层以为自己在操作一台 LTO 带库。备份数据最终落在 Linux 文件系统里但协议栈上的体验与真实带库一致。我一般会在 CentOS 或 Ubuntu 服务器上装 Mhvtl原因很简单它不需要额外硬件普通 KVM 虚机也能跑而且支持多驱动器、多槽位足够模拟出测试所需的带库拓扑。更重要的一点Mhvtl 能让你反复做恢复测试而不心疼磁带。真实带库的驱动器寿命是有限资源虚拟环境下随便折腾出问题随时清掉重来这本身就是测试环境最大的价值。2.2 安装 Mhvtl 并验证设备是否被系统识别以常见发行版为例安装 Mhvtl 需要先确认系统里有 sg3_utils 和 lsscsi这两个工具负责底层 SCSI 设备的管理与查看。编译安装完成后配置集中在 /etc/mhvtl/device.conf它描述了一台虚拟带库里有几个驱动器、多大容量、什么类型。下面是一个最小配置# /etc/mhvtl/device.conf # VTL: 虚拟带库标识 VTL 1 # 第一个驱动器模拟 LTO-5容量单位是 MB DRIVE 1 LTO5 400000 # 槽位定义给 TSM 提供可用的空带 SLOT 1 40配置的含义VTL 1 表示创建一台虚拟带库DRIVE 1 LTO5 400000 表示第一个驱动器的类型是 LTO-5、容量按 400 GB 模拟SLOT 1 40 表示 40 个槽位。改完配置后重启 mhvtl 服务再用 lsscsi 确认系统是否识别出新的磁带设备systemctl restart mhvtl lsscsi -g | grep -E tape|mediumx如果看到类似 /dev/sgX 和 /dev/stX 的设备节点输出说明 Mhvtl 已经把虚拟带库暴露给了操作系统。注意我强调在配置 TSM 之前必须先确认设备节点因为 Mhvtl 在重启后设备号可能变化这块如果不做前置检查后面 TSM 定义路径时很容易踩坑。2.3 给虚拟带库装磁带并确认机械臂可用带库只有驱动器还不够TSM 做备份调度时需要一个“机械臂”来抓取磁带放入驱动器这个动作在 Mhvtl 里由虚拟的 medium changer 承担。启动服务后可以用 mtx 工具测试机械臂动作是否正常mtx -f /dev/sg5 status mtx -f /dev/sg5 load 1 1 mtx -f /dev/sg5 unload 1 1先看 status 是否列出了 40 个槽位和驱动器然后执行 load 1 1意思是把 1 号槽位的磁带装载进 1 号驱动器再 unload。能成功执行这两步说明机械臂通路正常。这一步很容易被跳过但它是 TSM 定义路径之前必须确认的底层能力如果这里失败后面 TSM 里的 checkout/checkin 全都会报设备忙或未就绪。我遇到过一上来就配 TSM、结果所有命令都卡在挂载阶段的情况回头排查才发现是 Mhvtl 的 changer 设备没加载对。3. TSM 6.3 服务端初始化从设备定义到策略绑定3.1 初始化 TSM 实例与管理员账号Mhvtl 环境就绪后开始安装 TSM 6.3 服务端。安装完成后第一步是初始化实例用 dsmserv 命令创建数据库和日志卷。TSM 服务端的元数据本身存放在 TSM 的数据库里这个数据库也需要分配存储空间。常见做法是单独给 TSM 数据库卷一个目录避免和备份数据混在一起mkdir -p /tsmdata/db /tsmdata/log dsmserv format -data /tsmdata/db/tsmdb.vol -log /tsmdata/log/tsmlog.vol dsmservformat 命令创建了 TSM 数据库卷和日志卷dsmserv 启动服务端进程。首次启动后需要用 dsmadmc 进入管理命令行创建管理员 ID 并设置密码dsmadmc -seidadmin -passwordadmin grant authority admin sysadmin这里 -seid 和 -password 的默认值在安装文档里都有生产环境务必改成强密码。grant authority 把系统管理员权限授予该用户。TSM 6.3 的管理逻辑是管理员登录后所有后续操作都在 dsmadmc 命令行里完成。我一般把这一步称为“服务端的户口本”后面的设备、存储池、策略全部登记在这个实例下。3.2 定义磁带库、路径与驱动器TSM 服务端不会自动发现 Mhvtl 的设备必须手动定义。注意设备号要以上一步 lsscsi 查到的为准Mhvtl 重启后这个号会变这也是整个测试流程里最容易翻车的环节。下面是一组完整的定义命令# 定义磁带库类型为 SCSI define library MHVTL_LIB librarytypeSCSI # 定义服务端到库控制器的路径 define path TSM_SERVER MHVTL_LIB srctserver desttlibrary device/dev/sg5 online # 定义驱动器 define drive MHVTL_LIB DRIVE01 # 定义路径的驱动器部分 define path TSM_SERVER DRIVE01 srctserver desttdrive libraryMHVTL_LIB device/dev/sg6 onlinedefine library 的 librarytypeSCSI 表示这是一台通过 SCSI 控制的带库对应 Mhvtl 暴露的 medium changer 设备。define path 是告诉 TSM 服务端通过哪个设备节点访问库控制器和驱动器。DRIVE01 是驱动器在 TSM 侧的逻辑名可以和 Mhvtl 的驱动器编号不对应但路径必须指对。最后可以用 q path 和 q drive 查看定义是否生效q path q drive运行后如果状态显示 ONLINE说明服务端已经能访问虚拟带库的机械臂和驱动器。这里有个细节TSM 服务端主机名 TSM_SERVER 要和你当前服务器的主机名一致很多人在这里顺手写错结果路径定义总是报错。3.3 定义设备类、存储池与策略域设备类决定备份卷的写入格式存储池是 TSM 管理物理卷的容器策略域决定备份保留多久。三者缺一不可顺序通常是先设备类再存储池最后策略。用下面一组命令完成# 定义设备类指向库并指定格式 define devclass MHVTL_CLS devtypeLTO libraryMHVTL_LIB # 定义存储池绑定设备类 define stgpool VTLPOOL MHVTL_CLS maxscratch50 # 定义策略域与管理类 define domain BACKUP_DOM define mgmtclass BACKUP_DOM STANDARD_MC # 绑定管理类到存储池 define copygroup BACKUP_DOM STANDARD_MC STANDARDdevclass 里的 devtypeLTO 要和 Mhvtl 模拟的 LTO-5 匹配TSM 6.3 支持直接识别 LTO 类型。VTLPOOL 创建时 maxscratch50 意思是允许存储池动态创建最多 50 卷临时磁带这个参数太小时备份会在高峰期因为无可用卷而失败。管理类 BACKUP_DOM 下的 copygroup 里需要定义备份数据的保留策略# 在 copygroup 里定义数据保留版本与时间 update copygroup BACKUP_DOM STANDARD_MC STANDARD verexists7 verdeleted2 retextra1verexists7 表示每个文件保留 7 个版本verdeleted2 表示文件被删除后再保留 2 个版本retextra1 表示归档类数据额外保留 1 份。这个参数组合是我做测试常用的保守值既能让恢复测试有足够版本可选又不会让虚拟磁带库被历史版本塞满。3.4 注册数据库节点并测试一次手工备份TSM 的服务端配置最终要落到“谁来备份”的问题上。Oracle 和 DB2 在 TSM 里都以节点的身份出现节点名需要和数据库客户端配置完全一致。注册两个节点的命令如下register node ORACLE_NODE orapass register node DB2_NODE db2pass密码是客户端连接时用的测试环境可以简单些生产环境必须用加密传输和复杂密码。节点注册后就可以通过 TSM 的命令行发起一次手工备份验证最直观的方式是备份 TSM 自身的数据库backup db q processbackup db 会把 TSM 元数据写入 VTLPOOLq process 可以观察当前有没有活动进程。我建议第一次跑到这里就停下来先确认 TSM 自身能备份成功再继续配置数据库客户端。这样排查问题时就能划定边界TSM 链路有问题还是数据库客户端配置有问题。4. Oracle 与 DB2 备份恢复测试两套通道同一套验证逻辑4.1 Oracle 侧安装 TSM 客户端并配置 tdpo.optOracle 备份走的是 SBT 接口TSM 6.3 时代对应的组件是 TDP for Oracle。安装完成后配置集中在 dsm.sys 和 tdpo.opt 两个文件。dsm.sys 描述服务端连接信息tdpo.opt 描述备份节点的可选参数。下面是一个典型的配置# /opt/tivoli/tsm/client/oracle/bin/tdpo.opt TDPO_NODE ORACLE_NODE TDPO_PSWDPATH /opt/tivoli/tsm/client/oracle/bin TDPO_MGMTCLASS STANDARD_MC TDPO_DATAFORMAT 2TDPO_NODE 必须和 TSM 服务端注册的节点名一致TDPO_PSWDPATH 指定保存密码文件的位置TDPO_MGMTCLASS 指定备份写入哪个管理类。TDPO_DATAFORMAT 2 使用 TSM 的专有格式恢复时只能通过 TSM 读取。设置好之后用 dsmc 命令测试连通性dsmc -seidORACLE_NODE -passwordorapass q nodename能查询到节点信息说明客户端与服务端的握手成功。这一步不通后面 RMAN 里 100% 报 SBT 通道初始化失败。4.2 用 RMAN 发起 Oracle 备份与恢复验证连通性确认后RMAN 侧只需要分配一个 SBT 通道。备份脚本如下rman target / run { allocate channel ch1 type sbt_tape parms ENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/bin/tdpo.opt); backup database plus archivelog; release channel ch1; }allocate channel 里的 sbt_tape 是固定写法关键在于 ENV 参数必须指向 tdpo.opt 的绝对路径。RMAN 启动时会把控制文件里记录的备份信息与 TSM 的卷对应起来。备份完成后用 list backup 查看备份集然后做一次恢复验证rman target / run { allocate channel ch1 type sbt_tape parms ENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/bin/tdpo.opt); restore database; recover database; }restore 是从 TSM 卷上把数据文件读回来recover 是应用归档日志把数据库推进到一致状态。很多团队只做备份不做恢复这是自欺欺人。在测试环境里我强烈建议每次备份后立刻做一次 restore 到不同目录的演练因为“备份成功”和“能恢复”之间隔着一整条链路。4.3 DB2 侧配置 TSM 参数并执行备份DB2 走的是 TSM 的 API 客户端不依赖 RMAN配置直接在 DB2 实例参数里完成。需要设置三个参数TSM_MGMTCLASS、TSM_NODE、TSM_OWNER。下面以 SAMPLE 库为例db2 update db cfg for SAMPLE using TSM_MGMTCLASS STANDARD_MC TSM_NODE DB2_NODE TSM_OWNER db2inst1TSM_OWNER 填写运行 DB2 实例的操作系统用户名TSM 会以这个用户的身份去访问密码文件。配置完成后发起一次备份db2 backup db SAMPLE use TSM db2 list history backup all for SAMPLEbackup 命令会调用 TSM 的 API 把数据库写入虚拟磁带库list history 能看到备份映像的时间戳。DB2 的备份映像在 TSM 里是以“节点时间戳”为标识的后续恢复必须精确指定。4.4 DB2 恢复验证的两种方式DB2 恢复有两种典型场景恢复到一个全新数据库或恢复到原库并前滚到指定时间点。全库恢复的命令如下db2 restore db SAMPLE from TSM taken at 2025-01-10-12.00.00taken at 后面的时间戳来自 list history 的输出写错一个字符就会报映像不存在。如果还有归档日志要前滚追加 rollforward 命令db2 rollforward db SAMPLE to end of logs恢复测试里最常见的失败是时间戳写错、或者原库仍有连接会话导致文件被占用。习惯上我会先把应用连接断开再执行 restore。5. 避坑Mhvtl、TSM 与数据库客户端之间的典型故障5.1 现象TSM 定义路径时提示设备不可用Mhvtl 重启后/dev/sg5、/dev/sg6 这类设备号经常前后对调TSM 里定义好的路径就会指向错误的设备。原因Linux 对 SCSI 设备的命名取决于内核枚举顺序Mhvtl 服务启动时机变化会改变枚举结果。解决不要用固定设备号先执行 lsscsi -g 查看当前实际设备再重新 define path。更彻底的办法是给 Mhvtl 设备写 udev 规则根据序列号生成固定软链接让 TSM 始终引用同一个路径。5.2 现象Oracle 的 RMAN 通道一直处于等待状态分配 SBT 通道后RMAN 长时间停在 Waiting for tape mount没有任何报错。原因TSM 服务端没有可用空卷存储池 maxscratch 设置过小或虚拟带库里没有足够空带。解决用 q stgpool VTLPOOL 查看 available scratch volume 数量如果为 0在 TSM 里执行 checkout 把带库里的空带移入存储池或者直接更新 maxscratch 到更大值。我习惯把 maxscratch 设到 50Mhvtl 里预留 10 卷空带专门给测试用。5.3 现象DB2 备份报 TSM 密码文件认证失败db2 backup 时提示 TSM password file 无法读取。原因TSM_OWNER 指定的用户和实际执行命令的操作系统用户不一致密码文件存在了别的用户目录下。解决先确认执行 db2 backup 的 Linux 用户再在 TSM 客户端执行 dsmc 生成密码文件时用同一用户。常见做法是直接切换到 db2inst1 用户登录再执行 dsmc 初始化密码文件。5.4 现象恢复测试把备份卷删没了restore 时提示备份映像的卷已被回收TDPO 返回卷不可用。原因TSM 存储池启用了自动回收reclamation测试环境的保留期设置太短备份数据还没过期就被回收掉了。解决在测试阶段把 copygroup 的 verexists 调大并把存储池的 reclamation threshold 调高比如设到 90意思是卷使用率达到 90% 才触发回收。生产环境按业务要求设置测试环境以“能反复恢复”为第一目标。5.5 现象Mhvtl 主机重启后 TSM 服务端连不上虚拟带库原因Mhvtl 服务没有设置开机自启或者 TSM 服务端先于 Mhvtl 启动导致驱动器和库路径全部掉线。解决把 mhvtl 加入 systemctl enable在 TSM 服务启动前确认 lsscsi 输出正常。稳妥的做法是加一个监控脚本检测到 Mhvtl 设备不存在时不自启 TSM避免服务端在 10 分钟超时上反复重试带来的日志刷屏。6. 把恢复测试做成日常习惯一个可以反复执行的验证脚本测试环境的价值在于可重复。我把整套验证固化成一个脚本每次改完配置先跑一遍确认链路完好再交给项目方。脚本主要检查四件事Mhvtl 设备是否在线、TSM 存储池状态、Oracle 和 DB2 各自的备份映像时间、以及最近一次的恢复是否成功。骨架如下#!/bin/bash set -e # 1. 检查 Mhvtl 设备 lsscsi -g | grep -E tape|mediumx # 2. 检查 TSM 存储池和驱动器 dsmadmc -seidadmin -passwordadmin q stgpool VTLPOOL | grep AVAILABLE dsmadmc -seidadmin -passwordadmin q drive | grep ONLINE # 3. 检查数据库侧最近的备份映像 rman target / catalog /dev/null EOF list backup of database completed after sysdate-1; EOF # 4. 打印 DB2 历史备份 db2 list history backup all for SAMPLE | grep 2025-脚本里没有实际的恢复动作它只是把“万事俱备”的状态用命令确认一遍。真正恢复验证我要求每周至少手动做一次Oracle 恢复到一个中间目录、DB2 恢复到独立实例而不是在原库上覆盖。这能保证一旦生产环境出问题团队对恢复流程有肌肉记忆。另一个实用技巧是给 TSM 启用心跳监控。在 dsmadmc 里定义 schedule让系统每 30 分钟对 VTLPOOL 做一次一致性检查发现卷损坏立刻告警。虚拟带库的卷本质是文件磁盘损坏比物理磁带更难发现定时检查比事后补救值钱得多。我对这套环境的最终态度是备份测试不是“跑通一次备份”就结束而是让恢复成为习惯。没有恢复验证的备份测试文档充其量是一份记录不是一套可交付的能力。在这套 Mhvtl TSM Oracle DB2 的框架里把恢复演练次数做到和备份次数一样频繁才是真正把环境用到位了。希望这些步骤和教训能帮到你。本文还有配套的精品资源点击获取 基于Mhvtl虚拟磁带库的TSM备份恢复测试实践
简介资源包内含一份docx格式技术文档大小约1.83MB围绕TSM 6.3 Linux、Mhvtl、Oracle与DB2的备份恢复测试展开。内容面向系统运维、备份管理员及数据库DBA适合在企业级备份恢复方案验证或项目实施前参考。文档以CentOS 6.5为实验平台第一部分介绍Mhvtl虚拟带库软件包括在Linux下编译安装、配置以及带库可用性测试第二部分讲解TSM主服务器安装配置包括存储设备定义、卷配置、备份策略创建并执行备份。第三部分是基于TSM的Oracle备份从客户端环境准备、NUB客户端安装到服务器端配置再到手工发起备份。第四部分为Oracle异机恢复涉及环境准备、修改TSM授权文件并通过RMAN和TSM命令依次恢复Spfile、控制文件、数据文件、归档日志最后打开数据库。整份文档操作步骤完整命令具体可帮助读者搭建一套可运行的TSM加Mhvtl备份恢复测试环境掌握虚拟带库与TSM配合完成数据库备份恢复的关键方法。目前已有241人学习适合需要落地同类备份方案的工程师。1. 这套备份恢复测试在解决什么问题把标题拆开看这是一个典型的“没有物理磁带库也要把备份链路完整落地”的测试场景。TSM 6.3 是服务端Mhvtl 是跑在 Linux 上的虚拟磁带库Oracle 和 DB2 是真正要被保护的数据库。对绝大多数备份运维人员来说手头不一定有带库真机但项目验收、方案交付又必须证明备份能写进去、能读出来、数据库能恢复。这套组合解决的问题就是用一台普通 Linux 服务器模拟真实带库行为让 TSM 6.3 认认真真走完从服务端、存储池、策略到 Oracle RMAN/DB2 备份调度和恢复演练的完整闭环而且结果可以拿给项目方看。适合谁正在做备份方案选型测试、需要输出测试报告、或者想搞懂 TSM 与数据库备份机制的人。2. 用 Mhvtl 在 Linux 上搭一套虚拟磁带库最小可跑环境2.1 为什么数据库备份测试要用虚拟磁带库而不是直接写磁盘路径很多刚接触 TSM 的人会问反正都是存文件为什么不能让 TSM 直接把备份写到普通目录原因在于 TSM 6.3 的备份域模型里“磁带库”是一个带设备语义的对象。数据库客户端通过 SBTSystem Backup to Tape接口和带库驱动打交道驱动会向 TSM 请求挂载一卷磁带、定位到特定位置如果底层没有真正的磁带设备语义RMAN 和 DB2 的备份通道根本拉不起来。Mhvtl 做的就是把这层语义模拟出来它把文件按卷组织通过 SCSI 命令仿真让上层以为自己在操作一台 LTO 带库。备份数据最终落在 Linux 文件系统里但协议栈上的体验与真实带库一致。我一般会在 CentOS 或 Ubuntu 服务器上装 Mhvtl原因很简单它不需要额外硬件普通 KVM 虚机也能跑而且支持多驱动器、多槽位足够模拟出测试所需的带库拓扑。更重要的一点Mhvtl 能让你反复做恢复测试而不心疼磁带。真实带库的驱动器寿命是有限资源虚拟环境下随便折腾出问题随时清掉重来这本身就是测试环境最大的价值。2.2 安装 Mhvtl 并验证设备是否被系统识别以常见发行版为例安装 Mhvtl 需要先确认系统里有 sg3_utils 和 lsscsi这两个工具负责底层 SCSI 设备的管理与查看。编译安装完成后配置集中在 /etc/mhvtl/device.conf它描述了一台虚拟带库里有几个驱动器、多大容量、什么类型。下面是一个最小配置# /etc/mhvtl/device.conf # VTL: 虚拟带库标识 VTL 1 # 第一个驱动器模拟 LTO-5容量单位是 MB DRIVE 1 LTO5 400000 # 槽位定义给 TSM 提供可用的空带 SLOT 1 40配置的含义VTL 1 表示创建一台虚拟带库DRIVE 1 LTO5 400000 表示第一个驱动器的类型是 LTO-5、容量按 400 GB 模拟SLOT 1 40 表示 40 个槽位。改完配置后重启 mhvtl 服务再用 lsscsi 确认系统是否识别出新的磁带设备systemctl restart mhvtl lsscsi -g | grep -E tape|mediumx如果看到类似 /dev/sgX 和 /dev/stX 的设备节点输出说明 Mhvtl 已经把虚拟带库暴露给了操作系统。注意我强调在配置 TSM 之前必须先确认设备节点因为 Mhvtl 在重启后设备号可能变化这块如果不做前置检查后面 TSM 定义路径时很容易踩坑。2.3 给虚拟带库装磁带并确认机械臂可用带库只有驱动器还不够TSM 做备份调度时需要一个“机械臂”来抓取磁带放入驱动器这个动作在 Mhvtl 里由虚拟的 medium changer 承担。启动服务后可以用 mtx 工具测试机械臂动作是否正常mtx -f /dev/sg5 status mtx -f /dev/sg5 load 1 1 mtx -f /dev/sg5 unload 1 1先看 status 是否列出了 40 个槽位和驱动器然后执行 load 1 1意思是把 1 号槽位的磁带装载进 1 号驱动器再 unload。能成功执行这两步说明机械臂通路正常。这一步很容易被跳过但它是 TSM 定义路径之前必须确认的底层能力如果这里失败后面 TSM 里的 checkout/checkin 全都会报设备忙或未就绪。我遇到过一上来就配 TSM、结果所有命令都卡在挂载阶段的情况回头排查才发现是 Mhvtl 的 changer 设备没加载对。3. TSM 6.3 服务端初始化从设备定义到策略绑定3.1 初始化 TSM 实例与管理员账号Mhvtl 环境就绪后开始安装 TSM 6.3 服务端。安装完成后第一步是初始化实例用 dsmserv 命令创建数据库和日志卷。TSM 服务端的元数据本身存放在 TSM 的数据库里这个数据库也需要分配存储空间。常见做法是单独给 TSM 数据库卷一个目录避免和备份数据混在一起mkdir -p /tsmdata/db /tsmdata/log dsmserv format -data /tsmdata/db/tsmdb.vol -log /tsmdata/log/tsmlog.vol dsmservformat 命令创建了 TSM 数据库卷和日志卷dsmserv 启动服务端进程。首次启动后需要用 dsmadmc 进入管理命令行创建管理员 ID 并设置密码dsmadmc -seidadmin -passwordadmin grant authority admin sysadmin这里 -seid 和 -password 的默认值在安装文档里都有生产环境务必改成强密码。grant authority 把系统管理员权限授予该用户。TSM 6.3 的管理逻辑是管理员登录后所有后续操作都在 dsmadmc 命令行里完成。我一般把这一步称为“服务端的户口本”后面的设备、存储池、策略全部登记在这个实例下。3.2 定义磁带库、路径与驱动器TSM 服务端不会自动发现 Mhvtl 的设备必须手动定义。注意设备号要以上一步 lsscsi 查到的为准Mhvtl 重启后这个号会变这也是整个测试流程里最容易翻车的环节。下面是一组完整的定义命令# 定义磁带库类型为 SCSI define library MHVTL_LIB librarytypeSCSI # 定义服务端到库控制器的路径 define path TSM_SERVER MHVTL_LIB srctserver desttlibrary device/dev/sg5 online # 定义驱动器 define drive MHVTL_LIB DRIVE01 # 定义路径的驱动器部分 define path TSM_SERVER DRIVE01 srctserver desttdrive libraryMHVTL_LIB device/dev/sg6 onlinedefine library 的 librarytypeSCSI 表示这是一台通过 SCSI 控制的带库对应 Mhvtl 暴露的 medium changer 设备。define path 是告诉 TSM 服务端通过哪个设备节点访问库控制器和驱动器。DRIVE01 是驱动器在 TSM 侧的逻辑名可以和 Mhvtl 的驱动器编号不对应但路径必须指对。最后可以用 q path 和 q drive 查看定义是否生效q path q drive运行后如果状态显示 ONLINE说明服务端已经能访问虚拟带库的机械臂和驱动器。这里有个细节TSM 服务端主机名 TSM_SERVER 要和你当前服务器的主机名一致很多人在这里顺手写错结果路径定义总是报错。3.3 定义设备类、存储池与策略域设备类决定备份卷的写入格式存储池是 TSM 管理物理卷的容器策略域决定备份保留多久。三者缺一不可顺序通常是先设备类再存储池最后策略。用下面一组命令完成# 定义设备类指向库并指定格式 define devclass MHVTL_CLS devtypeLTO libraryMHVTL_LIB # 定义存储池绑定设备类 define stgpool VTLPOOL MHVTL_CLS maxscratch50 # 定义策略域与管理类 define domain BACKUP_DOM define mgmtclass BACKUP_DOM STANDARD_MC # 绑定管理类到存储池 define copygroup BACKUP_DOM STANDARD_MC STANDARDdevclass 里的 devtypeLTO 要和 Mhvtl 模拟的 LTO-5 匹配TSM 6.3 支持直接识别 LTO 类型。VTLPOOL 创建时 maxscratch50 意思是允许存储池动态创建最多 50 卷临时磁带这个参数太小时备份会在高峰期因为无可用卷而失败。管理类 BACKUP_DOM 下的 copygroup 里需要定义备份数据的保留策略# 在 copygroup 里定义数据保留版本与时间 update copygroup BACKUP_DOM STANDARD_MC STANDARD verexists7 verdeleted2 retextra1verexists7 表示每个文件保留 7 个版本verdeleted2 表示文件被删除后再保留 2 个版本retextra1 表示归档类数据额外保留 1 份。这个参数组合是我做测试常用的保守值既能让恢复测试有足够版本可选又不会让虚拟磁带库被历史版本塞满。3.4 注册数据库节点并测试一次手工备份TSM 的服务端配置最终要落到“谁来备份”的问题上。Oracle 和 DB2 在 TSM 里都以节点的身份出现节点名需要和数据库客户端配置完全一致。注册两个节点的命令如下register node ORACLE_NODE orapass register node DB2_NODE db2pass密码是客户端连接时用的测试环境可以简单些生产环境必须用加密传输和复杂密码。节点注册后就可以通过 TSM 的命令行发起一次手工备份验证最直观的方式是备份 TSM 自身的数据库backup db q processbackup db 会把 TSM 元数据写入 VTLPOOLq process 可以观察当前有没有活动进程。我建议第一次跑到这里就停下来先确认 TSM 自身能备份成功再继续配置数据库客户端。这样排查问题时就能划定边界TSM 链路有问题还是数据库客户端配置有问题。4. Oracle 与 DB2 备份恢复测试两套通道同一套验证逻辑4.1 Oracle 侧安装 TSM 客户端并配置 tdpo.optOracle 备份走的是 SBT 接口TSM 6.3 时代对应的组件是 TDP for Oracle。安装完成后配置集中在 dsm.sys 和 tdpo.opt 两个文件。dsm.sys 描述服务端连接信息tdpo.opt 描述备份节点的可选参数。下面是一个典型的配置# /opt/tivoli/tsm/client/oracle/bin/tdpo.opt TDPO_NODE ORACLE_NODE TDPO_PSWDPATH /opt/tivoli/tsm/client/oracle/bin TDPO_MGMTCLASS STANDARD_MC TDPO_DATAFORMAT 2TDPO_NODE 必须和 TSM 服务端注册的节点名一致TDPO_PSWDPATH 指定保存密码文件的位置TDPO_MGMTCLASS 指定备份写入哪个管理类。TDPO_DATAFORMAT 2 使用 TSM 的专有格式恢复时只能通过 TSM 读取。设置好之后用 dsmc 命令测试连通性dsmc -seidORACLE_NODE -passwordorapass q nodename能查询到节点信息说明客户端与服务端的握手成功。这一步不通后面 RMAN 里 100% 报 SBT 通道初始化失败。4.2 用 RMAN 发起 Oracle 备份与恢复验证连通性确认后RMAN 侧只需要分配一个 SBT 通道。备份脚本如下rman target / run { allocate channel ch1 type sbt_tape parms ENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/bin/tdpo.opt); backup database plus archivelog; release channel ch1; }allocate channel 里的 sbt_tape 是固定写法关键在于 ENV 参数必须指向 tdpo.opt 的绝对路径。RMAN 启动时会把控制文件里记录的备份信息与 TSM 的卷对应起来。备份完成后用 list backup 查看备份集然后做一次恢复验证rman target / run { allocate channel ch1 type sbt_tape parms ENV(TDPO_OPTFILE/opt/tivoli/tsm/client/oracle/bin/tdpo.opt); restore database; recover database; }restore 是从 TSM 卷上把数据文件读回来recover 是应用归档日志把数据库推进到一致状态。很多团队只做备份不做恢复这是自欺欺人。在测试环境里我强烈建议每次备份后立刻做一次 restore 到不同目录的演练因为“备份成功”和“能恢复”之间隔着一整条链路。4.3 DB2 侧配置 TSM 参数并执行备份DB2 走的是 TSM 的 API 客户端不依赖 RMAN配置直接在 DB2 实例参数里完成。需要设置三个参数TSM_MGMTCLASS、TSM_NODE、TSM_OWNER。下面以 SAMPLE 库为例db2 update db cfg for SAMPLE using TSM_MGMTCLASS STANDARD_MC TSM_NODE DB2_NODE TSM_OWNER db2inst1TSM_OWNER 填写运行 DB2 实例的操作系统用户名TSM 会以这个用户的身份去访问密码文件。配置完成后发起一次备份db2 backup db SAMPLE use TSM db2 list history backup all for SAMPLEbackup 命令会调用 TSM 的 API 把数据库写入虚拟磁带库list history 能看到备份映像的时间戳。DB2 的备份映像在 TSM 里是以“节点时间戳”为标识的后续恢复必须精确指定。4.4 DB2 恢复验证的两种方式DB2 恢复有两种典型场景恢复到一个全新数据库或恢复到原库并前滚到指定时间点。全库恢复的命令如下db2 restore db SAMPLE from TSM taken at 2025-01-10-12.00.00taken at 后面的时间戳来自 list history 的输出写错一个字符就会报映像不存在。如果还有归档日志要前滚追加 rollforward 命令db2 rollforward db SAMPLE to end of logs恢复测试里最常见的失败是时间戳写错、或者原库仍有连接会话导致文件被占用。习惯上我会先把应用连接断开再执行 restore。5. 避坑Mhvtl、TSM 与数据库客户端之间的典型故障5.1 现象TSM 定义路径时提示设备不可用Mhvtl 重启后/dev/sg5、/dev/sg6 这类设备号经常前后对调TSM 里定义好的路径就会指向错误的设备。原因Linux 对 SCSI 设备的命名取决于内核枚举顺序Mhvtl 服务启动时机变化会改变枚举结果。解决不要用固定设备号先执行 lsscsi -g 查看当前实际设备再重新 define path。更彻底的办法是给 Mhvtl 设备写 udev 规则根据序列号生成固定软链接让 TSM 始终引用同一个路径。5.2 现象Oracle 的 RMAN 通道一直处于等待状态分配 SBT 通道后RMAN 长时间停在 Waiting for tape mount没有任何报错。原因TSM 服务端没有可用空卷存储池 maxscratch 设置过小或虚拟带库里没有足够空带。解决用 q stgpool VTLPOOL 查看 available scratch volume 数量如果为 0在 TSM 里执行 checkout 把带库里的空带移入存储池或者直接更新 maxscratch 到更大值。我习惯把 maxscratch 设到 50Mhvtl 里预留 10 卷空带专门给测试用。5.3 现象DB2 备份报 TSM 密码文件认证失败db2 backup 时提示 TSM password file 无法读取。原因TSM_OWNER 指定的用户和实际执行命令的操作系统用户不一致密码文件存在了别的用户目录下。解决先确认执行 db2 backup 的 Linux 用户再在 TSM 客户端执行 dsmc 生成密码文件时用同一用户。常见做法是直接切换到 db2inst1 用户登录再执行 dsmc 初始化密码文件。5.4 现象恢复测试把备份卷删没了restore 时提示备份映像的卷已被回收TDPO 返回卷不可用。原因TSM 存储池启用了自动回收reclamation测试环境的保留期设置太短备份数据还没过期就被回收掉了。解决在测试阶段把 copygroup 的 verexists 调大并把存储池的 reclamation threshold 调高比如设到 90意思是卷使用率达到 90% 才触发回收。生产环境按业务要求设置测试环境以“能反复恢复”为第一目标。5.5 现象Mhvtl 主机重启后 TSM 服务端连不上虚拟带库原因Mhvtl 服务没有设置开机自启或者 TSM 服务端先于 Mhvtl 启动导致驱动器和库路径全部掉线。解决把 mhvtl 加入 systemctl enable在 TSM 服务启动前确认 lsscsi 输出正常。稳妥的做法是加一个监控脚本检测到 Mhvtl 设备不存在时不自启 TSM避免服务端在 10 分钟超时上反复重试带来的日志刷屏。6. 把恢复测试做成日常习惯一个可以反复执行的验证脚本测试环境的价值在于可重复。我把整套验证固化成一个脚本每次改完配置先跑一遍确认链路完好再交给项目方。脚本主要检查四件事Mhvtl 设备是否在线、TSM 存储池状态、Oracle 和 DB2 各自的备份映像时间、以及最近一次的恢复是否成功。骨架如下#!/bin/bash set -e # 1. 检查 Mhvtl 设备 lsscsi -g | grep -E tape|mediumx # 2. 检查 TSM 存储池和驱动器 dsmadmc -seidadmin -passwordadmin q stgpool VTLPOOL | grep AVAILABLE dsmadmc -seidadmin -passwordadmin q drive | grep ONLINE # 3. 检查数据库侧最近的备份映像 rman target / catalog /dev/null EOF list backup of database completed after sysdate-1; EOF # 4. 打印 DB2 历史备份 db2 list history backup all for SAMPLE | grep 2025-脚本里没有实际的恢复动作它只是把“万事俱备”的状态用命令确认一遍。真正恢复验证我要求每周至少手动做一次Oracle 恢复到一个中间目录、DB2 恢复到独立实例而不是在原库上覆盖。这能保证一旦生产环境出问题团队对恢复流程有肌肉记忆。另一个实用技巧是给 TSM 启用心跳监控。在 dsmadmc 里定义 schedule让系统每 30 分钟对 VTLPOOL 做一次一致性检查发现卷损坏立刻告警。虚拟带库的卷本质是文件磁盘损坏比物理磁带更难发现定时检查比事后补救值钱得多。我对这套环境的最终态度是备份测试不是“跑通一次备份”就结束而是让恢复成为习惯。没有恢复验证的备份测试文档充其量是一份记录不是一套可交付的能力。在这套 Mhvtl TSM Oracle DB2 的框架里把恢复演练次数做到和备份次数一样频繁才是真正把环境用到位了。希望这些步骤和教训能帮到你。本文还有配套的精品资源点击获取