Christian Pruett kicks off a series of articles on TSM, focusing on how it works on AIX servers. Part 1 gives an overview of TSM and its nuts and bolts.
A major area of focus for POWER IT Pro has been the AIX OS and associated IBM Power Systems architecture. I’m going to diverge a bit from that arena now as I kick off a series of articles on a related topic: backup and recovery software. Backup and recovery is related to and a crucial part of effective systems administration, and it’s essential for mission-critical environments.
In my years of experience in AIX and UNIX systems administration, I’ve used backup and recovery products from a variety of vendors, such as Symantec NetBackup, CommVault, and other bare-metal software packages. I’ve led disaster recovery drills and real-life exercises, putting business continuity plans to the test by using disks, tapes, and hot- and cold-recovery sites. I’ve found one piece of software that ties in most closely with AIX and tends to fall under the purview of systems administrators for disaster recovery and general backups and restores. It should be no surprise that this software—IBM Tivoli Storage Manager (TSM)—falls under the larger IBM umbrella.
In this series, we’ll look at TSM, focusing on how it works on AIX servers. We’ll begin with an overview of TSM and its nuts and bolts, covering topics such as the server-client relationship, the TSM database and log, and storage concepts such as pools and incremental backups. From there, we’ll move on to the server side and discuss topics such as setting up TSM libraries, checking in tapes, and using command syntax. After that, we’ll look at clients, including domains, backup retention, and doing incremental backups. Finally, we’ll pull together our knowledge of TSM by discussing what a day-to-day schedule might entail and how to be prepared for a true disaster.
Four main concepts help explain how TSM works: server-client relationship, storage pools, storage and recall of data, and incremental backups and active versus inactive data. Let’s examine each concept.
Server-client relationship. The name “Tivoli Storage Manager” refers to an entire suite of software products designed to help back up and recover data. The TSM suite comprises a range of parts—from components that facilitate data archiving and work with databases to utilities that enable direct communication over a SAN. However, when people refer to TSM, they’re usually talking about the TSM server and client software, which will be the emphasis of this series.
The TSM server is a centralized system that receives, inventories, and stores data sent from TSM clients. The TSM server typically has a large quantity of disk storage and a tape library assigned to it. Information about what data has been stored on the TSM server, as well as a log file for querying events and tracking changes, is contained in a relational database kept on the system.
TSM clients are systems that back up their data to the TSM server. These clients are identified on the TSM server as nodes. It’s possible to have multiple nodes on the same client box. For instance, on a database server, one defined node might handle some application and OS-related data, whereas another defined node might back up the database information using different retention rules.
Storage pools. On the TSM server, disks and tapes are gathered into common pools of resources. These storage pool resources can be prioritized in a hierarchical manner, and data can cascade down from one pool to another. For example, business-critical data might first go straight onto a solid state disk (SSD) storage pool to keep the transaction time over the network to a minimum. At some point, the same data might go to regular DASD for longer-term storage and ultimately might be migrated to tape for offsite storage. These pools can be set to migrate data automatically based on high and low water marks.
Data storage and recall. Within TSM, data can be transferred to a TSM server by a backup or an archive. Typically, backups are used for short-term and day-to-day utilization, whereas archives are used for sending data off for long periods of time and might be run only once a month or even once a year. Likewise, this data can be brought back by restoring the backup or retrieving the archived information.
Incremental backups and active versus inactive data. After an initial backup, the TSM server takes note of the date and timestamp of the backed-up files. After this point, most subsequent backups are done in an incremental fashion. This means that the backup will grab only those files that have had their dates and timestamps changed. An incremental backup keeps the quantity of data on disk and tape storage relatively low because static files aren’t needlessly duplicated.
Following the initial backup, all files are labeled as “active” in the TSM server’s database. But when an incremental backup arrives, the prior version of the file is marked as “inactive” and the new backup of the file becomes the active file. This makes it possible to have several inactive, older copies of the file—which could span back days, weeks, months, or even years—present on the TSM server.
After the maximum number of inactive files has been reached, or after a certain amount of time has passed, TSM will remove the last inactive file from the database on the TSM server and reclaim the space that the file used. Because there’s no limit to how often incremental backups can be run by default, it’s possible to expend all possible inactive versions of a file by running backups too frequently.
From the Basics to an Actual Backup
The best way to see how these essential TSM components work is to set up a TSM environment and do a few test backups. In my next article, we’ll explore how to configure a TSM server and define the resources necessary to assemble a solid disaster recovery solution.
*Editor's Note: This article originally appeared in the November 2012 digital edition of POWER IT Pro.