在过去的15年时间里，IBM的Tivoli Storage Manager (以下简称TSM)备份软件经过不断发展，已经成为市场上的主流产品，广泛地应用于企业级备份环境。TSM产品具有丰富的配置选项，灵活性非常强；但是对于一些经验尚不丰富的备份管理员来说，过多的配置功能却是复杂和难于理解的。

与其他大多数备份产品相比，在部署TSM备份软件之前，我们需要做更多的准备工作。不仅要考虑恢复指标（RPO、RTO）、网络带宽、介质容量等常见的基本要素，而且还要满足TSM的特殊（环境）要求，而这些特殊的地方是由TSM的技术架构决定的。下面我们介绍几个与TSM方案设计和项目实施相关的最佳实践。

注意Disk pool的大小

TSM使用disk storage pool（磁盘存储池）的概念，备份时先将数据写到disk storage pool，然后再迁移到磁带介质。Disk pool的设计实现了多任务多数据流并发备份，而传统的磁带库设备则需要多个driver（磁带驱动器）才能实现多数据流的并发。Disk pool的空间必须足够大，至少能容纳整晚的备份数据。如果出现空间不够的情况，TSM会提前触发磁带迁移操作，那样不但破坏了预设的时间策略，进而也会产生对其他后台进程的干扰。

慎用重复数据删除

对于一般的磁盘备份来说，增加重复数据删除功能是必然趋势。但是，在TSM的staging磁盘空间使用去重技术却不是一个好主意。考虑到获得最佳的去重比率需要一个长期过程，重复备份次数越多去重比率越高，因此非临时性的存储空间更适合进行重复数据删除。与最终迁移到磁带存放相比，数据在Staging磁盘中存储的过程是暂时性的，而这点决定了staging中的数据不适合做去重处理。所以，如果我们用带有重复数据删除功能的磁盘存储设备作为备份最终迁移目标（代替磁带库），可能会获得更好的去重效果。

磁带子系统的容量规划

磁带子系统一定要能容纳所有的备份数据，如果容量不够，那么管理员就必须手工退出写满的磁带为空磁带腾出槽位，这势必会影响TSM的自动化管理能力，通常还可能导致介质管理的混乱。因此，当我们规划磁带容量的时候，必须考虑备份数据的总量、单盘磁带的容量和数据未来的增长趋势等因素。同时在容量规划之前，我们还必须确定采用何种备份策略以及数据的保存周期。举个例子，如果计划对一个300GB的系统每天做一次全备份，数据保存周期是15天，那么仅这个系统就需要4.5TB相当于自身大小15倍的磁带空间。像这样的案例，容量规划必须放在前面，绝对不能事后才考虑。

除了保证磁带数量，磁带库还应该配置足够多的driver（磁带驱动器）。因为需要磁带库的多个driver同时工作，以处理日常的并行备份任务及各类数据吞吐请求，包括：直接到磁带库的备份、从storage pool到磁带的数据迁移、磁带回收、数据恢复等。顺便提一下，虚拟磁带库（VTL）和重复数据删除技术的出现，能够帮助用户解决备份空间管理的问题，也可以实现并行数据吞吐（不像磁带库那样需要准备多个driver）。

磁带的并置备份

并置（collocation，或布置）是TSM的一项功能，与并发备份将数据流分散到多个磁带不同，并置功能会控制备份进程将同一应用系统的数据集中写到一盘（或一组）磁带上。这就意味着来自于一个系统的数据不会与来自其他系统的数据混合存储在多盘磁带上。因为不需要从多盘磁带上检索数据，因此并置备份的系统在数据恢复时能显现出比较明显的性能优势。然而，在对一些数据量较少的系统做备份时，并置功能会降低磁带利用率，导致空间的浪费。TSM现在改进了并置功能，提出了一个新的概念collocation groups（并置组），与所有系统都必须采用（或完全不采用）并置备份相比，这是一个折中的方案，用户可以自定义使用并置备份的对象，建立并置备份组。

并置备份大大减少了数据碎片，但也可能严重影响磁带介质的利用率，因此，必须小心使用。对于一些数据量不足以写满一盘高容量磁带的小系统来说，实施并置备份非常糟糕。试想一个只有10GB数据的Web服务器独占800GB容量的LTO-4磁带是多么浪费，而且这盘磁带还要占用一个宝贵的磁带库槽位。这里应该考虑用VTL（虚拟磁带库）或带有重复数据删除功能的磁盘来取代磁带存储，因为磁盘系统可以显著地减少备份数据碎片，并避免小系统并置备份对空间的浪费问题。

请继续阅读：关于IBM Tivoli Storage Manager备份软件的应用建议（下）