What you will learn from this tip: Learn about the architectural concepts behind IBM's Tivoli Storage Manager backup software and the main differences with what are often referred to as "traditional" backup products. This piece is the first of a series of four on Tivoli Storage Manager.
((Content component not found.))
Acclaimed as the most flexible backup tool ever by some and criticized as the least intuitive by others, IBM's Tivoli Storage Manager (TSM) has been around for many years. First introduced in the early 90s as ADSM (ADSTAR Distributed Storage Manager), the software was built on mainframe data storage management concepts. Note that ADSM itself evolved from a distributed network backup tool called Workstation Data Safe Facility (WSDF) for the virtual machine (VM) operating system developed by IBM in the late 80s.
The major differences between TSM and traditional backups are outlined below.
Progressive incremental backups
IBM's progressive incremental (a.k.a. incremental forever) architecture is probably the best known differentiator. The basic concept is that once a file is backed up, it will never be backed up again by TSM unless it has changed. The first time a file server is backed up, all files are copied, since they have never been backed up to TSM. From that point on, only files that have changed are subsequently backed up. The main goal is to reduce the amount of data that is transferred across the network.
To achieve this, TSM maintains a database of all data objects it copies, which allows it, among other things, to:
Know if a file was previously backed up.
Maintain point-in-time system state information.
When restoring last night's backup for instance, TSM will only restore files as they were at that time, whether backed up the night before or six months ago.
Backup versions
In order to maintain specific point-in-time information, TSM uses backup object versioning. Unlike full/incremental backup products, TSM does not retain (or expire) backups based on "jobs" or media, but rather on file versions. For each file backed up, there is an active version (file as it currently exists on a system) and inactive version (file as it was prior to being backed up again). TSM will retain a user-defined number of versions for a given amount of time. Note that TSM never expires an active version of a file, which is why a file that is backed up once is never backed up again, unless it has changed.
TSM archives
Users can group files in "packages" bearing a time stamp and descriptor. These packages are known as archives in TSM terminology and are deleted after a user-defined amount of time (i.e., one, five, seven years, etc.). Each archive package is considered unique and retained for a specific amount of time regardless of previously stored copies or identical versions on TSM.TSM archives are independent of backups.
Storage pool hierarchy
TSM stores backup objects in storage pools. Backup objects are directed to storage pools, which in turn, are associated with specific device classes (disk, tape, optical). Storage pools can use random access devices (disk) or sequential access devices, such as tape, optical, file, etc. Primary storage pools are organized in a hierarchy, meaning that a storage pool can point to another pool as "next storage pool" allowing data to be automatically migrated when a user-defined capacity threshold is reached. The most common configuration consists in a disk pool pointing to a tape pool where backup data is initially stored on disk and later migrated to tape. TSM also supports the association of a "server" device class with a storage pool, meaning backup data can be transparently migrated from a local storage device to a remote TSM server.
Tape media reclamation
Because backup objects are expired rather than entire backup jobs or media, this creates "logical holes" on a tape volume. Once a threshold of logical free space is reached on certain tape volumes, the remaining valid data is consolidated on a tape that has sufficient space. The tape from which data was moved can then be reclaimed for use.
Command line interface
TSM provides a comprehensive command line interface (CLI) that allows every TSM management, backup, restore, monitoring and reporting operation to be scripted. A CLI is available on both the TSM server and client.
Selective backups
For users who can resist the craving for a full backup, TSM offers a selective backup that allows selected files to be backed up even if they have not changed since the last incremental backup.
Stay tuned for part two of this series on TSM, which focuses on implementation best practices.
About the author: Pierre Dorion is a certified business continuity professional for Mainland Information Systems Inc.
