Once you’ve installed and set up your TSM server, the next step is to get some clients working. Fortunately, configuring a TSM client is a much easier task than initially establishing the server.
Once you’ve installed and set up your Tivoli Storage Manager (TSM) server, as described in part 1 and part 2 of this series, the next step is to get some clients working. Fortunately, in terms of complexity, configuring a TSM client is a much easier task than initially establishing the server. However, there are some key configuration files that must be edited just right—otherwise you run the risk of making no backups at all or inadvertently expunging what you’ve saved off to disk or tape.
Client Setup with TSM
Just like with the TSM server, the first task to setting up a TSM client is to install the software. The TSM server packages available for download from IBM’s Passport Advantage website and the base media on CD usually will include the client runtimes. At a minimum, the installation will require a core binary fileset (such as tivoli.tsm.client.ba) and an API fileset (such as tivoli.tsm.client.api.64bit) to work correctly. They can be installed with the standard installp or geninstall commands, or by working through the SMIT interface.
Installing these filesets will create a directory tree under /usr/tivoli/tsm/client. In this structure, the software makes several subdirectories that contain the client binaries and executables, the TSM configuration files, and components for other software such as Oracle and DB2 to integrate TSM into their backup processes.
There are two key files within the TSM client directory tree that must be edited and configured for backups to function: the client options file and the client user options file. They're often be mistaken one for another, and there’s a certain degree of overlap that can happen between the two files in terms of options.
The purpose of the client options file, called dsm.sys, is to establish the nodename of the client, the TSM server to which backups will be made, and the communication method and port number for TSM traffic. The client options file also determines how to manage the passwords for managing backups. It’s a standard flat file and can be modified through a normal text editor such as vi. A sample dsm.sys file might include the following information:
This would tell TSM that the client system, client01, backs up to the TSM server tivoli01 via TCP/IP on port 1500 and saves the password locally so that after initial communication with the TSM server, the connections could happen automatically. The other option for the PASSWORDACCESS option is prompt, which requires admins or users to enter their password when communicating with the TSM server.
As you might recall from previous articles in this series, it’s possible to have multiple clients (nodes) defined in the dsm.sys file for various functions. For instance, in the past I’ve set up three nodes on some Oracle servers—one for normal OS files, one for RMAN backups, and one for cold database backups—because they were bound to different management classes on the TSM servers with different retention requirements. But, in order to manage these, there’s another configuration file that must be modified.
The client user options file, called dsm.opt, can be used to govern individual options for specific nodes or users. This file can be modified to handle customized options such as declaring which node is active for backup or recovery operations, addressing a specific domain, or looking for a customized list of which files and directories should be included or excluded from backups. It’s even possible to create several copies of this file and refer to them within the TSM client interface or the command line to access each node individually.
The Include/Exclude List
One of the most important topics pertaining to the TSM client is the include/exclude list. This customizable area can be used to selectively filter which files, directories, and file systems should or should not be sent over to the TSM server.
There are many ways to skin this proverbial cat, from integrating the list into the dsm.sys file to breaking it out into individual dsm.opt files to—my favorite—creating a separate include/exclude file altogether. This can be done by giving the dsm.opt file the INCLEXCL stanza and pointing to an individual file (I tend to name it /usr/tivoli/tsm/client/ba/bin/inclexcl.opt or something intuitive like that). I prefer this method because I like keeping my dsm.sys and dsm.opt files neat and clean.
The include/exclude list is unique in the way it operates. It’s processed from the bottom up, so the list of contents is written in what almost appears to be a counterintuitive way. It also accepts wildcards, search strings, and individual markers for sorting through what should or should not be backed up. However, it doesn’t traverse nested file systems well, so those should be broken out as much as possible.
Let’s take a look at a sample include/exclude list for reference:
In this case, processing from the bottom up, the very first thing that the system will do is to set a rule to exclude any core files from the server, no matter where they’re encountered. Then, it will exclude any subdirectories and contents within the /var file system. After that, it includes backups of the /oracle and /oracle/o01 file systems. It instructs the system to also back up the /home file system, but to omit anything from /home/test. And, finally, it sets a blanket rule to exclude any and all remaining directories.
The TSM Client Interface
The command to interact with the client is /usr/tivoli/tsm/client/ba/bin/dsmc. This command, similar to the dsmadmc command on the TSM server, can either have command line options passed into it (e.g., tossing in an –optfile flag to specify a unique dsm.opt file) or can be run interactively. The commands also have a SQL-like feel to them, relying less on flags and more on words (or abbreviations of words) to execute commands.
The simplest command, and the one that I’d wager is run more often than any other, is the dsmc i command, which specifies that the client is to run an incremental backup using the parameters in the default dsm.sys and dsm.opt files. This can be run in the foreground through the command line, scheduled through the crontab (my preference), or use the native TSM scheduler (which requires setting up a service in the /etc/inittab file). Once the backup has finished running, a summary will be displayed indicating how many files were backed up, the overall speed, and duration of the backup.
The initial incremental backup will always take the longest because it will examine all files specified in the include/exclude list and grab everything that's applicable. It’s also important to remember that the quantity of inactive files stored on the TSM server is dependent on a combination of how often the data being backed up changes and how often the dsmc i command is run. Remember, inactive versions aren’t time-dependent (e.g., daily), and mismanaging the command can squash all inactive versions of a file from history within one day.
Following this command, the next common one is the dsmc rest command to restore files. This is where I like the versatility of TSM, because it’s possible to enter in several options, including subdir=yes, pick, and ina to give a menu-driven option for selecting complete sets of subdirectories, picking specific files out of a wildcard search, and screening through inactive files for a specific version of a file that might have been erased long ago (provided it hasn’t been expunged through the TSM server’s retention rules for number and age of inactive files).
Now that your TSM server and client are communicating and backups can be made, the next phase of the process is to create an ongoing schedule to manage the resources, send tapes offsite, and keep things moving. In my next article, I’ll conclude this series by focusing on the day-to-day management tasks of TSM.