Connect With Us

The Tivoli Storage Manager Cheat Sheet, Part 1

Explore AIX backup and restore using IBM’s enterprise storage management product

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.

TSM Basics

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.

Learning Path

Automated Tiered Storage with IBM Power Systems

Easy Ways to Trace VSCSI Configuration with AIX

SAN Migration via LVM: Don’t Forget Raw Logical Volumes

Solid State Disk: PureFlex and the Speed for Need

*Editor's Note: This article originally appeared in the November 2012 digital edition of POWER IT Pro.

Discuss this Article 1

UNIXman
on Mar 3, 2013

ok, good introduction.
We will install and apply TSM solution next month in our company, so I'm waiting this useful series.
Thanks Christian

Please or Register to post comments.

AIX User-Related Commands

Download AIX User-Related Commands (Infographic) today! This quick guide highlights differences between user administration commands on AIX and other UNIX-derived operating systems.


POWER IT Pro Blogs
LPI Exam Objective 101.3: Runlevels, Shutdown, and Reboot
May 13, 2013
blog

LPI Exam Objective 101.3: Runlevels, Shutdown, and Reboot

This entry in the LPI certification exam blog series discusses the third objective in the System Architecture topic of the exam: Linux runlevels, and shutdown and reboot procedures....More
May 13, 2013
blog

Feedback Loop

I had more feedback from readers to my article, "The Forgotten", than practically anything I have written before. If you missed it, it told the story of a conversation I had with the financial director a mid-sized British food retailer....More
May 13, 2013
blog

COMMON Europe Cancels Flagship Conference

COMMON Europe has cancelled its flagship annual conference, due to be held next month in Annecy, south-eastern France....More
eBooks & Training
Secrets of an AIX Administrator by Christian Pruett
Dec. 13, 2012
Datasheet

Secrets of an AIX Administrator  

Download this Tech Advisor from POWER IT Pro and learn practical, real-world information about AIX administration. Christian Pruett shares all the things he wishes he had known about AIX before becoming an admin in his ebook Secrets of an AIX Administrator....More
Dec. 3, 2012
Datasheet

AIX Security  

IBM i has extremely robust intrinsic security, and Linux, although much less secure than either AIX or IBM i, has many more eyes watching for problems. But AIX has some significant corner cases where security can be breached if you're not careful....More