求一个TSM备份失败的问题

donggua0713

把备份写入到EP0563L4这盘带子时出错的时间记一下，比如说两天前的10：00：00
q act begind=today-2 begint=09:00:00 > output.txt

把这个output.txt发上来看看。

还有q vol EP0563L4 f=d 发来看看

donggua0713

日志还没看完，就看到你这个TSM的自身的数据库，竟然有2500多M的变动数据，也就是说你的TSM数据库急需备份，不然碰到问题就悲剧了。

donggua0713

我看到，在15号下午5点半的时候，还用了EP0563L4这个带子，用得很正常，当时file这个客户段备份了174G的一个文件，然后在16号早上5点的时候，备份到42G的时候，就报错了，然后16号9点左右，有人吧EP0563L4这个带子checkout了，17号备份的时候，需要这盘带子，但找不到，1小时挂载请求超时后，将EP0563L4带子设为不可用了。接着用了EP0560L4这个带子，但是同样备份到40G的时候，就报错了.

把file这个客户端的dsmerror.log发上来看看。

donggua0713

TSM自身的数据库大小和你说的回收没关系的。
我看到有自从上次数据库备份以来，有2500MB多的变化，然而却没有备份，我怀疑，这套TSM系统，根本就没有定时备份自身DB的机制。这个TSM系统存在严重的安全隐患。

donggua0713

我怀疑这个TSM的log现在应该是相当的大，你q log 看看

donggua0713

客户端的dsm.opt文件呢？

我觉得这个问题与这盘磁带没有关系，应该是出在FILE这个客户端本身上。因为ANS1512E 返回代码12 ，一般都是与客户端的设置啊，配置啊之类的有关系。

donggua0713

把file这个客户端的dsmerror.log 全发出来啊，不要发一点嘛

donggua0713

这个故障，看起来像个bug，建议先chkdsk 来检查一下这个大文件所在的磁盘。再手动备份几次试试。

不知道你这个文件是什么，有170多G，却用vss这种方式来备份，如果是数据库的数据文件之类的东西，建议用专门的TDP客户端来备份，如果就是一个普通的大文件，建议用普通的方式来备份，不要用vss。

针对这个故障，我有几个建议：
1.检查这个文件所在磁盘，文件，等等一些东西。
2.升级客户端。
3.如果这个文件不是普通的文件，是数据库，或者其他的应用数据文件，用专门的TDP来备份。
4.如果这个文件是普通文件，不要用vss来备份，就用普通的方法来备份。

还不行，打800，叫IBM来上门，注意这一条错误：
2010-05-07 11:51:22 GetDfsEnum(): Server=\\sy-file-01, NetDfsEnum() returns RC=1722.

donggua0713

你这个文件到底是个什么啊？是不是当初规划的时候没有做好啊，竟然要先用ntbackup备份，再用TSM备一次，这到底是个什么需求呢？QQ我吧，262870803，我也想了解一下