高手梳理：TSM系统知识、日常应用及常见故障处理

社区最近举办了“企业备份之TSM备份和归档专题讨论会”，多位社区会员针对TSM在日常工作中的各种场景和常用故障进行了探讨，分享了很多知识、使用心得、故障处理经验。特邀请活动嘉宾王巧雷梳理成文，方便大家参考。

王巧雷，目前在北京华胜天成科技股份有限公司，担任IT服务交付中心/专家支持部高级技术支持工程师一职。主要负责IBM Power小型机、存储产品、TSM备份软件及DB2数据库的高级技术支持及公司内部培训工作。精通TSM备份软件，拥有IBM Certified Administrator-TSM6.3与IBM Certified Deployment Professional-TSM6.3认证。

• 什么是TSM，能做什么

• TSM架构和概念

• TSM常见问题

• TSM心得及案例分享

什么是TSM，TSM能做什么？

Tivoli Storage Manager(简称TSM)是IBM推出的一款备份软件，能够为大型的企事业单位提供可靠的集中数据备份管理，是业界最主要的备份软件之一。TSM支持以下类型的数据备份：

1. 基本文件的备份归档：基于普通文件类型的备份

2. 操作系统基本的裸机备份：支持aix、linux、windows、solaris等主流操作系统

3. 数据库的备份保护：支持oracle、sql server、db2、informix等主流数据库备份

4. SAN 备份模块：支持lanfree的传输模式备份，提升备份效率

5. NAS设备支持：支持NDMP协议备份，对netapp和emc的nas设备提供原生支持

6. ERP备份：支持SAP备份，包括最新的基于hana的sap

7. 邮件系统备份支持：支持基于MS exchange和lotus nodes的备份

一般来讲，我们需要如果需要对某款应用进行保护，安装对应的模块即可。比如，需要对oracle数据进行保护。需要安装如下模块：

1. tsm server：服务端

2. tsmba client：基本客户端模块

3. tdp for oracle：tsm备份oracle的模块

4. tsm for san：可选，lanfree模块

典型问题：

问题1. 针对各种操作系统有没有什么好备份方案，比较常用的操作系统备份方式是什么？

以TSM为例，TSM支持各种主流操作系统的备份，实现方式分别如下：

windows、linux、aix：cristie公司的cbmr或tbmr，支持操作系统的备份。和ibm有合作关系，好像可以买tsm的时候一起下单。可独立使用，可集成到tsm里，受tsm统一调度管理。同时支持win linuxaix。恢复的时候需要使用cbmr的引导光盘。独立收费，需要激活码。首推的，非常好用。除了这些，cbmr还支持hp-ux和solaris的系统备份。

aix：sysback，ibm自己的aix系统备份工具，优势是免费，集成度高。劣势是必须搭配nim使用。也就是说你环境里至少2台小机。配置复杂。

windows、linux：早期还有fastback，ibm自己的快速备份软件。支持win和lin操作系统的备份，属于独立的产品线。现在产品线已经停了。

问题2. TSM 7 能否备份VMware ESX下的虚机？

首先，从VMware的备份来讲，VMware有两种备份实现方式

1. VCB: 需要额外的proxy服务器和空间，如1T的虚机空间，还需要额外的1t空间来存放备份数据

2. Vstorage API(也叫VADP，vStorage API for Data Protection)：2009年推出，可以直接从vm存储上传到备份服务器空间，VADP服务器可以是虚拟机。tsm支持通过vadp执行文件级别的备份

TSM的ba client直接支持vmwarevm的备份，但是安装tsm for ve后可以支持高级特性。Tsm for ve基于VADP技术实现，支持esx下虚拟机的备份。更新到TSM V7以后，tsm for ve也有了较大更新，具体可参考官方的技术更新：

http://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.ve.doc/r_techchg_ve.html

问题3. TSM对数据库的保护如何实现？

目前，TDP for Database支持MS sql server、db2、oracle等主流数据库。对于sql server和oracle来说，需要购买TSM FOR DATABASE模块，然后安装对应的模块来实现；对于DB2来说，安装TSM的ba client即可直接支持，不需要额外购买相应的模块。

对应各数据库来说，TSM的备份模块仅提供了备份通道，实际上还是通过数据库自身的备份工具来实现。以oracle为例，在安装配置好tdp for oracle后，备份还是使用rman，仅通过tdp的通道将数据备份到tsm所管理的磁带库中。

TSM的架构和概念

TSM作为一款功能强大的备份软件，底层有着自己清晰的逻辑架构。要想学好并灵活的应用tsm软件，需要对TSM底层的架构及相关概念有一个清晰的掌握。在TSM的架构中，主要分两大块：

1.策略层：含以下概念

- 策略域：相同或相似节点数据保留需求的一个集合体，其下包含策略集。

- 策略集：策略域的子集，每个策略域中可以有多个策略集，但只有1个是激活的。

- 管理类：策略集的子类，一个策略集中可有多个管理类，但只有1个是默认的。

- 副本组：管理类的子类，每个管理类中最多只有2个副本组，按功能分备份副本组和归档副本组。副本组中指定数据存放的策略，并执行存放的位置-存储池

2.存储层

- 库：磁带库，实际上指的是机械手

- 驱动器：磁带库中的磁带机

- 设备类：区分不同类型存储的逻辑概念。

- 存储池：根据设备类的不同，使用不同的存储介质组成的逻辑存储集合

- 卷：根据不同情况，可能是磁带。也可能是文件或设备。

物理存储设备和逻辑存储概念通过设备类关联起来，存储层和策略层通过副本组关联起来，下图：

典型问题：

问题1:tsm保本版本参数详解?

回答：verexists：指定当前在客户机文件系统中的文件所保留的最大备份版本数，如果某个备份操作超过了限制，则服务器使磁带库中最旧的备份版本到期。（即代表文件系统中有的文件在磁带库中保留的版本数）

版本数既文件的个数，比如verexists=2 ,则有文件/backup/file1，第一次备份保留一个版本，第二次备份，又会重新备份一次，同一个文件总共2个版本，但可能文件内容不一样了(因为文件被修改了)。

如果verexists=1，则第二次备份时，就会将第一次备份的文件删除掉，保留第二次最新的版本。

最新的版本叫ACTIVE的版本，其他的版本都叫INACTIVE的版本。INACTIVE的版本可以通过 QUERY -INACTIVE参数查询出来。但一旦版本保留时间超过了retextra规定的保留天数，则TSM将把版本变为过期的(expire)，用-inactive参数无法查看到。只能释放掉文件(expire inventory)。

verdeleted:指定要保留的文件备份版本的最大数目，该文件经TSM备份后，已从客户机文件系统中删除。

如果用户从客户机文件系统删除文件，则下一次备份导致服务器让超过此数值的文件的最旧的版本到期。保留版本的失效日期由RETEXTRA和RETONLY参数指定的保留时间决定。

此参数就是说如果主机上删除了这个文件，那么TSM中继续保留多少个版本数。如果verdeleted=0,则主机上删除了文件，则TSM也将文件删除掉。没有起到备份的意义。verdeleted=1代表如果主机上删除了文件，则TSM中仍然保留最后1个版本，但是是INACTIVE的了。verdeleted=2,是说如果主机删除了文件，则TSM中保留2个inactive的版本

retextra:当版本成为非活动版本以后，指定保留此备份版本的天数。当客户机存储更新的备份版本，或客户机删除工作站中的文件，然后运行完全增量备份时，文件的备份版本变为非活动。服务器根据保留时间删除非活动版本，即使非活动版本数超过VEREXISTS或VERDELETED参数容许的数目。缺省值是30天。

此参数就是说当主机上的文件被删除后，TSM中如果定义了还保留有版本，则此参数指定改版本保留的天数。

retonly:指定已从客户机文件系统中删除的文件的上一个备份版本要保留的天数，缺省是60天。

此参数就是说主机上文件被删除后，TSM中保留的最后一个版本的天数。

以上四个参数一定要记住。否则将酿成大错。

客户一般是把文件备份到TSM里面以后，就把文件从主机上删除掉了。看LOG什么的都正常备份了。

每天对同一个目录做备份，每天做删除，年复一年。

然后直到有一天，要恢复数据了，发现以前备份的数据都不在了，为什么？为什么？

因为：verexists=1 verdeleted=0

问题2：TSM备份调度策略如何规划？

回答：通过上面的介绍，我们对TSM的策略层面和存储层面有了一个简单的理解。基于这个理解，在设计调度的时候可采取正反向两个方向去推论。

1. 正向：基于业务需求，备份窗口等去设计。比如，考虑到白天业务繁忙，为了减少影响需要将备份放到晚上。备份最少需要3个小时，那就要计算好备份的时间段，避免影响业务。

2. 反向：基于存储的实际情况。比如备份环境使用了物理磁带库，驱动器的个数、是否使用lanfree等因素就要考虑进来，避免备份作业设置不当发生驱动器的争用。

问题3：同一节点数据保留不同时间，TSM能否通过指定不同的保留策略来完成？

对于同一节点的数据保留数据的期限不同比如每天备份保留一个月每月备份保留1年每年备份保留10年这样的保留策略。TSM 要设置并指定不同的管理类不同的节点或者添加排除等而目前很多其他的备份软件只需要指定不同的保留策略就可以了。 TSM有没有这种简单的做法？

回答：TSM使用两种方法来解决：

1. 设置不同的节点，节点分属不同的策略域

2. 只用1个节点，使用多个管理类，再通过dsm.sys文件中的选项来实现

实际上从原理来讲，和其他备份软件的实现方式应该大致相同。

问题4：TSM存储介质中存储池和库有什么区别呢？

回答：库在TSM里的物理对应就是机械手

池是个逻辑概念，可以由不同的介质类型构成，比如文件、lto等等。可以通过设备类指定。

存储池再和副本组中的dest参数关联。对应到不同的策略域

这样就形成闭环了

TSM常见问题

问题1：从A地将数据备份到B地，走TCPIP，每周的全备数据量比较大，一周内无法完成，带宽无法提升，有别的方式吗？

从A地将数据备份到B地，走TCPIP，每周的全备数据量比较大，一周时间内无法完成，带宽无法提升，还有别的什么方式吗？

回答：实现方式有两种：

1.基于TSM实现：比如直接使用客户端备份或使用node replication。那么需要在传输上下功夫。利用源端消重技术可以有效减少备份传输过程中的数据量。

2.基于设备实现：比如两端的存储设备本身具备远程复制属性，比如datadomain的虚拟带库。这样就完全靠硬件来实现了。

问题2：使用TSM备份oracle，怎么设置通道会比较好？

回答：不管是哪一款备份软件，对备份数据备份流程的控制尤其重要，特别是采用消重技术的备份，对备份数据的控制效用将直接影响消重性能。

消重技术以变长、定长两种为例，顾名思义变长是可以根据数据长度动态调整切片长度（如EMC DataDomain）,定长仅仅是以固定长度对数据进行切片。

切片完成后，片（piece）的命中率直接决定消重性能。piece的命中率越高，消重越明显。因此如何控制备份片（backup piece）单一度且相似度成为重点。

我们知道Oracle的Rman脚本里，有一个fileperset参数来控制每一个backup piece里会包含多少个data file。设想一下，如果fileperset越高，那每个backup piece就会包含更多的data file，backup piece的杂糅度就会越高（data file会被混乱随机的组成一个backup piece，并不是每次都按照同一个顺序拟成），那么消重切片后piece的重复率必然低。

综合分析，一个合理的fileperset值将有效提升消重效率，fileperset越小越好，理论为1最好（如果没有多路复用的情况，一个流会话会占用一个备份设备）。

接下来关注备份通道数，Oracle的备份效率与数据结构类型、数据大小以及备份配置等息息相关。

如何合理规划备份通道数？关于此问题，我们需要了解一个概念——多路复用（multiplexing）。这个功能能够让多个oracle channel的备份流写入一个磁带机，如rman里分配了四个通道，但备份只有一个磁带机在跑。对于单个磁带机来讲，连续、大量的数据流具有更高的写入效率，如果单个backup piece数据量偏小就需要适当提高multiplexing的复用效率：允许x个会话同时写入该设备（此操作提高数据杂糅度会降低后端消重效率）。

对于Oracle而言，如果数据库性能允许，更多的channel会带来更高的数据读取效率，备份速度越快。然而考虑到备份对业务的影响以及并发性能的限制，最佳的通道数需要多次调整尝试。

除此之外若是oracle的消重备份，如果设置rman读取datafile时的读取块大小以及备份软件写数据的块大小以及设备消重的最小长度呈倍数关系，在消重效率和备份速率上都会有一定提升。

问题3：TSM备份和恢复在oracle rac下的具体操作是怎样的？两个节点都有问题的恢复吗？

TSM for oracle的模块所起的作用，简单理解仅仅是提供了备份恢复的通道而已。所以在处理这个问题的时候先不要被tsm迷惑，仅从单纯的oracle rman角度去考虑即可。

实践上，rac环境的备份恢复仅在一个节点做就可以了，操作步骤基本上和单机环境没什么区别。

唯一需要考虑的一点就是rac环境下两边日志是存储在共享存储还是两边各是个的，要确保备份恢复的动作可以同时获取两个节点的归档信息，其他就没啥区别了。

问题4：磁带库上TSM中log异常增长的问题该如何解决？

有个关于TSM的LOG问题。一直也没搞清楚，

以前用TSM5.2 5.3.在不同的平台。不同的带库上都遇到过。q db或者Q LOG增长的异常，用不了多久就要去扩充TSM DB的容量。但是有的带库这个值就很低。几乎不怎么增长，有人有遇到这样的情况吗，这个DB库的增长是怎样的一种工作机制呢。有那些参数影响到它呢

回答：首先说下原理，tsm自身的db用来存放备份元数据及相关的策略等信息。db的大小和这些是相关的。我之前接触的一个案例，tsm v5，100多个节点，大量的碎文件，dbvolume配了好几个。因为用户需求，需要清掉所有的备份，删了好几天，一边删除一边可以明显的看到 q db在显著下降。

然后说下可能，个人理解一种可能是正常情况，由于业务需求导致的。另外一种可能就是bug了。需要仔细检查，并根据当前的版本信息，去查一下更新补丁的说明，看看已解决的问题里是否有相关项。

TSM自v6版本开始引入db2，与之前版本不同的时候，对tsm自身db要求要经常备份，否则归档日志会越来越多。这个是另外一种情况。建议条件满足的话可以考虑升级到新版本，db2对元数据的处理和大数据支持方面应该会有较大的进步。

如果一定要深入研究，可以通过tsm数据库中的三个基本表（SYSCAT.COLUMNS SYSCAT.ENUMTYPES syscat.tables）去观察相关的表信息。

问题5：现在还有没有好的虚拟带库软件可以练手啊？

回答：MHVTL 开源虚拟磁带库软件

官方网站：https://sites.google.com/site/linuxvtl2/（需墙）

TSM心得及分享

案例分享一：HP UNIX只能识别部分DataDomain VTL 磁带机

部署环境：

DataDomain 4200 （OS :5.5）

HP小型机（HP UNIX 11.31）

现象描述：

1，在DataDomain的VTL里虚拟了16个drive，分享给HP小型机备份使用,。

2，在DataDomain上能够识别HP小型机的HBA卡WWNN，中间链路正常。

3，HP小型机上使用ioscan只能识别其中8个drive，能够正常查看drive信息、使用drive进行备份。

4，HP小型机上再次执行ioscan重新扫描设备，系统日志并无报错，ioscan正常完成。

5，将DataDomain VTL里虚拟的这16个drive共享给Linux主机，16个磁带机正常识别，并能正常备份。

排查思路：

1，HP小型机上识别的8个drive，能够正常查看drive信息、使用drive进行备份。

【部分磁带机正常】

2，在DataDomain上正常识别HP小型机的HBA卡WWNN，能够正常配对。

【中间链路无问题】

3，查看IOSCAN时系统日志，无报错。

【识别过程无报错】

4，将DataDomain VTL里虚拟的这16个drive共享给Linux主机，16个磁带机正常识别，并能正常备份。

【所有共享的drive状态正常】

5，定位问题根本在HPUNIX小型机上。

【OS上找问题】

6，查询HP UNIX设备管理器知识库以及DataDomain知识库。

【查询手册往往是最可靠的方法】

7，在HP UNIX知识库上“HP/UX addressing”一节里定位了VTL drive设备寻址问题。

【设备寻址问题】

8，在DataDomain上“VTL Drive Addressing in HP-UX”找到如下信息：

【一般关联性问题都会在厂商手册中标注】

HPUX only allows 8 LUNs per target with Data Domain system VTL.

VSA addressing is only necessary to see more than 8 LUNs. Also note that device special files will change unless you are using 11iV3 (aka 11.31) and persistent DSFs.

解决方法：

1，在DataDomain上将识别的HP小型机上的 initiator改成VSA（ Volume Set Addressing）模式。

2，在HP小型机上设备配置里完全删除已识别到的8个drive配置信息。

3，重新执行ioscan扫描DataDomain VTL drive，正常识别16个drive。

案例分享二：TSM故障分析一例

故障现象：无法进行每天backup_db的操作；在重启TSM的时候发现，612ABF(ORAPOOL)试图进行reclamation的步骤，但是因为在ORAPOOL中没有其它磁带，所以一直报scratch volume not available的错，同时报reclamation failure和mount failure

故障分析： ORAPOOL中唯一的一盘磁带612ABF的空间已满，所以需要用一盘空白磁带（scratch volume）进行reclamation的操作。由于没有空白磁带在同一个storage pool中，所以造成612ABF无法mount，导致备份操作失败

故障解决方法：故障在加入一盘新的空白磁带SHA476后得到解决。以下是加入新磁带的详细过程和命令： (在操作时，开启另外一个AIX窗口，用dsmadmc–console命令打开一个可以监控TSM log的窗口) 1）label libvolume 3583lib sha476 checkin=scratch overwrite=yes 这时系统在TSM log窗口会给出一个request号，并要求把空白磁带放入3583带库的I/O station中；把磁带放入后，用这个命令继续操作： reply <request号>系统会自动完成把磁带加入libvolume的操作

tob_id_3541

以上命令把sha476加入到libvolume中去，状态设为scratch；可以用这个方法对这条命令的操作结果进行验证： query libvolume可以看到sha476已经被加入，且状态为scratch 2）define volume orapool sha476 这条命令把sha476加入到orapool中去完成以上2步操作之后，系统重新发起reclamation的操作，成功mount 612ABF和scratch volume sha476，完成reclamation操作

案例分享三：TSM调度在hacmp环境下的配置

场景：如果我们的备份对象配置到了hacmp或者其他集群环境下，就意味着，如果资源发生切换，必须要确保备份的调度还能执行。

应对：

当时第一反应是将调度相关的命令配置到hacmp的起停脚本里。调度启动命令放到hacmp的启动脚本，调度关闭命令放到ha的停止脚本里。实施后发现一些问题，有时因为意外原有调度进程死掉了，没有想过的监测机制启动，导致调度窗口丢失。或者发生切换后，原节点的调度进程没正常退出，导致调度接收混乱。

后来想了想设计了一个脚本，放到crontab里，定期执行一下。脚本内容如下：

脚本以db2 with hacmp为例，以db2sys进程为判断对象，如果监测到db2sys进程启动，调度不存在则启动。如果db2sys进程不在，调度进程在则杀掉，调度进程不在自动退出。

后续运行良好，中间意外切换了几次调度都没丢正常备份。

虽然是野路子，胜在好用，分享给大家！

其他：一些TSM的实施和设计的心得，欢迎大家补充

1、设计初期就规划好管理调度，包括卷历史信息备份和删除、设备文件的备份、tsmdb的备份等，可避免后期发生问题时抓瞎

2、数据库的备份效率可通过多通道来实现。以oracle为例，要实现多通道需同时具备以下条件：node属性maxnummp的值；多个物理驱动器；rman脚本中的多个channel。

3、如果备份规模较大，驱动器较多。在设计lanfree时，建议为每个san agent分配独立的驱动器。这样可以避免后期定义调度时，驱动器的争用问题。

4、oracle或db2的备份调度由数据库控制，要确保磁带库的空间不被无效的备份塞满，需具备以下条件：node属性backdelete和archdelete为yes；副本组的属性为1 0 0 0 ；要有删除脚本，并定期执行。

5、注意设置超时参数

6、驱动器最少2个起，1个驱动器要注意做好文件回收池

7、TSMserver端和客户端参数优化:如：tcpip的size的优化，日志保留时间

8、通讯端口如：lanfree端口统一制定，方便防火墙统一配置管理

9、适当多划分自己domain，分开管理

点击原文到“企业备份之TSM备份和归档专题讨论会”可以看更多相关内容

长按下图二维码关注“AIX专家俱乐部”公众号

也可以直接搜索公众号名称“AIX专家俱乐部”或微信号“AIXChina”关注