二十个不可不知的 TSM 知识点

偏执的太偏执、 2023-01-23 13:49 5阅读 0赞

你可能是个TSM 新手，也可能是个TSM 老手，但这20个知识点不一定都清晰。

> https://www.sohu.com/a/218745936\_151779

背景知识：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模块

背景知识：TSM的架构和概念

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

1.策略层：含以下概念

*  策略域：相同或相似节点数据保留需求的一个集合体，其下包含策略集。
 *  策略集：策略域的子集，每个策略域中可以有多个策略集，但只有1个是激活的。
 *  管理类：策略集的子类，一个策略集中可有多个管理类，但只有1个是默认的。
 *  副本组：管理类的子类，每个管理类中最多只有2个副本组，按功能分备份副本组和归档副本组。副本组中指定数据存放的策略，并执行存放的位置-存储池

2.存储层

*  库：磁带库，实际上指的是机械手
 *  驱动器：磁带库中的磁带机
 *  设备类：区分不同类型存储的逻辑概念。
 *  存储池：根据设备类的不同，使用不同的存储介质组成的逻辑存储集合
 *  卷：根据不同情况，可能是磁带。也可能是文件或设备。

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

、

TSM 20个常见问题和难点

1、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 能否备份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所管理的磁带库中。

4、TSM系统部署流程是怎样的？需要做好哪些准备工作？

1，备份系统的整体规划，包括存储架构，主机的部署，备份方案的确定。

2，tsm系统的安装配置，初始化。

3，备份服务器的配置，策略域的设置，存储池等。

4，客户端的实施，安装tsm软件包并配置。

5，备份恢复测试。

5、TSM系统在首次部署时关注点有哪些？

1，你需要知道你要备份的是数据库还是操作系统，决定了你要选用的tsm模块

2，备份的数据量有多大，能否在规定的时间窗口内完成备份

3，为了在规定的时间窗口内完成备份，对磁带库有哪些要求

4，如果有同城备份选用什么传输线路？带宽具体多少能满足要求，这些都需要考虑

5，未来数据量增长的趋势，尽量建成备份系统后，满足未来1~3年的数据增长需求

6、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

7、TSM备份调度策略如何规划？

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

1.  正向：基于业务需求，备份窗口等去设计。比如，考虑到白天业务繁忙，为了减少影响需要将备份放到晚上。备份最少需要3个小时，那就要计算好备份的时间段，避免影响业务。
2.  反向：基于存储的实际情况。比如备份环境使用了物理磁带库，驱动器的个数、是否使用lanfree等因素就要考虑进来，避免备份作业设置不当发生驱动器的争用。

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

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

TSM使用两种方法来解决：

1.  设置不同的节点，节点分属不同的策略域
2.  只用1个节点，使用多个管理类，再通过dsm.sys文件中的选项来实现

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

9、TSM存储介质中存储池和库有什么区别呢？

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

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

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

这样就形成闭环了。

10、使用TSM备份Oracle，怎么设置通道会比较好？

通道数越多，对数据库业务影响越大，对数据库的并发读性能要求越高，但如果通道数越多而通过单个通道内备份的data file越少、数据量越小，反而会降低备份效率。备份最终是要落入磁带库的，对于磁带机而言，连续且大量的数据写入效率是最高的。至于怎么平衡，取决于备份管理员对这个系统数据库和备份的理解了。

下面是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时的读取块大小以及备份软件写数据的块大小以及设备消重的最小长度呈倍数关系，在消重效率和备份速率上都会有一定提升。

11、TSM备份和恢复在Oracle Rac下的具体操作是怎样的？两个节点都有问题的恢复吗？

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

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

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

12、TSM备份失败可能的原因？如何处理？

备份软件的日志一般是第一手判断问题的重点。多数成熟的备份软件都会有详细的日志来说明相关的错误。

其次就是确认备份的环境、网络、系统状态、备份服务这些。

很多原因都会导致tsm备份失败，查找原因需要看日志——

查看一小时以前的所有日志：

query actlog

如查看昨天8点以后的所有日志

query actlog begindate=today-1 begintime=08:00:00

查看日志中有关nc\_ora节点的相关信息，可以加上search参数

query actlog search=nc\_ora

查看TSM服务器中的日志信息：

query actlog originator=server

数据库：api的log，tsmserver的log

文件：ba的log，tsmserver的log

RC 106，一般是日志权限的问题，找到需要的日志，加上权限。

RC 12，介质mount不可用，一般是TSM调用带库的时候出现问题，查查驱动器和path，看看存储池的最大可用scratch数值；如果是磁盘，看看磁盘的文件系统权限。

第一次启动调度的时候，如果调度进程未启动，可能是因为password生成参数没设置好，或者没有手动的登录一下客户端。

ANS0102W，语言包的问题导致dsmc登录不了，将/opt/tivoli/tsm/client/lang/en\_US目录内所有内容，拷贝到/opt/tivoli/tsm/client/ba/bin目录下试试。

ORA-19554，动态链接库的问题可能大些。

如果日志表述无法直接定位问题，那么需要分析该问题是服务器端还是client端的问题，如果其他备份作业成功完成，那么备份服务器基本判断可用；之后看存储池，发起测试备份写入该存储池，如果可行则存储介质基本判断可用，带库路径驱动器路径可用；如果是数据库备份，则尝试发起文件备份，如果文件备份成功，那么基本判断是该节点的数据库备份问题，那么可以尝试重新执行配置，和检查配置文件的方式，判断问题。

13、TSM备份软件实现数据级容灾的实现方式是怎样的？

数据容灾，根本思想是关键的业务数据保留多份备份（本地和远程）。 支持业务的基础架构还有许多其他东东，物理机/虚拟机，虚拟机管理系统，存储系统，实际的软件/中间件/数据库等。这些都好恢复，数据丢了就歇菜了！ 要想提高可用性，实现容灾，提高RPO, RTO,也可以采用应用层方案，多活中心等，应用架构设计就考虑软硬件故障，site故障等情形，但代价很高，更多的软硬件，系统架构，运维更复杂等等，一般的企业不现实。 所以数据级容灾就是以尽量小的代价获得较高的收益！

TSM 大概可以有几种方式：

云备份池：

最新的7.1.6支持 复制数据到云备份池（openstack, amazon, clearsafe), 复制到云池的数据在线去重/压缩。

磁带拷贝池：

传统方式，主池定期做备份到拷贝池(一般每天），拷贝池磁带check out后运往本地或远程灾备中心。 相似的还可以采用export to tape, generate backupset to tape.

企业多站点，多个TSM Server的时候：

TSM server之间可以repl node/protect stg（6.3+以上server)，export to server将数据存在别的server中一份。

RPO/RTO 跟你使用的备份方式密切相关，比如采用磁带拷贝池，晚上对主池备份一次，运到灾备中心，RPO只能是恢复业务到一天前状态。那我们采用云备份池/TSM server之间可以repl node/protect stg，设定每天更频繁的数据复制，则RPO是以小时计，整个业务系统可以恢复到几个小时前的状态。

RTO 则跟实际恢复数据时间（磁带恢复速度）， 你的网络带宽（repl node方式，云备份池），从灾备中心运回磁带的速度，恢复其他基础架构的时间密切相关。

14、虚拟带库里有这样一盘磁带，在TSM下看是空的scratch状态，在EMC控制台下看到是满的？

1.查看带库日志和备份软件相关日志信息；

2.TSM备份配置参数：

如果collocation的参数设置不是no。则可能的参数值包括：filespace，node，group。

如果设置为filespace，则磁带选择的顺序是：

1． 优先选择已经备份同一文件空间数据的磁带；

2． 已经定义的空白磁带；

3． 定义为scratch的空白磁带；

4． 包含同一节点数据的已经使用过的磁带；

5． 空间最大的一盘已经使用过的磁带；

如果设置为node，则磁带的选择顺序是：

1． 包含同一节点数据的已经使用过的磁带；

2． 已经定义的空白磁带；

3． 定义为scratch的空白磁带；

4． 空间最大的一盘已经使用过的磁带；

如果设置为group，则磁带的选择顺序是：

1． 优先选择已经包含来自客户端所属的collocation group的备份数据的磁带；

2． 已经定义的空白磁带；

3． 定义为scratch 的空白磁带；

4． 空间最大的一盘已经是使用过的磁带。

面对上述例子中情况，用户可以考虑下列方法来跳过需要等待的60分钟。

在checkout命令执行完后，修改磁带A0000的access属性为unavailable。命令如下：

update volume A0000 access=unavailable

15、备份VCener的解决方案

通过VMware VADP接口，将数据映射并和TSM API（TSM for VE）结合后，直接集中备份到备份设备中存放。

采用持续增量备份，就是TSM的永久增量备份技术，可以以最合理的方式减少备份窗口，冗余数据和备份设备介质的资源使用率。

只有第一次是全备份（去掉了VM的空块空间）。

后续备份，全部采用持续增量备份，自动启动VMware的CBT（changed Block Tracking)功能，并跟踪块的变化进行仅增量备份。

16、TSM 怎样实现归档SQLServer 2012 AlwaysON环境的数据库的备份？

SQL Server2012中新增的AlwaysOn是一个新增高可用性解决方案。在AlwaysOn之前，SQL Server已经有的高可用性和数据恢复方案,比如数据库镜像，日志传送和故障转移集群.都有其自身的局限性。而AlwaysOn作为微软新推出的解决方案，提取了数据库镜像和故障转移集群的优点。

因为always on 环境下，数据文件都到了 cluster节点对应的存储池中。

现在我想到的另一个方法就是单独通过SQL备份出文件，然后文件 归档到TSM

上面这种备份方式需要测试数据的完整性，确认数据是否可用。

17、如何保证TSM服务器端与客户端的正常运行？

1，注意定期对tsm服务器和客户端的巡检，及时发现问题并处理。

2，定期检查tsm备份是否成功，如果备份失败查清原因并处理。

3，定期做好备份数据的恢复演练，保证tsm备份成功的数据是可用的。

4，配合自动化启停脚本完成TSM系统的监控。

18、如何做到TSM系统的自动运维？

1，可以考虑使用crontab或调度完成备份，配合脚本完成日常检查，比如邮件等功能，可以结合监控软件如bmc或zabbix完成物理硬件和应用可用性监控，当然可以配合商业产品完成漂亮的图表等查询功能。

2，把TSM的运维做好的话，每天的人工巡检是一部分工作之外，可以考虑投入一部分资金基于TSM平台进行一些开发，因为TSM有这样的接口，比如调度执行结果，尤其是TSM调用脚本执行的结果，日志在本地生成，可以考虑通过Agent采集的方式把日志收集上来；比如数据量监测，每天的数据量都维持在一个平稳的数值，如果某一天数据量上来了，应该关注一下。应该有一些工作在做这方面的定制化。

19、为啥TSM对调度要“暂挂”

TSM如果对调度进行“立即运行”的时候，它会暂挂个好几分钟，为什么要这么久呢？没什么设计理由让它等这么久吧？

是从OC/AC 上提交的吧，这个从用户角度是比较搞笑哈 ：）

实际TSM Scheduler的决定运行某个schedule的时候，是有一定的随机性的，比如我们设定schedule的时候，大部分要设定一个启动时间范围，Server在这个时间范围内启动schedule就可以了。

从Server的角度考虑，在某个时刻，server可能面临各种操作，比如客户备份，恢复数据，expire inv, migration， reclamation. 还有一些内部damon做其他检查，比如后台线程做tsm db index rerog等等， 如果在一个时间段设定了很多schedule, 先启动那个，后启动那个呢？ 为了避免冲突，server就尽量在符合设定的情况下， 按自己的节奏来启动这些活动，就是有一定的随机性。

20、TSM 经常会遇到物理带库里的部分或个别volume不能自动回收如何定位问题？

在tsm的使用过程中，经常会遇到部分或个别volume不能自动回收，比如说保留策略为一周，时常能够发现个别好几个月前的磁带还在带库中，没有被回收。其中里边的数据也均是老数据。1 ）遇到类似问题，应该如何操作和避免呢？ 2）有没有什么好的手段或机制做检查，发生这个问题的原因又是什么，如何定位问题 ？

1.  如果你的带子很多，存储空间也够，忽略这些问题好了。

想回收的话，检查tape pool的回收阀值设置， 查看每个卷的可回收空间 pct\_reclaim，

select volume\_name,status,pct\_reclaim from volumes where stgpool\_name=‘TAPE’ and pct\_reclaim >= 0.0

http://www.thobias.org/tsm/sql/\#toc120

然后可以降低RECLaim 的阀值，让server回收这些磁带。

update stg TAPE RECLAIMPRocess=4

RECLaim STGpool TAPE THreshold=10

或者用 命令 Move data vol\_name 将这些磁带里数据挪到别地，然后老带子在REUsedelay天数过后就可以利用了。

1.  应该是可回收空间 pct\_reclaim 没有达到回收阀值，或者回收就没有有成功（查actlog，回收需要tape\_pool里有额外的空白带或空间）

检查tape pool的回收阀值设置，mascr 设置以及 REUsedelay 的设置。 q content 查看是那些节点的数据，是否是新数据还存在这些带子里？ 如果都是老数据没有被expire inv过期，这个没有详细信息不好说，根据数据类型不同：归档数据，备份数据？ 先查查copygroup的各项设置吧。