如何应对 TSM 的 9 个运维难点？

TSM（IBM Tivoli Storage Manager）能够为用户提供企业级存储数据管理的全面解决方案，包括集中的数据备份与恢复管理、专业的数据归档管理功能、高级的分级存储功能和流程化的灾难恢复管理。为了让大家对其运维难点与故障处理有更好的理解和应对，社区组织了相关交流，促进大家共同交流学习提高。以下是活动中社区专家和会员分享的运维难点与故障处理经验，由社区专家聂奎甲整理编辑，供大家参考。

1.备份软件常见的故障有哪些，如何处理这些故障？

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

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

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

数据库：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，动态链接库的问题可能大些。

2.当备份软件出现无法备份或是备份失败的情况应该如何诊断出现问题的原因并处理问题？

TSM的话，文件备份直接查看日志dsmsched.log文件，数据库的话查询对应的日志，日志一般都是在dsm.sys对应的调度内容上指定的。如果日志直观的话，可能直接会显示出问题所在，比如文件正在使用使用跳过，或者超出存储空间等报错，或者归档日志不连续找不到归档，数据库非归档失败等等；

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

3.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方式，云备份池），从灾备中心运回磁带的速度，恢复其他基础架构的时间密切相关。

4. TSM在恢复Oracle时，怎么设置rman的备份集和备份片，来使恢复效率更高？

在默认情况下，一种类型的文件在备份集中都会存成一个备份片段。不过考虑到如果文件较大，生成的备份片段可能也较大，甚至超出操作系统限制（不稀奇，比如Windows平台下FAT32文件系统，单个文件最大不能超过4GB），在你真正创建备份策略之前，备份片段文件大小显然也得在考虑范围之内。

RMAN在分配通道时有一个参数MAXPIECESIZE，就是专门用来指定备份片段大小的，例如，备份SYSTEM表空间，指定单个备份片段最大不能超过10MB

单个备份集的最大值可以在执行备份命令（或分配通道）时通过MAXSETSIZE参数指定，比如：

RMAN> BACKUP DATABASE MAXSETSIZE=100m;

MAXSETSIZE参数指定的是单个备份集的最大值，与备份片段无关，不过默认情况下，一个备份集对应一个备份片段，因此也相当于指定了备份片段的大小，但是直接指定MAXSETSIZE参数限定备份集大小并非在所有情况下都适用，如果要备份的数据文件中，任意一个数据文件超出了指定参数值，则备份就会失败（前面示例命令执行肯定失败，因为默认情况下SYSTEM表空间数据文件就接近300MB）。因此，对于在实际应用中需要限制生成文件大小的情况，更多还是会通过MAXPIECESIZE参数限制备份片段，而不会直接限制备份集。

5.虚拟带库里有这样一盘磁带，在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

7.备份VCener的解决方案

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

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

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

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

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

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

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

现在我想到的另一个方法就是单独通过SQL备份出文件，然后文件 归档到TSM
上面这种备份方式需要测试数据的完整性，确认数据是否可用。

9.带库中磁带寿命大概多久，一盘磁带反复回收重写会有什么影响吗？ 带库驱动器三天两头提示需要清洗该如何解？

磁带终究是一种易耗品。和周围的环境，磁带本身的质量。驱动器等都有关系。我们曾经遇到过一个驱动器有问题。会加速磁带的损坏。基本上这个驱动器在的时候两三个星期就会出现一盘坏带。

磁带属于易耗品，容易坏，和保存方式，空气的湿度、温度使用次数都有关系，一般三年左右就得更换，对于需要无限保留的数据可以使用光盘塔方式保存！

磁带寿命的理论时间确实没有什么指导意义。大家都知道电子产品也好。磁带也好。说怀就坏。如果用了五年，还是建议做出准备来更换。

 主要分享者 

聂奎甲   长春长信华天 项目经理

工作至今10年，主要参与项目规划实施，主要参与政府、电力、国土等行业的系统集成项目，包括主机存储、oracle数据库，精通计算机网络与安全，熟悉IBM等存储。

pingpang1018  启明信息 系统工程师

Jerry Lee  BRS CE 系统架构师

baizhaoxian 万国数据服务有限公司 数据库架构师

更多相关文章，请点击阅读原文

长按二维码关注公众号