IBM Tivoli Storage Manager and disk backups

This is the third of a four-part series on IBM's Tivoli Storage Manager disk backup software. This tip discusses integration of disk as a backup media in a TSM environment.

What you will learn: This is the third of a four-part series on IBM's Tivoli Storage Manager disk backup software. This tip discusses integration of disk as a backup media in a TSM environment.

In its early days, one of the features that made Tivoli Storage Manager (TSM), then ADSM, different from other backup products was the use of disk storage as a staging area for backup data. At a time when tape was the backup media of choice, some pundits perceived backing up to disk as a flaw in the software's ability to write to tape efficiently. Now, a software's inability to seamlessly back up to disk is considered a gap. This tip outlines the advantages of disk backups and the various ways to implement disk backup in a TSM environment today.

Why stage to disk?

Essentially, the concept of staging backup data to disk allows TSM to back up more systems concurrently without multiplexing or interleaving multiple systems' data on a single tape or requiring as many devices as the desired number of concurrent backup sessions. The random read/write nature of disk devices allows for as many concurrent host connections as performance will allow. In contrast, tape is a sequential access media allowing only a single data stream at a time, unless data streams are interleaved on the same tape, which can eventually affect restore performance. However, data that is staged to disk must then be migrated to tape, which lengthens the daily backup cycle even if TSM does it automatically. There have been countless debates on the pros and cons of either method.

TSM uses device classes to define the type of media to be used by a backup storage pool. The types of TSM device classes using disk as a backup media are disk, file, Centera, virtual tape library (VTL), server and backup appliances, followed by information on each.


TSM can use disk in a number of ways: direct-attached storage (DAS), storage area network (SAN) disk, or a network share, such as a network attached storage (NAS) appliance. TSM can use disk space at the root of a file system or within a directory structure. On Unix systems, TSM can also write to raw logical volumes. The common denominator is that TSM will format disk volumes to a defined size disk before it can store backup data. Much like a database, TSM uses its own format to which it writes data.


The file device type is a sequential access file on disk that TSM uses to store backup data. At a high level, it can be compared to of a VTL; data is written sequentially to files of a predetermined size much like it would be to a tape volume. File volumes can provide portability for electronic vaulting and offer a more granular control over disk utilization without the need to preformat large volumes.


Similar to the file device type described above, these are logical sequential access volumes created by TSM to store data on an EMC Corp. Centera. One of the main benefits is the added level of protection against inadvertent or unauthorized deletion of regulated archive data provided by the Centera.


Although not exclusive to TSM, the ability to back up to a VTL must be mentioned for completeness. These disk arrays use hardware abstraction layer software to appear like a tape subsystem to TSM. Although conceptually similar to TSM's file device type, VTLs are typically preconfigured for performance and availability. This is not always a given with user configured disk.


Although not necessarily a disk device, TSM can send data to a server device type. This is essentially another TSM server that is defined as a target server to a TSM source server allowing cross replication of backup data between TSM servers. This configuration relies on the creation of virtual volumes, which can be either tape- or disk- based on the target server but transparent to the source TSM server.

Backup appliances

The latest and greatest in terms of backup to disk -- appliances such as DataDomain -- add an extra layer of functionality to the VTL or file device type. Through sophisticated byte sequence analysis, these appliances provide data deduplication that can result in significant backup data compression. The main benefits include reduced storage capacity requirements and lower bandwidth replication, which combined, can significantly reduce tape storage and handling.

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 implementation traps and pitfalls to avoid.

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

Next Steps

IBM Tivoli Storage Manager vs. traditional backup 

Best practices using IBM's Tivoli Storage Manager 

Shedding storage pounds with data reduction technology

Dig Deeper on Disk-based backup