简介面向企业备份运维人员与数据库管理员的一份 TSM 6.3 Linux 实验文档聚焦 Mhvtl 虚拟带库、TSM 服务端配置及 Oracle 基于 TSM 的备份恢复测试也可为 DB2 等数据库的类似验证提供流程参照。压缩包仅含 1 个 docx约 1.83MB正文按 Mhvtl 安装配置、TSM 安装配置、Oracle 备份、Oracle 异机恢复四部分组织目录细化到编译安装 Mhvtl、测试带库可用性、基于 tgt 的 iSCSI 映射、配置机械手与驱动器、配置卷和备份策略、安装 NUB 客户端、手工发起备份以及通过 RMAN 与 TSM 命令恢复 spfile、控制文件、数据文件和归档日志并打开数据库。已有 243 人学习适合需要搭建虚拟带库实验环境、梳理 TSM 备份策略或演练异机恢复的中高级读者对照实践与查漏补缺。1. 从一次没有带库的恢复演练说起去年帮某公司做备份演练机房腾退物理带库提前下架只剩三台虚拟机和一份 TSM 6.3.5 的旧配置。演练要求很明确Oracle 11g 全备能落到带库、能在另一台机器上恢复起来DB2 9.7 同样走一遍。没有带库怎么办用 mhvtl 在一台 CentOS 6.6 上仿真出 STK L700 机械手和四台 LTO5 驱动器再用 tgt 把这套设备通过 iSCSI 映射给备份服务器。整套链路跑通之后发现真正的难点不在装软件而在设备名漂移、卷状态不对、异机恢复的节点授权这三处。这份文档记录的就是 mhvtl TSM 6.3 Oracle DB2 这条链路的完整落地步骤适合手里有闲置虚拟机、想验证备份策略但暂时没有物理带库的 DBA 和系统工程师照着复现。2. Mhvtl 虚拟带库落地编译内核模块到 mtx 认带2.1 先想清楚为什么用虚拟带库顶替物理设备mhvtl 是一套跑在 Linux 上的开源虚拟磁带库它向下用内核模块模拟 SCSI 磁带设备向上暴露标准的机械手medium changer和驱动器tape设备节点。它能仿的型号不少LTO1 到 LTO5、AIT4、STK T10000A/B/C、STK L700 和 L80 都在支持列表里默认配置通常落在 L180/L700 这一档四台驱动器、四十多个槽位足够撑起一次中等规模的策略验证。选它的理由有三条。第一条是成本物理带库、磁带、光纤交换机这一套下来不是小数目而验证备份策略、跑通恢复流程根本用不着真实介质。第二条是可重复虚拟磁带就是 /opt/mhvtl 下的普通文件备份跑完想重来停服务、删文件、重启几分钟回到干净状态物理磁带做不到。第三条是可观测磁带里到底写了什么、卷标对不对、机械手抓带有没有失败用 mtx 和 mt 命令直接看比在物理带库面板上按按钮直观得多。边界也要说清楚。这套环境走的是 LAN 路径备份数据从客户端经 TCP 到备份服务器再由服务器写到本地挂载的虚拟带库设备上没有 Fiber Channel也没有 LAN-Free。所以拿它测吞吐量、做容量规划是没有意义的它只能验证功能正确性、流程完整性和策略合理性。我在文档里一般会写一句性能数字看个趋势就行别拿去汇报。2.2 依赖包与目录规划一步都别省mhvtl 的编译依赖几个不太起眼的包缺一个就卡在 make 阶段。lsscsi 用来枚举 SCSI 设备mt-st 提供 mt 命令操作磁带mtx 操作机械手sg3_utils 用来直接发 SCSI 命令排查问题zlib-devel、kernel-devel、kernel-headers、gcc 是编译内核模块的必需品。# 一次性把编译和调试要用的包装齐 yum install -y lsscsi mt-st mtx zlib-devel sg3_utils \ kernel-devel kernel-headers gcc # 专用账户避免用 root 跑带库进程 useradd vtl passwd vtl # 两个目录要分清配置放 /etc/mhvtl虚拟磁带数据放 /opt/mhvtl mkdir -p /opt/mhvtl /etc/mhvtl chown -Rf vtl:vtl /opt/mhvtl chown -Rf vtl:vtl /etc/mhvtl这段的目的不是把包装上就完事而是把权限和路径提前定死。/etc/mhvtl存的是mhvtl.conf、library_contents.10、device.conf这类文本配置/opt/mhvtl存的是每盘磁带对应的二进制数据文件一盘 2GB 的带就是 2GB 的稀疏文件。两个目录都归属 vtl 用户是因为 vtllibrary 和 vtlstor 这两个守护进程以 vtl 身份运行用 root 跑会在后续挂载和权限检查上埋坑。内核版本和 kernel-devel 必须严格一致这是编译环节最常见的翻车点。装包之前先uname -r看一眼再rpm -q kernel-devel对一下版本号差一位make 就会报/lib/modules/xxx/build: No such file or directory。2.3 编译内核模块并拉起服务mhvtl 的安装包分两部分mhvtl-utils提供用户态工具和启动脚本源码包里的kernel目录是 SCSI 调试模块改造出来的内核模块。顺序不能反先装 utils 再编内核模块。# 1. 先装用户态工具包 rpm -ivh mhvtl-utils-1.5-2.x86_64.rpm # 2. 解压源码进入 kernel 子目录编译 unzip mhvtl-1.5-2.zip cd markh794-mhvtl-d9f6115/kernel make make install # 3. 启动服务并设为开机自启 service mhvtl start chkconfig mhvtl on第一次启动时控制台会打出两行提示Could not locate library config file: /etc/mhvtl/library_contents.10和.30紧接着说Creating a default one。这不是错误是服务在发现配置缺失后自动生成了一份默认带库布局。.10对应 L7004 驱动器 / 43 槽位.30对应 L804 驱动器 / 44 槽位两份配置文件里的槽位、卷标、驱动器映射都可以后续手改。启动成功后会看到类似vtllibrary process PID is 3718和3723的输出说明两个带库实例的守护进程都起来了。如果只有一行 PID 或者进程秒退先去/var/log/messages里找 mhvtl 关键字八成是内核模块没加载上用lsmod | grep mhvtl确认一下。2.4 用 lsscsi 和 mtx 确认机械手与驱动器设备到底认没认出来别看服务状态看 SCSI 层。# -g 额外显示 sg 设备节点机械手和驱动器都要能看到 lsscsi -g正常的输出里会出现两类关键行mediumx开头的就是机械手/dev/sch0和/dev/sg10是它的两个入口tape开头的是驱动器/dev/st0到/dev/st7对应八个逻辑驱动器/dev/sg2到/dev/sg9是它们的 SCSI 通用节点。默认配置下会同时出现 L700 和 L80 两套带库槽位和卷标都不一样。确认机械手能不能动用 mtx 查状态# 查 L700 机械手当前状态几个驱动器、几个槽位、每个槽位装了什么带 mtx -f /dev/sg10 status # 把 1 号槽位的磁带装到 0 号驱动器 mtx -f /dev/sg10 load 1 0 # 再看一次状态Data Transfer Element 0 应该显示 Full mtx -f /dev/sg10 statusmtx -f后面跟的是机械手设备节点load的两个参数分别是源槽位和目标驱动器号顺序不能颠倒。装载成功后status输出里对应驱动器那一行会从Empty变成Full (Storage Element 1 Loaded):VolumeTag E01001L4卷标是从library_contents.10里读出来的。最后一步是端到端验证读写绕开所有备份软件直接用 tar 打一盘# 往 0 号驱动器对应的磁带写数据 tar -cvf /dev/st0 /boot # 倒带后读回来确认内容完整 mt -f /dev/st0 rewind tar -tvf /dev/st0tar 能写能读说明内核模块、设备节点、机械手抓带这一整条链路是通的。这一步跳过直接去配 TSM出了问题根本分不清是带库的锅还是备份软件的锅排查成本翻倍。2.5 磁带容量与配置文件的联动关系默认每盘带容量不大做 Oracle 全备几盘就满了。改容量在mhvtl.conf里cat /etc/mhvtl/mhvtl.conf # MHVTL_CONFIG_PATH/etc/mhvtl # CAPACITY2046 # 单位 MB2046 约等于 2GB # VERBOSE1 # VTL_DEBUG0CAPACITY的单位是 MB2046 就是约 2GB。改完之后必须重启 mhvtl 服务才生效而且只对之后新写入的磁带起作用。已经写过的磁带如果中途改容量元数据和实际文件大小会对不上后续 mount 或者 restore 时可能报介质错误。我的习惯是环境搭好、还没开始灌数据之前就把容量定下来之后不再动。library_contents.10里的卷标、槽位、驱动器映射也是同理改配置之前先service mhvtl stop改完再 start热改会读到半截状态。这些细节看着琐碎但虚拟带库这一层如果不稳上面 TSM 的所有报错都会指向错误的方向。3. iSCSI 映射与 TSM 6.3 服务端配置机械手、驱动器、卷三件套3.1 tgt 服务端把机械手和驱动器导出去mhvtl 跑在带库那台机器上TSM 服务端在另一台机器上中间要有一条 SCSI 通路。用 tgt 把本地 SCSI 设备封装成 iSCSI target 是最省事的做法不用配光纤卡和 zoning。# 装 iSCSI target 服务端 yum install -y scsi-target-utils service tgtd start chkconfig tgtd on # 建一个 target名字里的 iqn 自己定格式对就行 tgtadm --lld iscsi --mode target --op new \ --tid 1 --targetname iqn.2015-04.local.mhvtl:l700 # LUN 0 导出机械手注意 --device-type 必须显式写成 changer tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 0 \ --backing-store /dev/sg10 --device-type changer # LUN 1 到 LUN 4 分别导出四台驱动器 tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 \ --backing-store /dev/st0 --device-type tape tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \ --backing-store /dev/st1 --device-type tape # 只允许备份网段访问别开成 any tgtadm --lld iscsi --mode target --op bind --tid 1 \ --initiator-address 192.168.81.0/24 # 确认导出结果 tgtadm --lld iscsi --mode target --op show这段里最容易错的是--device-type。tgt 默认按磁盘处理 backing-store机械手和磁带必须显式声明成changer和tape否则客户端登进来看到的是一块普通磁盘lsscsi 里根本不会出现 mediumx 和 tape 两类设备。另一个坑是--backing-store要写 sg 节点而不是 st 节点机械手只有 sg 节点驱动器虽然两个都有但统一用 sg 更稳。上面这些 tgtadm 命令是运行时生效重启就没了。生产环境要写进/etc/tgt/targets.conf格式和命令行参数一一对应改完service tgtd reload。3.2 客户端登录并固定设备名备份服务器这一侧装 initiator发现并登录 targetyum install -y iscsi-initiator-utils service iscsid start # 发现目标 iscsiadm -m discovery -t sendtargets -p 192.168.81.6 # 登录-T 后面跟完整的 target 名 iscsiadm -m node -T iqn.2015-04.local.mhvtl:l700 -l # 登录后再看一次 SCSI 设备 lsscsi -g登录成功后备份服务器上会多出mediumx和tape两类设备节点名可能是/dev/sg12、/dev/st8之类具体编号看系统已有设备数量。这里有个必须处理的问题iSCSI 设备名不保证每次重启都一样而 TSM 的define path是写死设备路径的设备名一漂备份任务全部报ANR8300E。常见做法是用/dev/disk/by-path/下的持久链接或者写 udev 规则按 target 名和 LUN 号固定成/dev/tsmscsi/mt0这样的名字。TSM 自带的autoconf工具也能扫设备并生成持久名路径在/opt/tivoli/tsm/devices/bin/autoconf跑一遍之后ls /dev/tsmscsi/能看到mt0、lb0这类节点后面配置统一用这套名字。3.3 TSM 服务端定义 library、drive、path进入 TSM 管理命令行dsmadmc按「库 → 驱动器 → 路径 → 设备类」的顺序定义顺序反了会报依赖错误。/* 1. 定义带库libtypescsi 表示机械手由操作系统识别 */ define library l700lib libtypescsi /* 2. 定义驱动器名字自己起和物理槽位对应 */ define drive l700lib drive0 define drive l700lib drive1 /* 3. 定义路径告诉 TSM 这台服务器怎么访问到这台驱动器 */ define path tsm61 drive0 srctypeserver desttypedrive \ libraryl700lib device/dev/tsmscsi/mt0 /* 4. 定义设备类格式要和虚拟带库仿的型号对上 */ define devclass lto5dev devtypelto libraryl700lib formatdrive参数逐个说。libtypescsi是外部机械手模式TSM 通过操作系统提供的 changer 设备去抓带不做自己的机械手控制。device一定要写持久名写/dev/st0这种会在重启后失效。devtypelto对应 LTO 系列如果虚拟带库仿的是 T10000这里要改成devtypeecart或对应类型写错会导致卷挂载后读写异常。formatdrive表示磁带格式化交给驱动器自己做不用 TSM 预处理。定义完用q path和q drive检查状态Online才算通。如果显示Offline先看q actlog最近的报错再回到操作系统层面用mt -f /dev/tsmscsi/mt0 status确认设备本身能打开。3.4 卷检入、存储池与策略域驱动器通了接下来把磁带登记进 TSM 的卷管理。/* 把机械手里所有带卷标的磁带批量检入为 scratch 状态 */ checkin libvol l700lib searchbulk statusscratch checklabelyes /* 定义主存储池maxscratch 控制最多占用多少盘 scratch 带 */ define stgpool tapepool lto5dev maxscratch50 reuseyes collocateno /* 定义策略域和策略集名字按业务命名 */ define domain ORADOM define policyset ORADOM standard define mgmtclass ORADOM standard mc_oracle define copygroup ORADOM standard mc_oracle typebackup \ destinationtapepool verexists30 retextra90 modemodified assign defmgmtclass ORADOM standard mc_oraclecheckin这条是关键。searchbulk表示让 TSM 自己去机械手里扫不用一盘盘报槽位号statusscratch表示检入后作为可覆盖的空带使用如果是要保留数据的带改成private。checklabelyes会先校验卷标防止把别的环境的带误检进来。verexists30和retextra90是版本保留策略前者管「还有数据存在时保留多少个版本」后者管「数据删除后再保留多少天」。这两个值直接决定磁带消耗量和恢复窗口虚拟环境里可以调小一点方便观察 reclaim 行为但别调到 1那样连一次完整恢复都做不了。3.5 先验文件系统备份再碰数据库数据库备份链路比文件系统复杂先用文件系统备份验证整条通路能跑通是省时间的做法。/* 注册一台测试客户端 */ register node fsclient fsclient Pssw0rd domORADOM /* 定义一个每天都跑的备份调度 */ define schedule ORADOM standard daily_fs typeclient \ actionbackup objects/etc /home starttime02:00客户端装好 BA 客户端、配好dsm.opt指向服务端之后用dsmc backup /etc手工触发一次服务端q session能看到会话q actlog能看到备份完成记录q volume能看到带卷状态从Scratch变成Filling。这几步都对上了才说明带库、驱动器、存储池、策略这一整套配置是正确的接下来 Oracle 备份出了问题范围就能缩小到 TDPO 客户端那一层。4. Oracle 与 DB2 的 SBT 通道NUB 客户端配置与备份脚本4.1 TDPO 客户端装什么、配什么Oracle 通过 RMAN 调 TSM中间靠的是 TDPOTivoli Data Protection for Oracle现在官方叫法是 NUB 客户端套件。这个套件里其实有四个包装的时候顺序和用途得分清包名作用是否必需TIVsm-API64提供 DSMI 接口层TDPO 依赖它必需TIVsm-BA备份归档客户端含 dsmc 命令必需TIVsm-TDPOOracle 专用模块提供 libtdpo.so必需TIVsm-APIcit32 位 API只在 32 位 Oracle 场景用视情况# 先装底层 API再装 BA最后装 TDPO rpm -ivh TIVsm-API64.x86_64.rpm rpm -ivh TIVsm-BA.x86_64.rpm tar xf TIVsm-TDPO.tar cd TIVsm-TDPO ./install.sh装完之后配两个文件。dsm.opt管节点身份和服务端地址tdpo.opt管 TDPO 自己的行为/* /usr/tivoli/tsm/client/oracle/bin64/dsm.opt */ SERVERNAME tsm61 NODENAME oracle1 COMMMETHOD TCPIP TCPPORT 1500 TCPSERVERADDRESS 192.168.81.7 PASSWORDACCESS GENERATE/* /usr/tivoli/tsm/client/oracle/bin64/tdpo.opt */ DSMI_ORC_CONFIG /usr/tivoli/tsm/client/oracle/bin64/dsm.opt DSMI_LOG /home/oracle/tdpo TDPO_NODE oracle1 TDPO_OWNER oracle TDPO_FS /adsmorcPASSWORDACCESS GENERATE表示首次用dsmc set password存下密码之后后续自动读取不用在脚本里写明文密码这一点在 Oracle 备份脚本里特别重要。TDPO_FS是 TSM 服务端上的文件空间名恢复的时候要用它定位备份对象随便改会导致找不到备份。4.2 服务端注册节点并授权客户端配好之前服务端先把节点登记上否则第一次连接会被拒绝/* 注册 Oracle 客户端节点密码自己定 */ register node oracle1 Pssw0rd domORADOM /* 授予备份归档权限恢复时还需要 restore 权限 */ grant authority oracle1 classesbackup节点名必须和dsm.opt里的NODENAME完全一致大小写敏感。授权只给backup的话备份能跑恢复会报权限不足这个坑在异机恢复章节还会再遇到。稳妥做法是备份和恢复权限一次性都给classesbackup,restore。4.3 RMAN 走 SBT 通道的完整脚本Oracle 侧的核心是allocate channel ... type sbt_tape这一句让 RMAN 把备份流交给 TDPO再由 TDPO 转给 TSM。run { allocate channel t1 type sbt_tape parms ENV(TDPO_OPTFILE/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt); allocate channel t2 type sbt_tape parms ENV(TDPO_OPTFILE/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt); sql alter system archive log current; backup as compressed backupset incremental level 0 database format ora_%d_%T_%U plus archivelog format arch_%d_%T_%U delete input; release channel t1; release channel t2; }parms里的TDPO_OPTFILE必须写绝对路径RMAN 不会继承 shell 的环境变量。format里的%U是 RMAN 生成的唯一标识TSM 侧看到的对象名会带上这个串恢复时按这个格式去查备份片段比较方便。delete input表示归档日志备份成功后删掉源文件虚拟环境磁盘小不加这一句很快就会满。两个通道对应两台驱动器前面 TSM 里定义了 drive0 和 drive1这里开两个通道能并行写。通道数不要超过驱动器数多开的通道会排队等设备反而拖慢整体速度。4.4 DB2 的 vendor 配置与备份命令DB2 走 TSM 靠的是libdb2tsm.so配置方式和 Oracle 完全不同主要通过数据库参数和VENDOROPT环境变量。# 进实例用户配置 TSM API 的选项文件路径 db2 update db cfg for SAMPLE using VENDOROPT \ DSMI_CONFIG/usr/tivoli/tsm/client/api/bin64/dsm.opt \ DSMI_LOG/home/db2inst1 # 确认参数已生效 db2 get db cfg for SAMPLE | grep -i vendor # 在线全备use tsm 表示走 TSM 通道 db2 backup db SAMPLE online use tsm # 查看备份历史确认 TSM 侧记录 db2 list history backup all for SAMPLEVENDOROPT里的两个参数都指向 API 层的配置不是 TDPO 那套。dsm.opt里同样要有NODENAME和SERVERNAME节点名换成 DB2 客户端自己的。备份完之后去服务端q backup db2inst1能看到对象如果服务端查不到但客户端说成功八成是节点名写错了数据写到别的节点下面去了。5. 异机恢复排查从授权文件到 open resetlogs 的五道坎5.1 异机恢复最容易忽略的授权文件异机恢复不是把备份拷过去那么简单恢复机上的 TDPO 需要重新做一次节点绑定和密码确认。做法是进到恢复机的 TDPO 目录跑tdpoconf# 在恢复机上重新设置节点密码节点名必须是备份时的那个 /usr/tivoli/tsm/client/oracle/bin64/tdpoconf password # 确认配置能连上服务端 /usr/tivoli/tsm/client/oracle/bin64/tdpoconf showenvtdpoconf password会把密码写到TDPO.dir目录下的oracle1.TDPO文件里这个文件默认权限是 600 且属主是 oracle 用户。如果直接用 root 跑了一遍文件属主变成 root之后 oracle 用户跑 RMAN 会读不到报TDPO: Error opening password file。这种权限问题在异机恢复里出现频率很高因为恢复机上什么都是临时搭的。服务端这一侧也要配合恢复机的节点如果换了名字需要用rename node把原节点的备份映射过来或者直接给原节点的restore权限让恢复机用原节点身份登录。两种做法各有利弊前者干净但容易把原节点搞乱后者简单但两台机器共用一个节点名不能同时跑。5.2 RMAN 恢复的顺序与三个必查状态恢复顺序是固定的乱一步就起不来/* 1. 启到 nomount准备恢复参数文件和控文件 */ startup nomount /* 2. 从带库恢复 spfile注意路径和原名要对 */ restore spfile to /u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileorcl.ora from tag ora_orcl_20250418; /* 3. 用恢复出来的 spfile 重启到 nomount */ startup force nomount pfile/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileorcl.ora /* 4. 恢复控文件没有自动备份就指定具体的备份片段 */ restore controlfile from autobackup; /* 5. 挂载后恢复数据文件和归档日志 */ alter database mount; restore database; recover database; alter database open resetlogs;每一步做完都要查状态。第一步查v$instance是不是STARTED第四步之后查v$database的CONTROLFILE_TYPE和OPEN_MODE是不是MOUNTED第五步recover完成之后先别急着open resetlogs用v$recover_file确认没有ONLINE状态的坏文件。open resetlogs是不可逆操作开着库之前多查一次比事后后悔强。5.3 五条踩坑记录每条都带血现象一restore database报ORA-19870: error while restoring backup pieceTDPO 日志里是ANS1329S Server out of data storage space。原因是备份时磁带已经满了TSM 没能从 scratch 池里拿到新带。解决方法是去服务端q stgpool tapepool看Pct Util和Max Scratchscratch 用尽就加带加完q libvol确认状态是Scratch再重跑恢复。这个错误的迷惑性在于客户端日志看起来像介质损坏实际是空间问题。现象二恢复机跑restore spfile时报ORA-27028: skgfqcre: sbtread2 returned errorTDPO 日志里是ANS4005E Error processing file。原因是恢复机和备份机的TDPO_FS配置不一致TSM 按文件空间名找对象名字对不上就找不到。解决办法是比对两台机器的tdpo.optTDPO_FS必须完全一致通常是/adsmorc。现象三recover database卡在media recovery complete不动几十分钟没反应。不是死锁是在从带库拉归档日志虚拟带库的吞吐就那么点几个 GB 的归档拉半小时很正常。判断方法是服务端q session看有没有活跃会话、q actlog看有没有新的 mount 记录。如果确实没动静去恢复机ps -ef | grep tdp看 TDPO 进程还在不在进程没了就是真的断了。现象四open resetlogs之后应用连不上报ORA-01555。这个和 TSM 没关系是 undo 表空间在恢复过程中被覆盖了。异机恢复时如果只恢复了数据文件没恢复 undo或者恢复顺序不对导致 undo 被 reset就会出现。预防办法是restore database之后再单独restore一遍 undo 表空间对应的数据文件确认v$datafile里所有文件状态都是ONLINE。现象五TSM 服务端q path显示Online但备份任务隔三差五失败报ANR8779E Unable to open drive。根因是 iSCSI 设备名漂了重启之后/dev/tsmscsi/mt0指向了别的 LUN。解决办法是把 udev 规则写死按 iSCSI target 名、LUN 号、SCSI ID 三元组固定设备名重启后ls -l /dev/tsmscsi/逐个核对。6. 把「备份成功」变成「能恢复」一份可执行的验证清单备份任务显示Completed不等于这份备份能恢复。这个结论我吃过亏某次演练里 TSM 的备份成功率 100%真到恢复时发现有三盘带在 scratch 池里被回收了对应的正是三个月前那次全备。从那以后我给自己定了一条规矩每个月抽一个备份集做一次小型恢复验证不做验证的备份一律按「不存在」处理。验证不需要每次都做完整恢复按下面这张表分层做成本可控验证层级操作耗时能发现的问题L1 对象可见服务端q backup node -subdiryes1 分钟节点名错、文件空间错、备份没落盘L2 卷可用q volume查带卷状态与Pct Util2 分钟scratch 耗尽、卷被误标 privateL3 单文件恢复dsmc restore或restore spfile10 分钟权限、TDPO 配置、路径映射L4 全库恢复完整 RMAN 恢复 open resetlogs1 到 2 小时归档缺失、恢复顺序、undo 状态L1 到 L3 每周做一次L4 每月一次成本不高但能覆盖绝大多数恢复失败场景。L4 建议固定在一台专用的恢复机上做恢复机的dsm.opt、tdpo.opt、TDPO_FS保持和备份机一致这样每次验证的都是同一条路径出问题容易定位。还有一个小技巧给每个备份集打 tag恢复时用restore ... from tag精确定位不要用most recent。虚拟带库环境里经常会有测试备份混进来most recent拿到的可能不是你要的那份。tag 命名我一般用「库名_日期_类型」的格式比如orcl_20250418_L0看名字就知道是什么。RMAN 里有一个容易被忽略的检查点恢复完recover database之后、open resetlogs之前跑一句report schema和list backup summary确认所有数据文件都出现在报告里且备份片数量与备份时一致。这两个输出我都会存到恢复机的日志目录作为这次验证的凭证。恢复演练的记录不要求多漂亮但要求能拿出东西证明「这一刻库是能起来的」。现在每次碰新的备份环境我都会先跑一遍 L1 到 L3把结果贴进交付文档再谈调度和保留策略。备份这件事能恢复才算数希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/31 16:21:49 · 阅读 1.2k mhvtl+TSM虚拟带库：Oracle/DB2备份与异机恢复实战
简介面向企业备份运维人员与数据库管理员的一份 TSM 6.3 Linux 实验文档聚焦 Mhvtl 虚拟带库、TSM 服务端配置及 Oracle 基于 TSM 的备份恢复测试也可为 DB2 等数据库的类似验证提供流程参照。压缩包仅含 1 个 docx约 1.83MB正文按 Mhvtl 安装配置、TSM 安装配置、Oracle 备份、Oracle 异机恢复四部分组织目录细化到编译安装 Mhvtl、测试带库可用性、基于 tgt 的 iSCSI 映射、配置机械手与驱动器、配置卷和备份策略、安装 NUB 客户端、手工发起备份以及通过 RMAN 与 TSM 命令恢复 spfile、控制文件、数据文件和归档日志并打开数据库。已有 243 人学习适合需要搭建虚拟带库实验环境、梳理 TSM 备份策略或演练异机恢复的中高级读者对照实践与查漏补缺。1. 从一次没有带库的恢复演练说起去年帮某公司做备份演练机房腾退物理带库提前下架只剩三台虚拟机和一份 TSM 6.3.5 的旧配置。演练要求很明确Oracle 11g 全备能落到带库、能在另一台机器上恢复起来DB2 9.7 同样走一遍。没有带库怎么办用 mhvtl 在一台 CentOS 6.6 上仿真出 STK L700 机械手和四台 LTO5 驱动器再用 tgt 把这套设备通过 iSCSI 映射给备份服务器。整套链路跑通之后发现真正的难点不在装软件而在设备名漂移、卷状态不对、异机恢复的节点授权这三处。这份文档记录的就是 mhvtl TSM 6.3 Oracle DB2 这条链路的完整落地步骤适合手里有闲置虚拟机、想验证备份策略但暂时没有物理带库的 DBA 和系统工程师照着复现。2. Mhvtl 虚拟带库落地编译内核模块到 mtx 认带2.1 先想清楚为什么用虚拟带库顶替物理设备mhvtl 是一套跑在 Linux 上的开源虚拟磁带库它向下用内核模块模拟 SCSI 磁带设备向上暴露标准的机械手medium changer和驱动器tape设备节点。它能仿的型号不少LTO1 到 LTO5、AIT4、STK T10000A/B/C、STK L700 和 L80 都在支持列表里默认配置通常落在 L180/L700 这一档四台驱动器、四十多个槽位足够撑起一次中等规模的策略验证。选它的理由有三条。第一条是成本物理带库、磁带、光纤交换机这一套下来不是小数目而验证备份策略、跑通恢复流程根本用不着真实介质。第二条是可重复虚拟磁带就是 /opt/mhvtl 下的普通文件备份跑完想重来停服务、删文件、重启几分钟回到干净状态物理磁带做不到。第三条是可观测磁带里到底写了什么、卷标对不对、机械手抓带有没有失败用 mtx 和 mt 命令直接看比在物理带库面板上按按钮直观得多。边界也要说清楚。这套环境走的是 LAN 路径备份数据从客户端经 TCP 到备份服务器再由服务器写到本地挂载的虚拟带库设备上没有 Fiber Channel也没有 LAN-Free。所以拿它测吞吐量、做容量规划是没有意义的它只能验证功能正确性、流程完整性和策略合理性。我在文档里一般会写一句性能数字看个趋势就行别拿去汇报。2.2 依赖包与目录规划一步都别省mhvtl 的编译依赖几个不太起眼的包缺一个就卡在 make 阶段。lsscsi 用来枚举 SCSI 设备mt-st 提供 mt 命令操作磁带mtx 操作机械手sg3_utils 用来直接发 SCSI 命令排查问题zlib-devel、kernel-devel、kernel-headers、gcc 是编译内核模块的必需品。# 一次性把编译和调试要用的包装齐 yum install -y lsscsi mt-st mtx zlib-devel sg3_utils \ kernel-devel kernel-headers gcc # 专用账户避免用 root 跑带库进程 useradd vtl passwd vtl # 两个目录要分清配置放 /etc/mhvtl虚拟磁带数据放 /opt/mhvtl mkdir -p /opt/mhvtl /etc/mhvtl chown -Rf vtl:vtl /opt/mhvtl chown -Rf vtl:vtl /etc/mhvtl这段的目的不是把包装上就完事而是把权限和路径提前定死。/etc/mhvtl存的是mhvtl.conf、library_contents.10、device.conf这类文本配置/opt/mhvtl存的是每盘磁带对应的二进制数据文件一盘 2GB 的带就是 2GB 的稀疏文件。两个目录都归属 vtl 用户是因为 vtllibrary 和 vtlstor 这两个守护进程以 vtl 身份运行用 root 跑会在后续挂载和权限检查上埋坑。内核版本和 kernel-devel 必须严格一致这是编译环节最常见的翻车点。装包之前先uname -r看一眼再rpm -q kernel-devel对一下版本号差一位make 就会报/lib/modules/xxx/build: No such file or directory。2.3 编译内核模块并拉起服务mhvtl 的安装包分两部分mhvtl-utils提供用户态工具和启动脚本源码包里的kernel目录是 SCSI 调试模块改造出来的内核模块。顺序不能反先装 utils 再编内核模块。# 1. 先装用户态工具包 rpm -ivh mhvtl-utils-1.5-2.x86_64.rpm # 2. 解压源码进入 kernel 子目录编译 unzip mhvtl-1.5-2.zip cd markh794-mhvtl-d9f6115/kernel make make install # 3. 启动服务并设为开机自启 service mhvtl start chkconfig mhvtl on第一次启动时控制台会打出两行提示Could not locate library config file: /etc/mhvtl/library_contents.10和.30紧接着说Creating a default one。这不是错误是服务在发现配置缺失后自动生成了一份默认带库布局。.10对应 L7004 驱动器 / 43 槽位.30对应 L804 驱动器 / 44 槽位两份配置文件里的槽位、卷标、驱动器映射都可以后续手改。启动成功后会看到类似vtllibrary process PID is 3718和3723的输出说明两个带库实例的守护进程都起来了。如果只有一行 PID 或者进程秒退先去/var/log/messages里找 mhvtl 关键字八成是内核模块没加载上用lsmod | grep mhvtl确认一下。2.4 用 lsscsi 和 mtx 确认机械手与驱动器设备到底认没认出来别看服务状态看 SCSI 层。# -g 额外显示 sg 设备节点机械手和驱动器都要能看到 lsscsi -g正常的输出里会出现两类关键行mediumx开头的就是机械手/dev/sch0和/dev/sg10是它的两个入口tape开头的是驱动器/dev/st0到/dev/st7对应八个逻辑驱动器/dev/sg2到/dev/sg9是它们的 SCSI 通用节点。默认配置下会同时出现 L700 和 L80 两套带库槽位和卷标都不一样。确认机械手能不能动用 mtx 查状态# 查 L700 机械手当前状态几个驱动器、几个槽位、每个槽位装了什么带 mtx -f /dev/sg10 status # 把 1 号槽位的磁带装到 0 号驱动器 mtx -f /dev/sg10 load 1 0 # 再看一次状态Data Transfer Element 0 应该显示 Full mtx -f /dev/sg10 statusmtx -f后面跟的是机械手设备节点load的两个参数分别是源槽位和目标驱动器号顺序不能颠倒。装载成功后status输出里对应驱动器那一行会从Empty变成Full (Storage Element 1 Loaded):VolumeTag E01001L4卷标是从library_contents.10里读出来的。最后一步是端到端验证读写绕开所有备份软件直接用 tar 打一盘# 往 0 号驱动器对应的磁带写数据 tar -cvf /dev/st0 /boot # 倒带后读回来确认内容完整 mt -f /dev/st0 rewind tar -tvf /dev/st0tar 能写能读说明内核模块、设备节点、机械手抓带这一整条链路是通的。这一步跳过直接去配 TSM出了问题根本分不清是带库的锅还是备份软件的锅排查成本翻倍。2.5 磁带容量与配置文件的联动关系默认每盘带容量不大做 Oracle 全备几盘就满了。改容量在mhvtl.conf里cat /etc/mhvtl/mhvtl.conf # MHVTL_CONFIG_PATH/etc/mhvtl # CAPACITY2046 # 单位 MB2046 约等于 2GB # VERBOSE1 # VTL_DEBUG0CAPACITY的单位是 MB2046 就是约 2GB。改完之后必须重启 mhvtl 服务才生效而且只对之后新写入的磁带起作用。已经写过的磁带如果中途改容量元数据和实际文件大小会对不上后续 mount 或者 restore 时可能报介质错误。我的习惯是环境搭好、还没开始灌数据之前就把容量定下来之后不再动。library_contents.10里的卷标、槽位、驱动器映射也是同理改配置之前先service mhvtl stop改完再 start热改会读到半截状态。这些细节看着琐碎但虚拟带库这一层如果不稳上面 TSM 的所有报错都会指向错误的方向。3. iSCSI 映射与 TSM 6.3 服务端配置机械手、驱动器、卷三件套3.1 tgt 服务端把机械手和驱动器导出去mhvtl 跑在带库那台机器上TSM 服务端在另一台机器上中间要有一条 SCSI 通路。用 tgt 把本地 SCSI 设备封装成 iSCSI target 是最省事的做法不用配光纤卡和 zoning。# 装 iSCSI target 服务端 yum install -y scsi-target-utils service tgtd start chkconfig tgtd on # 建一个 target名字里的 iqn 自己定格式对就行 tgtadm --lld iscsi --mode target --op new \ --tid 1 --targetname iqn.2015-04.local.mhvtl:l700 # LUN 0 导出机械手注意 --device-type 必须显式写成 changer tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 0 \ --backing-store /dev/sg10 --device-type changer # LUN 1 到 LUN 4 分别导出四台驱动器 tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 \ --backing-store /dev/st0 --device-type tape tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \ --backing-store /dev/st1 --device-type tape # 只允许备份网段访问别开成 any tgtadm --lld iscsi --mode target --op bind --tid 1 \ --initiator-address 192.168.81.0/24 # 确认导出结果 tgtadm --lld iscsi --mode target --op show这段里最容易错的是--device-type。tgt 默认按磁盘处理 backing-store机械手和磁带必须显式声明成changer和tape否则客户端登进来看到的是一块普通磁盘lsscsi 里根本不会出现 mediumx 和 tape 两类设备。另一个坑是--backing-store要写 sg 节点而不是 st 节点机械手只有 sg 节点驱动器虽然两个都有但统一用 sg 更稳。上面这些 tgtadm 命令是运行时生效重启就没了。生产环境要写进/etc/tgt/targets.conf格式和命令行参数一一对应改完service tgtd reload。3.2 客户端登录并固定设备名备份服务器这一侧装 initiator发现并登录 targetyum install -y iscsi-initiator-utils service iscsid start # 发现目标 iscsiadm -m discovery -t sendtargets -p 192.168.81.6 # 登录-T 后面跟完整的 target 名 iscsiadm -m node -T iqn.2015-04.local.mhvtl:l700 -l # 登录后再看一次 SCSI 设备 lsscsi -g登录成功后备份服务器上会多出mediumx和tape两类设备节点名可能是/dev/sg12、/dev/st8之类具体编号看系统已有设备数量。这里有个必须处理的问题iSCSI 设备名不保证每次重启都一样而 TSM 的define path是写死设备路径的设备名一漂备份任务全部报ANR8300E。常见做法是用/dev/disk/by-path/下的持久链接或者写 udev 规则按 target 名和 LUN 号固定成/dev/tsmscsi/mt0这样的名字。TSM 自带的autoconf工具也能扫设备并生成持久名路径在/opt/tivoli/tsm/devices/bin/autoconf跑一遍之后ls /dev/tsmscsi/能看到mt0、lb0这类节点后面配置统一用这套名字。3.3 TSM 服务端定义 library、drive、path进入 TSM 管理命令行dsmadmc按「库 → 驱动器 → 路径 → 设备类」的顺序定义顺序反了会报依赖错误。/* 1. 定义带库libtypescsi 表示机械手由操作系统识别 */ define library l700lib libtypescsi /* 2. 定义驱动器名字自己起和物理槽位对应 */ define drive l700lib drive0 define drive l700lib drive1 /* 3. 定义路径告诉 TSM 这台服务器怎么访问到这台驱动器 */ define path tsm61 drive0 srctypeserver desttypedrive \ libraryl700lib device/dev/tsmscsi/mt0 /* 4. 定义设备类格式要和虚拟带库仿的型号对上 */ define devclass lto5dev devtypelto libraryl700lib formatdrive参数逐个说。libtypescsi是外部机械手模式TSM 通过操作系统提供的 changer 设备去抓带不做自己的机械手控制。device一定要写持久名写/dev/st0这种会在重启后失效。devtypelto对应 LTO 系列如果虚拟带库仿的是 T10000这里要改成devtypeecart或对应类型写错会导致卷挂载后读写异常。formatdrive表示磁带格式化交给驱动器自己做不用 TSM 预处理。定义完用q path和q drive检查状态Online才算通。如果显示Offline先看q actlog最近的报错再回到操作系统层面用mt -f /dev/tsmscsi/mt0 status确认设备本身能打开。3.4 卷检入、存储池与策略域驱动器通了接下来把磁带登记进 TSM 的卷管理。/* 把机械手里所有带卷标的磁带批量检入为 scratch 状态 */ checkin libvol l700lib searchbulk statusscratch checklabelyes /* 定义主存储池maxscratch 控制最多占用多少盘 scratch 带 */ define stgpool tapepool lto5dev maxscratch50 reuseyes collocateno /* 定义策略域和策略集名字按业务命名 */ define domain ORADOM define policyset ORADOM standard define mgmtclass ORADOM standard mc_oracle define copygroup ORADOM standard mc_oracle typebackup \ destinationtapepool verexists30 retextra90 modemodified assign defmgmtclass ORADOM standard mc_oraclecheckin这条是关键。searchbulk表示让 TSM 自己去机械手里扫不用一盘盘报槽位号statusscratch表示检入后作为可覆盖的空带使用如果是要保留数据的带改成private。checklabelyes会先校验卷标防止把别的环境的带误检进来。verexists30和retextra90是版本保留策略前者管「还有数据存在时保留多少个版本」后者管「数据删除后再保留多少天」。这两个值直接决定磁带消耗量和恢复窗口虚拟环境里可以调小一点方便观察 reclaim 行为但别调到 1那样连一次完整恢复都做不了。3.5 先验文件系统备份再碰数据库数据库备份链路比文件系统复杂先用文件系统备份验证整条通路能跑通是省时间的做法。/* 注册一台测试客户端 */ register node fsclient fsclient Pssw0rd domORADOM /* 定义一个每天都跑的备份调度 */ define schedule ORADOM standard daily_fs typeclient \ actionbackup objects/etc /home starttime02:00客户端装好 BA 客户端、配好dsm.opt指向服务端之后用dsmc backup /etc手工触发一次服务端q session能看到会话q actlog能看到备份完成记录q volume能看到带卷状态从Scratch变成Filling。这几步都对上了才说明带库、驱动器、存储池、策略这一整套配置是正确的接下来 Oracle 备份出了问题范围就能缩小到 TDPO 客户端那一层。4. Oracle 与 DB2 的 SBT 通道NUB 客户端配置与备份脚本4.1 TDPO 客户端装什么、配什么Oracle 通过 RMAN 调 TSM中间靠的是 TDPOTivoli Data Protection for Oracle现在官方叫法是 NUB 客户端套件。这个套件里其实有四个包装的时候顺序和用途得分清包名作用是否必需TIVsm-API64提供 DSMI 接口层TDPO 依赖它必需TIVsm-BA备份归档客户端含 dsmc 命令必需TIVsm-TDPOOracle 专用模块提供 libtdpo.so必需TIVsm-APIcit32 位 API只在 32 位 Oracle 场景用视情况# 先装底层 API再装 BA最后装 TDPO rpm -ivh TIVsm-API64.x86_64.rpm rpm -ivh TIVsm-BA.x86_64.rpm tar xf TIVsm-TDPO.tar cd TIVsm-TDPO ./install.sh装完之后配两个文件。dsm.opt管节点身份和服务端地址tdpo.opt管 TDPO 自己的行为/* /usr/tivoli/tsm/client/oracle/bin64/dsm.opt */ SERVERNAME tsm61 NODENAME oracle1 COMMMETHOD TCPIP TCPPORT 1500 TCPSERVERADDRESS 192.168.81.7 PASSWORDACCESS GENERATE/* /usr/tivoli/tsm/client/oracle/bin64/tdpo.opt */ DSMI_ORC_CONFIG /usr/tivoli/tsm/client/oracle/bin64/dsm.opt DSMI_LOG /home/oracle/tdpo TDPO_NODE oracle1 TDPO_OWNER oracle TDPO_FS /adsmorcPASSWORDACCESS GENERATE表示首次用dsmc set password存下密码之后后续自动读取不用在脚本里写明文密码这一点在 Oracle 备份脚本里特别重要。TDPO_FS是 TSM 服务端上的文件空间名恢复的时候要用它定位备份对象随便改会导致找不到备份。4.2 服务端注册节点并授权客户端配好之前服务端先把节点登记上否则第一次连接会被拒绝/* 注册 Oracle 客户端节点密码自己定 */ register node oracle1 Pssw0rd domORADOM /* 授予备份归档权限恢复时还需要 restore 权限 */ grant authority oracle1 classesbackup节点名必须和dsm.opt里的NODENAME完全一致大小写敏感。授权只给backup的话备份能跑恢复会报权限不足这个坑在异机恢复章节还会再遇到。稳妥做法是备份和恢复权限一次性都给classesbackup,restore。4.3 RMAN 走 SBT 通道的完整脚本Oracle 侧的核心是allocate channel ... type sbt_tape这一句让 RMAN 把备份流交给 TDPO再由 TDPO 转给 TSM。run { allocate channel t1 type sbt_tape parms ENV(TDPO_OPTFILE/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt); allocate channel t2 type sbt_tape parms ENV(TDPO_OPTFILE/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt); sql alter system archive log current; backup as compressed backupset incremental level 0 database format ora_%d_%T_%U plus archivelog format arch_%d_%T_%U delete input; release channel t1; release channel t2; }parms里的TDPO_OPTFILE必须写绝对路径RMAN 不会继承 shell 的环境变量。format里的%U是 RMAN 生成的唯一标识TSM 侧看到的对象名会带上这个串恢复时按这个格式去查备份片段比较方便。delete input表示归档日志备份成功后删掉源文件虚拟环境磁盘小不加这一句很快就会满。两个通道对应两台驱动器前面 TSM 里定义了 drive0 和 drive1这里开两个通道能并行写。通道数不要超过驱动器数多开的通道会排队等设备反而拖慢整体速度。4.4 DB2 的 vendor 配置与备份命令DB2 走 TSM 靠的是libdb2tsm.so配置方式和 Oracle 完全不同主要通过数据库参数和VENDOROPT环境变量。# 进实例用户配置 TSM API 的选项文件路径 db2 update db cfg for SAMPLE using VENDOROPT \ DSMI_CONFIG/usr/tivoli/tsm/client/api/bin64/dsm.opt \ DSMI_LOG/home/db2inst1 # 确认参数已生效 db2 get db cfg for SAMPLE | grep -i vendor # 在线全备use tsm 表示走 TSM 通道 db2 backup db SAMPLE online use tsm # 查看备份历史确认 TSM 侧记录 db2 list history backup all for SAMPLEVENDOROPT里的两个参数都指向 API 层的配置不是 TDPO 那套。dsm.opt里同样要有NODENAME和SERVERNAME节点名换成 DB2 客户端自己的。备份完之后去服务端q backup db2inst1能看到对象如果服务端查不到但客户端说成功八成是节点名写错了数据写到别的节点下面去了。5. 异机恢复排查从授权文件到 open resetlogs 的五道坎5.1 异机恢复最容易忽略的授权文件异机恢复不是把备份拷过去那么简单恢复机上的 TDPO 需要重新做一次节点绑定和密码确认。做法是进到恢复机的 TDPO 目录跑tdpoconf# 在恢复机上重新设置节点密码节点名必须是备份时的那个 /usr/tivoli/tsm/client/oracle/bin64/tdpoconf password # 确认配置能连上服务端 /usr/tivoli/tsm/client/oracle/bin64/tdpoconf showenvtdpoconf password会把密码写到TDPO.dir目录下的oracle1.TDPO文件里这个文件默认权限是 600 且属主是 oracle 用户。如果直接用 root 跑了一遍文件属主变成 root之后 oracle 用户跑 RMAN 会读不到报TDPO: Error opening password file。这种权限问题在异机恢复里出现频率很高因为恢复机上什么都是临时搭的。服务端这一侧也要配合恢复机的节点如果换了名字需要用rename node把原节点的备份映射过来或者直接给原节点的restore权限让恢复机用原节点身份登录。两种做法各有利弊前者干净但容易把原节点搞乱后者简单但两台机器共用一个节点名不能同时跑。5.2 RMAN 恢复的顺序与三个必查状态恢复顺序是固定的乱一步就起不来/* 1. 启到 nomount准备恢复参数文件和控文件 */ startup nomount /* 2. 从带库恢复 spfile注意路径和原名要对 */ restore spfile to /u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileorcl.ora from tag ora_orcl_20250418; /* 3. 用恢复出来的 spfile 重启到 nomount */ startup force nomount pfile/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfileorcl.ora /* 4. 恢复控文件没有自动备份就指定具体的备份片段 */ restore controlfile from autobackup; /* 5. 挂载后恢复数据文件和归档日志 */ alter database mount; restore database; recover database; alter database open resetlogs;每一步做完都要查状态。第一步查v$instance是不是STARTED第四步之后查v$database的CONTROLFILE_TYPE和OPEN_MODE是不是MOUNTED第五步recover完成之后先别急着open resetlogs用v$recover_file确认没有ONLINE状态的坏文件。open resetlogs是不可逆操作开着库之前多查一次比事后后悔强。5.3 五条踩坑记录每条都带血现象一restore database报ORA-19870: error while restoring backup pieceTDPO 日志里是ANS1329S Server out of data storage space。原因是备份时磁带已经满了TSM 没能从 scratch 池里拿到新带。解决方法是去服务端q stgpool tapepool看Pct Util和Max Scratchscratch 用尽就加带加完q libvol确认状态是Scratch再重跑恢复。这个错误的迷惑性在于客户端日志看起来像介质损坏实际是空间问题。现象二恢复机跑restore spfile时报ORA-27028: skgfqcre: sbtread2 returned errorTDPO 日志里是ANS4005E Error processing file。原因是恢复机和备份机的TDPO_FS配置不一致TSM 按文件空间名找对象名字对不上就找不到。解决办法是比对两台机器的tdpo.optTDPO_FS必须完全一致通常是/adsmorc。现象三recover database卡在media recovery complete不动几十分钟没反应。不是死锁是在从带库拉归档日志虚拟带库的吞吐就那么点几个 GB 的归档拉半小时很正常。判断方法是服务端q session看有没有活跃会话、q actlog看有没有新的 mount 记录。如果确实没动静去恢复机ps -ef | grep tdp看 TDPO 进程还在不在进程没了就是真的断了。现象四open resetlogs之后应用连不上报ORA-01555。这个和 TSM 没关系是 undo 表空间在恢复过程中被覆盖了。异机恢复时如果只恢复了数据文件没恢复 undo或者恢复顺序不对导致 undo 被 reset就会出现。预防办法是restore database之后再单独restore一遍 undo 表空间对应的数据文件确认v$datafile里所有文件状态都是ONLINE。现象五TSM 服务端q path显示Online但备份任务隔三差五失败报ANR8779E Unable to open drive。根因是 iSCSI 设备名漂了重启之后/dev/tsmscsi/mt0指向了别的 LUN。解决办法是把 udev 规则写死按 iSCSI target 名、LUN 号、SCSI ID 三元组固定设备名重启后ls -l /dev/tsmscsi/逐个核对。6. 把「备份成功」变成「能恢复」一份可执行的验证清单备份任务显示Completed不等于这份备份能恢复。这个结论我吃过亏某次演练里 TSM 的备份成功率 100%真到恢复时发现有三盘带在 scratch 池里被回收了对应的正是三个月前那次全备。从那以后我给自己定了一条规矩每个月抽一个备份集做一次小型恢复验证不做验证的备份一律按「不存在」处理。验证不需要每次都做完整恢复按下面这张表分层做成本可控验证层级操作耗时能发现的问题L1 对象可见服务端q backup node -subdiryes1 分钟节点名错、文件空间错、备份没落盘L2 卷可用q volume查带卷状态与Pct Util2 分钟scratch 耗尽、卷被误标 privateL3 单文件恢复dsmc restore或restore spfile10 分钟权限、TDPO 配置、路径映射L4 全库恢复完整 RMAN 恢复 open resetlogs1 到 2 小时归档缺失、恢复顺序、undo 状态L1 到 L3 每周做一次L4 每月一次成本不高但能覆盖绝大多数恢复失败场景。L4 建议固定在一台专用的恢复机上做恢复机的dsm.opt、tdpo.opt、TDPO_FS保持和备份机一致这样每次验证的都是同一条路径出问题容易定位。还有一个小技巧给每个备份集打 tag恢复时用restore ... from tag精确定位不要用most recent。虚拟带库环境里经常会有测试备份混进来most recent拿到的可能不是你要的那份。tag 命名我一般用「库名_日期_类型」的格式比如orcl_20250418_L0看名字就知道是什么。RMAN 里有一个容易被忽略的检查点恢复完recover database之后、open resetlogs之前跑一句report schema和list backup summary确认所有数据文件都出现在报告里且备份片数量与备份时一致。这两个输出我都会存到恢复机的日志目录作为这次验证的凭证。恢复演练的记录不要求多漂亮但要求能拿出东西证明「这一刻库是能起来的」。现在每次碰新的备份环境我都会先跑一遍 L1 到 L3把结果贴进交付文档再谈调度和保留策略。备份这件事能恢复才算数希望帮到你。本文还有配套的精品资源点击获取