Channel takeaway: Installing IBM's Tivoli storage manager in a customer's shop can automate some of the daily backup...
tasks that can occasionally be overlooked. Using Tivoli storage manager to handle some of the menial tasks of storage management can free you and your customer up to concentrate on other tasks.
There are many aspects to consider when deploying an IBM Tivoli Storage Manager (TSM) backup environment. Beyond the basic requirements common to most backup products, such as network bandwidth, I/O performance, tape throughput, etc., some are TSM-specific based on product architecture. The following are generally accepted best practices regarding some infrastructure design and implementation items specific to TSM.
Storage pool collocation
Collocation is TSM's ability to store data from different systems on separate tapes (the opposite of multiplexing). However, collocation can result in poor media utilization when backing up smaller systems and seriously impact library capacity.
Storage pool backups
All primary disk and tape storage pools must be backed up to the copy storage pool on a daily basis. Copy pool tapes (and database backups) should be sent offsite daily to avoid keeping all backup data in one location over extended periods.
Disaster recovery manager
The DRM module of TSM should be fully configured with all "Instructions" files duly documented and maintained. Every time the TSM "prepare" process is run (should be daily), the DRM produces a TSM recovery plan file, which contains all the TSM configuration information along with a list of offsite tapes and database backup volume. This information is essential to recover the TSM server in the event of a total failure. Obviously, the DRM plan file must be sent offsite daily with the copy storage pool tapes and database backup.
More information on TSM architecture and concepts can be found in the IBM Tivoli Storage Management Concepts Redbook (SG24-4877).
Get more information on IBM Tivoli storage manager at SearchStorage.com.