备份数据的改变率和保存周期

在做TSM备份系统的容量规划时，我们需要考虑的最重要的因素是：备份数据改变率和保存周期。数据的改变率直接影响到日常备份所需要的存储空间，又间接决定了网络带宽使用率以及对备份架构整体性能的要求。另一方面，备份数据的拷贝数（或版本数）和保存时间直接影响着备份空间的大小，无论我们使用磁带、磁盘还是VTL设备都必须考虑这个问题。决定备份版本数和保存周期的因素取决于企业对业务恢复指标的要求，决不能可有可无或只图方便。设计备份数据保存周期的最佳实践是在开始阶段采用适度的设置，然后根据需要决定是否增加；最好不要在一开始就设置一个很长的时间，因为在最初的阶段我们可能还不清楚是否真的需要那么久。不过，一些需要满足法规遵从要求设置的（保存周期）参数不在这个考虑范围之内。

简化TSM的策略域和管理类

毫无疑问，TSM中策略域和管理类的概念对管理员来说是相对复杂且难于管理的。在高端的备份环境中，TSM通过一组被称为策略域（policy domain）和管理类（management class）的逻辑关系来管理客户端系统、备份计划、目标介质和保存周期等重要设置。除非有特殊的原因，比如业务系统要求备份数据的存储位置和保存周期做复杂配置，一般情况下，TSM推荐用户保持最小、最简单的策略域（policy domains）、管理类（management classes） 和备份调度计划（backup schedules）。因为使用太多的策略会使备份环境过于复杂，难以管理且容易出错。

客户端的批量设置

TSM的备份客户端有许多配置选项，这是一个优势，丰富的配置可以满足特殊备份策略或特殊应用系统的需求。TSM的客户端用一个本地配置文件dsm.opt记录基本的配置信息，比如TSM服务器端的IP地址。用户可以在TSM的服务器端以指定的系统或组为单位对客户端进行批量设置。在一些大型的应用环境中，有非常多的TSM客户端节点，集中对客户端进行配置管理无疑比单独维护每个节点的配置文件简单得多。

TSM数据库及日志的维护

TSM自身的管理数据库必须每天都做备份。更理想的做法是每天备份两次，一份拷贝离线保存，而另一份保持在线以便随时能够快速恢复。如果TSM数据库的日志模式被激活，那还必须保证在TSM数据库备份时有可用的磁带空间将日志备走，从而避免TSM数据库的日志达到13个GB的上限值。因为一旦日志量达到上限，TSM进程会被迫停止工作，直到下一次数据库备份时日志被清走。

Storage pool（存储池）的冗余备份

Storage pool（存储池）的备份非常重要，这一点无论怎么强调都不过分。所有主要的磁盘和磁带存储池必须每天备份到副本存储池（copy storage pool）。如果用户使用虚拟磁带库（VTL）设备，那么必须通过建立存储硬件之间的复制关系保护备份数据；或者通过TSM创建一份冗余的介质拷贝，比如用磁带。总之，最佳的备份实践告诉我们，永远不要只有一份备份数据，而且，必须有一份备份介质离线保存。

不要“节约”应用程序的备份代理

降低成本是某些用户感兴趣的话题，因此有人希望通过节省“应用程序的备份代理Agent”来减少TSM软件许可证的支出。但是随着时间的推移这种做法带来的好处会显得微不足道。因为如果我们不使用应用程序的备份代理agent，那么在备份时通常需要关闭应用程序从而保证备份数据的一致性。这也意味着我们无法利用备份代理agent提供的增量备份功能，只能做全备份了。

灾难恢复管理器（Disaster Recovery Manager）

TSM有一个很重要的安全模块叫做灾难恢复管理器（DRM），我们应该按照产品文档的要求完整的对其进行配置。每次TSM的后台进程“准备”运行时，都会通过灾难恢复管理器（DRM）生成一个TSM恢复文件，其中包含了所有TSM的配置信息，连同离线磁带和数据库备份卷的列表。如果TSM发生彻底失败的故障，那么这些信息对恢复TSM系统至关重要。当然了，灾难恢复管理器（DRM）所生成的恢复文件像副本存储池（copy storage pool）和数据库备份一样，每天必须做离线介质保存。

获得更多有关TSM最佳实践的信息可以参考《IBM Tivoli Storage Manager V5.5部署指南》。

关于作者：

Pierre Dorion是Long View系统公司的数据中心业务总监和资深顾问。Long View系统公司总部位于亚利桑那州的凤凰城，专门为企业用户提供数据保护、业务连续性计划和灾难恢复服务。

关于IBM Tivoli Storage Manager备份软件的应用建议（上）