IBM TSM管理软件五个常见的备份错误以及规避办法.docxVIP

PAGE 1 PAGE 1 IBM TSM管理软件五个常见的备份错误以及规避办法  IBM的TSM是最具有敏捷性和易于配置的企业级备份软件之一。本文将着重介绍五个TSM备份常见的问题以及如何避免这些问题的发生。  IBM的TSM是最具有敏捷性和易于配置的企业级备份软件之一。然而在配置TSM的时候有很多需要留意的地方，否则就会遇到管理上的问题或者备份报错。本文将着重介绍五个TSM备份常见的问题以及如何避免这些问题的发生。  数据库备份及恢复日志大小  一个最常见遇到的问题就是在做TSM备份数据库的时候，对恢复日志的大小没有设置正确。在备份的时候，TSM服务器会将备份信息记录到恢复日志里，之后再写入数据库。恢复日志的作用是在数据库损坏的时候能够从上一次备份里面恢复回来，全部的事物记录在之前的数据库备份完成后都会被写入恢复日志，然后再写入数据库本身以保证其最新状态。这也是我们熟知的前滚恢复模式。  当备份操作开始的时候，恢复日志会占用更多的空间因为它会存储事物记录相关信息，不管TSM数据库什么时候开始备份，恢复日志里会记录全部的事务日志。假如在下次备份操作开始前恢复日志满了，服务器会停止接受交易信息。服务器会自动停止工作，除非恢复日志大小得以增长否则将无法启动TSM。这个错误相对比较常见，比如由于失败的数据库备份（没有临时磁带空间），这也往往是因为监控不得力造成的。  在TSM早期版本里，恢复日志的最大值是13GB。在TSM6.1里面，最大阀值已经被提升到了128GB。尽管阀值得到了增加，我们仍旧需要对服务器进行监控以避免突然宕机，因为日志大小仍可能会超过新的阀值。针对这种情形最好的解决方案是，首先要确保我们随时有临时磁带空间用于数据库备份，并且不间断的对数据库备份成功及恢复日志使用大小进行监控。  主磁盘存储池空间过小  客户环境里假如备份设备磁盘和磁带兼用的话，磁盘通常会被用成是主存储池，数据会被先写入磁盘，之后再复制到带库上。这种环境下常见的一个问题是主存储池空间不够，这样会带来备份延迟和备份窗口不够的问题。  当磁盘池快满或者空间将不够的时候，它会自动复制数据到指定的带库上去。但这会严重影响备份进程，因为这个过程很大程度上取决于当时有多少磁带设备空闲以及复制开始时候并发的备份进程数。由于磁盘是随机读取的设备，因此只要磁盘I/O允许的话，磁盘存储池能尽可能多的并行支持备份进程。然而，TSM对磁带操作的时候是根据顺序读写的方式，这就意味着磁盘存储池和单个磁带设备之间仅有单数据流，假如有多个磁带设备的话，就会多进程同时复制。一但发生磁带资源不足的状况，备份进程就会排队直到有空闲的存储资源被释放出来。在磁盘存储池空间不够的状况下，可能会导致备份进程超出备份窗口或者备份失败。  避免这类问题最好的方法就是给磁盘存储池预留足够的空间，这样在备份窗口里，能尽可能多的将数据存放在这里。换句话说，假如每天备份到磁盘存储池的空间有700GB，那么至少磁盘需要预备700GB的空间。另外一种方法是，可以将相对较大的备份直接备份到磁带上而不选择在磁盘上缓存，当然也需要磁带上有足够的空间。  不充分的磁带预备步骤  一个正常的TSM环境里会有一个定期执行的进程能将临时存放在主存储池上的数据拷贝到库上，考虑到灾难恢复上的目的，同时会将每天备份的数据备份到远程站点。这些保存好数据的磁带必需每天正常的出库并送到远程的站点。实际上，许多企业都没有这样做，每周一次将出库的磁带送到远程站点比较正常。但问题是，假如我们遇到了比如洪水，飓风，龙卷风，火灾这样的状况，我们可能会面临数据丢失一周的危急。假如公司的RPO要求策略是每天数据都要备份，那么在远程的数据拷贝每天也需要有。  上面所争论的这些状况其实可以被轻易的避免，前提条件是我们使用的策略步骤正确并使用了正确的容量规划。假如RPO要求的是24小时，那么每天的带库出库并送到远程站点的操作则是必需要的。假如每天要处理这么多磁带不是一件切实可行的事情，那么远程的复制解决方案则是需要借鉴的，常见的方案有基于磁盘的虚拟带库，或者是TSM自身的。有关带库的容量，我们需要确保有足够的存储空间以应对数据的增长。作为另外一种选择，可以将磁带中的一部分数据复制迁移到有消退功能磁盘备份解决方案上，或者缩短数据保留时间，也能起到节约空间的作用。  备份保留时间掌握进程  备份保留时间掌握进程会帮助那些到了保留时间的备份标记会过期状态，通过这样的方法以确保存储池的空间得到自动的掌握。这个进程同样能掌握数据库的条目，从而掌握数据库本身的大小。在一个较大型的TSM环境中，备份保留时间掌握进程有时是需要人工中断的