成功实施Tivoli Storage Manager V5 的建议

成功实施Tivoli Storage Manager V5 的建议

本文主要讨论采用Tivoli Storage Manager实施一个企业级存储解决方案时应注意的地方和推荐采纳的一些建议。Tivoli Storage Manager是一个强大的工具，以下的一些建议可以帮助客户节省时间和尽量避免以后出现问题。
1. 推荐采用渐进式增量备份方案（progressive incremental backup）.
Tivoli Storage Manager 的架构和它的渐进式增量备份方案在业界是独具特色的. 所以懂得和使用这种强大的备份方式是非常重要的。
许多管理员当从完全备份+差异备份转向渐进式增量备份时具有障碍，很难改变原来的观念。他们很难相信Tivoli Storage Manager 能自动管理介质，他们宁愿手工去做这些操作。一种误解，或者拒绝接受渐进式增量备份会导致去采用传统的备份方式，包括每星期进行完全备份（weekly “full”
backups），即使有很少的变化，也要通过Tivoli Storage Manager里的选择备份（selective backups）方式进行备份。
这种思维方式导致了的结果是备份的数据过多，而且，产生了过多的Tivoli Storage Manager数据库对象，这会使数据库的容量变得过于庞大，从而使数据库的访问性能降低。过多的备份数据也会直接导致使用过多的磁带。磁带数目的增加会使购买成本增加，而且也会带来磁带的管理和储存成本的增加，而这些成本的增加都是由于备份了过多的不必要的数据引起的，这些因素也会最终导致客户对于产品的满意度下降。
2. 领会和理解Tivoli Storage Manager的功能
一般来说，了解一个产品的功能对于更好地使用这个产品来说非常重要.
非常重要的是要了解备份和归档（backup and archive）的区别，避免混淆二者的适用范围。
同样重要的是要了解在线和离线（onsite and offsite）磁带的区别和灾难恢复管理器（Disaster Recovery Manager）是如何工作的. 懂得离线流程将决定你是否应该购买Tivoli Storage Manager的扩展版，从而激活DRM 功能。
另一个容易犯的错误是备份了过多的数据，即是备份或归档了一个系统中的所有东西。你应该决定哪些东西需要恢复（restoration），，那些数据需要做灾难恢复（disaster recovery），这样的数据才需要真正做备份。
3.提升并发挥Tivoli Storage Manager 功能的优势.
对Tivoli Storage Manager功能的不理解往往导致实际应用中不能正确使用。尽管Tivoli
Storage Manager 提供了很多功能和特性,但我们不应该过度使用。经常可以看到,一个 Tivoli Storage Manager 的实施被“over engineered”, 比如说,定义了太多的domains, schedules,
storage pools, 或 device classes. “Over-engineering” 会使管理和操作变得非常复杂.了解 你得客户的需求将会帮助你做一个相对更好实施的规划。
例如 Collocation这个功能 ，是一个非常有用的功能, 但如果你针对所有的磁带卷（tape
volumes）都使用这一功能，那么就有可能造成磁带的浪费. Collocation 会直接把一个客户端的数据都尽可能地存储到数量少的磁带上，即使只有很少量的数据作备份。如果collocation这个功能使用太随意， 对于大容量的磁带 例如LTO 会造成很大的空间浪费。而且，从磁盘迁移到磁带会需要更多的磁带驱动器，从而降低备份效率。
同样的例子还有”直接备份到磁带”（direct backup to tape）. 直接备份到磁带只在有大容量的持续数据流，例如：备份Oracle 数据库时，才推荐采用. 对于基于文件（file-based）的备份,
通常每天只有 10 到 20% 的数据变化，而且对象的尺寸都比较小，选择备份到磁盘会更快一些， 这样的话会使备份窗口（backup window ）尽可能达到最小化，当备份完成，你可以定期使用Tivoli Storage Manager 迁移工具把磁盘上的数据再转移到磁带上.
大多数 IT 环境都有特殊的数据应用，例如：数据库或邮件服务器，为这些应用做备份，你需要了解它的数据保护模式，以便决定采用何种方式进行备份。如果用户需要他们的数据库保持24x7的工作模式，那么唯一的解决方案也许就是Tivoli Storage Manager for Databases这个可选模块。如果客户的数据库能够在夜里停下，那么标准的备份/归档客户端（backup/archive client）就能用来备份客户的数据库文件。

4. 仔细考虑你的性能需求.
性能和很多不同的因素有关 — 这些因素之间还相互作用影响。
其中主要的因素有 ：Tivoli Storage Manager server和 client 的硬件配置, 网络, 存储设备,和操作系统。当计算性能时, 包含在存储管理环境里的每一个系统都应该被单独对待或类似的系统类型分组对待，不要假设每一个单独的系统都会有相同的性能。
如果没有专门的网络用来做备份，实际的网络带宽会在运行不同应用的系统之间是共享的，那么真实的可获得的用于备份的网络带宽应该去实际测算，例如：使用一种网络探测器（network sniffer）来测算出网络负荷特征。
即便用分离的网络来做不同的备份，仍然有一些可能导致网络带宽下降的因素需要去考虑，例如：protocol overhead ，要备份的数据量，和客户端的数目。文件级别备份（File level backup）的性能很大程度上取决于存储设备的硬件配置，它所采用的协议以及连接的方式（its protocol and attachment type），和文件系统的类型。
基于备份性能的这些考虑同样也适用于恢复。大多数恢复请求也需要从磁带上读取数据，所以一些其他的因素需要被考虑，像SCSI总线的数目和类型，机械手和磁带mount的延迟（robotics and tape mount delays），设备的读取速率，定位延迟和collocation等都会影响恢复所需的时间。

5. 生产条件下的测试（Test in production situations）.
在一个企业存储管理环境中，备份和归档都是为了一个目的：恢复。无论是一个单独文件，整个文件系统或整个机器，你将需要按照你的服务级别规定的要求尽可能快地把数据恢复回来。
所以在生产环境中，有必要作所有功能的测试，以便有足够的把握，将来可以在需要的时候能够恢复数据。一旦你的测试在实验室的环境下可以工作了，要想办法在真实的生产环境下，重新运行一遍， 不要指望实验室的环境会涵盖所有的可能遇到的情况。如果使用DRM（Disaster Recovery Manager）模块, 策略和方法要认真仔细的加以考虑，实施，形成文档，和进行测试，然后要在正规的环境下在作重复性的测试。
http://blog.ixpub.net/html/59/t-927059.html