IBM的TSM是最具有灵活性和易于配置的企业级备份软件之一。然而在配置TSM的时候有许多需要注意的地方，否则就会遇到管理上的问题或者备份报错。本文将着重介绍五个TSM备份常见的问题以及如何避免这些问题的发生。

数据库备份及恢复日志大小

一个最常见遇到的问题就是在做TSM备份数据库的时候，对恢复日志的大小没有设置正确。在备份的时候，TSM服务器会将备份信息记录到恢复日志里，之后再写入数据库。恢复日志的作用是在数据库损坏的时候能够从上一次备份里面恢复回来，所有的事物记录在之前的数据库备份完成后都会被写入恢复日志，然后再写入数据库本身以保证其最新状态。这也是我们熟知的前滚恢复模式。

当备份操作开始的时候，恢复日志会占用更多的空间因为它会存储事物记录相关信息，不管TSM数据库什么时候开始备份，恢复日志里会记录所有的事务日志。如果在下次备份操作开始前恢复日志满了，服务器会停止接受交易信息。服务器会自动停止工作，除非恢复日志大小得以增长否则将无法启动TSM。这个错误相对比较常见，比如由于失败的数据库备份（没有临时磁带空间），这也往往是因为监控不得力造成的。

在TSM早期版本里，恢复日志的最大值是13GB。在TSM6.1里面，最大阀值已经被提升到了128GB。尽管阀值得到了增加，我们仍然需要对服务器进行监控以避免突然宕机，因为日志大小仍可能会超过新的阀值。针对这种情形最好的解决方案是，首先要确保我们随时有临时磁带空间用于数据库备份，并且不间断的对数据库备份成功及恢复日志使用大小进行监控。

主磁盘存储池空间过小

客户环境里如果备份设备磁盘和磁带兼用的话，磁盘通常会被用成是主存储池，数据会被先写入磁盘，之后再复制到带库上。这种环境下常见的一个问题是主存储池空间不够，这样会带来备份延迟和备份窗口不够的问题。

当磁盘池快满或者空间将不够的时候，它会自动复制数据到指定的带库上去。但这会严重影响备份进程，因为这个过程很大程度上取决于当时有多少磁带设备空闲以及复制开始时候并发的备份进程数。由于磁盘是随机读取的设备，因此只要磁盘I/O允许的话，磁盘存储池能尽可能多的并行支持备份进程。然而，TSM对磁带操作的时候是按照顺序读写的方式，这就意味着磁盘存储池和单个磁带设备之间仅有单数据流，如果有多个磁带设备的话，就会多进程同时复制。一但发生磁带资源不足的情况，备份进程就会排队直到有空闲的存储资源被释放出来。在磁盘存储池空间不够的情况下，可能会导致备份进程超出备份窗口或者备份失败。

避免这类问题最好的方法就是给磁盘存储池预留足够的空间，这样在备份窗口里，能尽可能多的将数据存放在这里。换句话说，如果每天备份到磁盘存储池的空间有700GB，那么至少磁盘需要准备700GB的空间。另外一种方法是，可以将相对较大的备份直接备份到磁带上而不选择在磁盘上缓存，当然也需要磁带上有足够的空间。

不充分的磁带准备步骤

一个正常的TSM环境里会有一个定期执行的进程能将暂时存放在主存储池上的数据拷贝到库上，考虑到灾难恢复上的目的，同时会将每天备份的数据备份到远程站点。这些保存好数据的磁带必须每天正常的出库并送到远程的站点。实际上，很多企业都没有这样做，每周一次将出库的磁带送到远程站点比较正常。但问题是，如果我们遇到了比如洪水，飓风，龙卷风，火灾这样的情况，我们可能会面临数据丢失一周的危险。如果公司的RPO要求策略是每天数据都要备份，那么在远程的数据拷贝每天也需要有。

上面所讨论的这些情况其实可以被轻易的避免，前提条件是我们使用的策略步骤正确并使用了正确的容量规划。如果RPO要求的是24小时，那么每天的带库出库并送到远程站点的操作则是必须要的。如果每天要处理这么多磁带不是一件切实可行的事情，那么远程的复制解决方案则是需要借鉴的，常见的方案有基于磁盘的虚拟带库，或者是TSM自身的。有关带库的容量，我们需要确保有足够的存储空间以应对数据的增长。作为另外一种选择，可以将磁带中的一部分数据复制迁移到有消除功能磁盘备份解决方案上，或者缩短数据保留时间，也能起到节省空间的作用。

备份保留时间控制进程

备份保留时间控制进程会帮助那些到了保留时间的备份标记会过期状态，通过这样的方法以确保存储池的空间得到自动的控制。这个进程同样能控制数据库的条目，从而控制数据库本身的大小。在一个较大型的TSM环境中，备份保留时间控制进程有时是需要人工中断的，否则就不会停止。事实上，TSM软件允许备份管理员对这个进程设置一个特别的参数来控制这个对资源要求比较高的进程每天允许时间的长短。虽然中断进程本身不是什么难事情，但可能会产生一些问题出来。如果我们不让进程自动完成而采用人工中断的方式，可能会在数据库里插入比过期时间更多的记录，这样数据库会比原先更大。

备份保留时间控制进程之所以运行的时间比较久是因为它的操作还会包含最近对备份数据手工删除的清理，而这些操作对TSM服务器上的资源是个不小的挑战，或者是说TSM数据库超对于单一服务器实例来说过了可管理的大小。这种情况可以通过日常对备份服务器性能上的监控来避免。此外，避免一次删除数据较大的备份可以帮助缓解已有的性能问题，还有我们建议在企业级数据保护环境下使用多套TSM服务器实例以保证性能和功能上的需求。

最大并发进程数

另外一个常见的报错和配置文件中定义的可允许最大备份连接数有关。这个错误在新部署的TSM环境中或者是一次加入多个备份客户端的情况下比较常见。有关最大备份连接数的默认的数值是25，在生产环境中，这个数值很容易被超过。再加上默认一小时的备份窗口，可能会造成备份的失败。和前面所提到的方法一样，只要能保证定期也充分的监控，就可以很大程度上避免问题的发生。这就是说，最好解决这类问题的方法就是首先要准备一个配置检查列表来记录变动的信息，比如说增加了备份客户端或者是TSM环境做了大的改变等。

IBM TSM是一款高度定制化且灵活的备份软件，在专业人员正确安装和配置后，它会是一款高效的备份解决方案。这就是说，产品的灵活性同样也意味着复杂程度的增加，灵活性本身是好事，但有些时候也会造成配置或者运行上的问题。相信任何备份软件都会面临类似的问题，早期发现问题并解决问题最好的方法就是有适当的监控机制。其实，不充分的监控本身也是一种错误，其严重程度不亚于产品本身的报错，但庆幸的是这也是最容易避免的。