Backup best practices using IBM's Tivoli Storage Manager

This is the second in a four-part series on IBM's TSM backup software. This segment outlines some of the best practices when designing and implementing a TSM backup environment.

What you will learn from this tip: This is the second in a four-part series on IBM's Tivoli Storage Manager (TSM)...

backup software. This segment outlines some of the backup best practices when designing and implementing a TSM backup environment.

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.

Disk pool sizing

TSM can use disk storage pools to stage backup data and later migrate it to tape. Among other things, this allows for simultaneous backup sessions without requiring a large number of tape devices or resorting to data interleaving or multiplexing on tape (more on TSM integration with disk next month). The disk pool(s) must be large enough to hold at least the equivalent of one night's worth of backup data that is directed to disk. Otherwise, data migration to tape might be triggered automatically instead of on schedule and interfere with other processes.

Tape subsystem sizing

The tape subsystem must be sized to hold all the backup data to be kept onsite. Lack of capacity will force the ejection of full tapes to make room for empty (scratch) tapes. This practice interferes with TSM's automated data management processes. Capacity must consider onsite backup data, scratch tapes and growth.

The tape library should also be configured with enough tape devices to accommodate all direct backups to tape, data migration, storage pool backups for offsite, tape reclamation and restore requests for any given daily cycle.

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.

Backup data change rate and retention

The rate at which data changes and how long backup data is retained are the most important factors to consider for TSM capacity planning. The amount of daily backup data dictates network capacity, server performance, staging disk pool requirements and the number of tape drives when backing up directly to tape. How long backups are retained has a direct influence on the tape library capacity.

TSM database and logs

The TSM database must be backed up at least daily and ideally twice with one copy sent offsite and the other kept onsite for rapid restores. If roll-forward logging mode is enabled, there must always be scratch tapes available for database backups to avoid having the logs reach the 13 GB limit, which will force a TSM hard stop.

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.

Backup agents for applications

The "cowboy backup" method (two-step) should be avoided when backing up applications like MS SQL or other databases. This consists of creating a database "dump" to disk and subsequently backing up the flat file. TSM has backup agents that integrate with applications to perform hot backups.


In addition to client backups, all TSM administrative processes should be automated using the central scheduler to avoid errors and omissions. This includes processes, such as expiration, storage pool backups, migration, reclamation and database backups, all of which must be scheduled in order. Ideally, the last TSM processes in a daily cycle prior to vaulting should be the TSM database backup, closely followed by the volume history file backup and disaster recovery manager (DRM) file preparation to capture the latest system state information.

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). Next month, we will discuss TSM integration with disk (native, backup appliances and VTLs).

About the author:
Pierre Dorion is a certified business continuity professional for Mainland Information Systems Inc.

Next Steps

Backup and disaster recovery software

Backup software product specifications

Capacity planning: Reclaim orphaned storage

IBM Tivoli Storage Manager vs. traditional backup

Check out our Data backup and recovery software tutorial.

Dig Deeper on Backup and recovery software