TSM Administration Hints

TSM Command line or GUI?
Setting up an Enterprise Server
Compression, yes/no
Compression Statistics
Selective Compression by Directory
Using Cache on Disk Storage Pools
Using ATA Disk Storage Pools
Querying TSM Options
Password handling in Unix shell scripts
Stopping a UNIX client scheduler
Directing command output to a file
Controlling the amount of data going to the TSM scheduling and error logs
Suppressing TSM information on queries
Querying data transfer rates
Encrypting the backup data
Accessing 2 servers from 1 client
Querying nodes associated with a schedule
Synchronising your TSM server with the OS
Canceling sessions and processes

TSM command line or GUI?

Which is best, the TSM command line or the TSM GUI? Now there's a question that can cause some discussion. I personally believe that both have their place, depending in what you are doing.

I much prefer the GUI when working with a TSM server, but be aware that some sites might not have a working GUI for some older legacy servers, so you need to be prepared to use a command line. You also need to use a command line if you are working with 'cut down' TSM servers like Storage Agents.
But first, why do I prefer the GUI? Simply because when you are defining objects like clients a lot of values are defaulted, client compression for instance. If you use a command line you need to be aware of what all the defaults are so you can override them. If you use the GUI you can see the default values on the screen and then know what you need to change.
To start a TSM server command line in AIX, you use the dsmadmc command with an optional servername. If you are logged into a client that is running a Storage Agent called ClientA_Sta you would log into it the command

dsmadmc -se=ClientA_Sta

and then you can run a limited commandset from the Agent's command line.
You can also use the command line to define complex schedules as described in the Backup section.

On the client side I prefer a command line simply because you get much more control over backups and restores. You start a command line on most operating systems by just typing in 'dsmc', although it can be difficult to find a command prompt on Windows systems. If your client has multiple server stanzas, then you can invoke each stanza with the server name parameter. For example if you define a stanza for oracle RMAN and use a servername of oracle_backup in it, then you would start a client TSM session like this.

dsmc -se=oracle_backup

back to top

Setting up an Enterprise Server

Controlling and managing several TSM servers with hundreds of clients can be a headache, if only when working out which client is managed by which server. TSM offers the Enterprise Configuration facility to make this easier. This lets you create and distribute settings and configurations from one configuration TSM server to several managed TSM servers.

You start with the TSM server that is going to be the configuration server.

From the Object view, select Server - Server Groups, then 'Define New Server Group' from the drop down menu. Give this group a meaningful name and description, add it, then select 'Server Group Members' and add the TSM servers that you want to be associated with this group.

On that server GUI, open Operational View; Configuration Manager Operations option and select 'Establish this server as a configuration manager', set the configuration manager drop down window to 'ON' and press the Finish button (or use console command SET CONFIGMANAGER ON)

Next, you need to select the 'managed server operations' menu The configuration manager works on profiles, which are used to collect the objects that are to be managed together, so they can be managed with a single command.

You select the 'define a new Configuration Profile' option from the drop down menu, then you will be presented with a list of objects that can be managed by this profile. The available objects are:

• Managed administrators
• Managed policy domains
• Managed command schedules
• Managed scripts
• Managed option sets
• Managed server definitions
• Managed server groups
• Subscribers

You can then define which of these objects will be managed centrally. However it is not as simple as this, as, for example, if you decide to centrally manage all your command schedules, then they need to be identical on every server in the group. Installing an Enterprise Configuration is a good opportunity to clean up and standardise your TSM estate

Once you get the configuration manager setup, you then need to log onto each of your managed servers, and subscribe each one to the profile that you just created. Suppose you called it WINDOWS_PROD and your Configuration Manager server was called CONF_MAN, then you would issued the command

define subscription WINDOWS_PROD server=CONF_MAN

What does this all mean?

Suppose that you defined a server group called WINDOWS that contains all your Windows TSM servers. You can now send commands to all your Windows TSM servers by prefixing your command with WINDOWS:

 
WINDOWS: Q DB

WINDOWS: upd stg cartpool reclaim=40

Suppose you defined your WINDOWS_PROD profile to control administrators, client schedules and admin schedules. They are all centrally managed by the CONF_MAN server now and you can only make changes to your managed servers by applying the updates to CONF_MAN then distributing the changes out to the managed servers by issuing the command

NOTIFY SUBSCRIBERS PROFILE=* 

From the CONF_MAN server. This both simplifies management and maintains consistency across all TSM servers.

back to top

To compress or not to compress?

Client compression will use up CPU cycles on your client server. However, once the data is compressed, it will use less Network resource and will also reduce the I/O pressure on your TSM server. This used to be a big plus point, in the days of restricted bandwidth. However, these days, with gigabit ethernet, its probable that the CPU consumption on the client actually outweighs any benefit you might get from better network usage.
If your data is a good compression candidate (big Oracle databases can compress down to 20% of original size) then you might get a benefit from client compression. If your clients are CPU constrained, and you have a good network, then your backups will probably run slower with client compression.
You should also not use compression if your clients support file compression. If compression would make a file bigger than it was before, which happens if a file is already compressed, then the file transfer will fail and will be retried without compression. If this happens for lots of files you will suffer a real performance hit. You then have three options: don't use compression, set the COMPRESSALWAYS parameter to on, then a file will be compressed and transmitted even it if grows with compression, or just exclude problem file types from compression with EXCLUDE.COMPRESSION statements as explained below.
My impression is that most people run with client compression off these days.

The only definitive answer seems to be 'suck it and see', trying compression on all clients of a given type and monitoring data transfer rates.

back to top

Compression statistics

How do you get compression statistics for a given backup session?

From the Client side, when the backup completes, look at the SCHEDLOG (normally dsmsched.log) on the client and page down to the last paragraph. This will give (among other stuff) compression statistics for the backup in the line 'Objects compressed by n %'

From the server side, issue command 'q actlog' and look for the lines starting ANE4968I. These give you compression stats for each client.

Note that when you look at space occupied by backups, you see two numbers, %utilised, and %reclaimable. These two numbers do not add to 100%. This is because the reclaimable space includes 'holes' within Aggregates, whereas utilised space considers Aggregates as intact units.

back to top

Selective Compression by Directory

If you want to compress some parts of a filespace but not others, maybe because some directories contain large files which should compress well, then try the following in the dsm.opt file

COMPRESSION ON
exclude.compression */.../*
include.compression */.../compressed_dir/.../*

back to top

Using Cache on Disk Storage Pools

It is possible to speed up recoveries by keeping a backup copy on disk, after it has been migrated to tape. This is called disk caching. By default, caching is disabled on storage pools so the backups on disk are deleted as soon as they are migrated to tape. You need to enable disk cache by specifying CACHE=YES when you define or update a storage pool. Then the backup copy on disk will be kept until space is needed in the disk pool for new backups. Disk cache is useful for pools that have a high recovery rate.

The disadvantage of disk cache is that backups will take longer, as the backup operation has to clear space in the disk pool before it can copy a new backup to disk. Disk cache will also increase the size of the TSM database, as it needs to track two backup copies, one on disk and one one tape.

If you run a query storagepool command

 Q stgpool backuppool

You see the following (partial) result

 Storage      Estimated    Pct      Pct     
 Pool Name    Capacity     Util    Migr   
 -----------  ----------   -----   -----   
 BACKUPPOOL    274,277.0    80.0   40.0     

The pct Util (utilised space) includes the space used by any cached copies of files in the storage pool. The (Pct Migr (migratable space) does not include space occupied by cached copies of files.

back to top

Using ATA Disk Storage Pools

This process has been effectively replaced by Active Copy Storage pools, or by disk only virtual tape systems.

You need a fast disk cache to get your initial backups off your clients, but once its in your backup system, you want to be able to retrieve the data fast, but also store it cost effectively. You want to store smaller files in a big, cheap ATA disk pool, but keep large files on tape. Why? Because you can retrieve big files from tape quite quickly, but it takes a while to pull back a lot of small files.

Consider the following scenario. You have three storage pools that look like this:

 Storage            Device   Estimated    Pct    Pct     High  Low  Next Storage
 Pool Name    Class Name    Capacity    Util   Migr     Mig  Mig          Pool
 ----------   ----------  ----------     -----  -----  ---  ---   -----------
 FASTDASD      DISK            1000.0    10.0   00.0     90   10     ATADASD
 ATADASD        DISK        100000.0    67.6   67.6     95   80     TAPEPOOL
 TAPEPOOL       TAPE    48034821.3    54.6   00.0     90   70

The initial backup goes to the fast (SCSI or FC) disks. Migration then kicks in and clears the fast disks down. The ATADASD pool has a maxsize parameter set to 2 MB, so all files bigger than 2 MB are skipped and sent straight to tape. If the ATADASD pool hits 90% it also overflows to tape

There are issues with this idea.
If you ever have to restore your TSM database, part of that procedure is to audit any disk storage pool volumes. If you have a huge disk storage pool, this audit will take that much longer.
Migration is limited to one process per node, so the migration will be swapping between tape and disk for output. This could cause a lot of tape mounts.
Tapes are still cheaper to purchase and run than disk, though the difference is shrinking.

IBM do not recommend this approach as it is not the way TSM was intended to work. However there are people who use disk backup pools only, and claim it works fine.
The main issue IBM have is that there is no reclamation for random access storage pools, which means that aggregates of small files will not be rebuilt, and will not expire until every member of the aggregate expires. The disk will also become fragmented.

back to top

QUERYING TSM OPTIONS

If you want to verify your client is picking up the correct options file, you can query the TSM client options by using the undocumented console command SHOW OPT. This produces loads of output, and scrolling cannot be controlled, which might be a problem, especially if using RCONSOLE under Netware. IBM wrote this as an internal maintenance command, and don't support it.

back to top

Password handling in Unix shell scripts

How can you include a dsmadmc command in a UNIX shell scripts without advertising a name and password by including it in the script, i.e., 'dsmadmc -id=xxxxxx -pa=xxxxxx select ....'?

One way is to set up a 'password file', and have your shell script read it. You would do this by defining password and user variables, reading in the data from the file, then putting the variables in the command

  $pass=tail -1 /var/tmp/dsmaccess
  $user=head -1 /var/tmp/dsmaccess

  dsmadmc -id=$user -pa=$pass

You then protect the password file so only root can read it.

If you only want to run queries from your scripts, then another way is to define a TSM userid, lets call it QUERY which can only issue queries. You can then hardcode the userid and password in your scripts, as there is little security risk in others using it. The problem with this method is that if you have to change the 'QUERY' password, then you have to change all your scripts. Holding the info in a single file is a better option.

back to top

Stopping a UNIX client scheduler

How do you stop a client scheduler running on a UNIX box?

Issue the command

	ps -ef | grep dsm

Find the process number for the scheduler from the command output, then issue the command

	kill xxxx
	  or if that fails
	kill -9 xxxxx  

where xxxx was the process number

back to top

Saving command outputs

If you schedule a script to run on a TSM server, how do you save the output?

   place a        > file.name
 after the command
 i.e.
   q volume >  /tmp/tapevols 

in your script the output will be saved in the tapevols file.

Under UNIX, you can't do this from within TSM, you have to run the command externally as dsmc -pa=xxxx q volume > /filename.

If you want to use '> ' as comparator symbol don't put spaces around it, then it won't be considered a redirection command. i.e. a> 2 will report on values of 'a' greater than 2. a > 2 will try to redirect the output from the 'a' command to a file called 2, and will fail with a syntax error.

Redirecting output works with Netware depends on the TSM client level, as clients at TSM 5.3.2.0 client or higher use a dynamic C library, whereas older clients utilised a static SMS library named SMSUT.lib. Novell no longer supports this static library, which required TSM to switch to the dynamic C library at version 5.3.2

For 5.3.2.0 and higher TSM clients use the standard re-direction method;

  
  q backup data:/accounts/ > output.txt

For 5.3.1.x and lower TSM clients use the re-direction method;

 q backup data:/accounts/ (CLIB_OPT)/>output.txt

back to top

Suppressing TSM information on queries

If you want to run a query then feed it into a program or script, then you do not want all the TSM/IBM copyright information, the date and time. the session established message, and all the other information that comes at the start of a session. If your client is running TSM 5.2 or higher, you can suppress these messages by launching the admin command line interface with the new -DATAOnly=Yes option. You do not need a 5.2 server for this. This option will not suppress error messages.

back to top

Controlling the amount of data going to the TSM scheduling and error logs

The DMSMSCHED.log and the DSMERROR.log are usually the first point of call when investigating problems. They are usually found in the CLIENT/BA/ or BACLIENT/ directory. TSM will update both these files every time it runs a scheduled backup and will record every backed up file. The problem is that if they are not controlled, the logs will quickly become too big to manage.

You have two parameters in your dsm.opt file that control the data held in these files, schedlogretention and errorlogretention. The default values are schedlogretention N and errorlogretention N, which means never prune the logs. Other options are

  ERRORLOGRetention 7 D	

which means keep the errors for 7 days then discard them, or

 
  ERRORLOGRetention 7 S

which means after 7 days move the data to DSMERLOG.PRU. The schedlog retention syntax is the same. You can select how many days you want to keep your logs for. You can also add a QUIET parameter in your DMS.OPT file, which will suppress most of the messages, but this is not recommended as you lose most of your audit trail.

A further pair of parameters were introduced With the 5.3 baclient,

schedlogmax nn
errorlogmax nn 

This parameters cause the logs to wrap, so when they reach the end of the file, they start to overwrite the data at the beginning. The end of the current data is indicated by an 'END OF DATA' record. The nn value is the maximum size of the log in megabytes, with a range from 0 to 2047. 0 is the default and means do not wrap the log.

back to top

Querying data transfer rates

how do you find out yesterdays data transfer rate for client sessions?

Use the command -

	q ac begind=today-2 begint=23:59 endd=today-1 
	endt=23:59 originator=client 

obviously, you can manipulate the relative dates to get data from other days

back to top

Encrypting the backup data

It is generally considered that TSM backup data is secure, as it cannot be read without a copy of the database. However if you have a legal requirement for full data encryption then standard DES 56-bit encryption is available. When you turn on encryption, you will be prompted to create a unique key. Without this key, you won't be able to restore your data. It is very important that you keep a copy of this key someplace other than the computer that is being backed up. If you forgot the encryption key, then the data cannot be restored or retrieved under any circumstances.

To enable encryption you add an encryptkey parameter to the dsm.opt file on the client, and add include.encrypt and exclude.encrypt statements as required. TSM will not encrypt anything unless at least one include.encrypt statement is present.

The encryptkey options are -

encryptkey prompt 

With the prompt option you should see the following message every time you run a backup

User action is required, file requires an encryption key 

And you need to provide password twice

encryptkey save 

You should only see the password required prompt once, and the password is saved in the tsm.pwd file

The manual states that with the encryptkey option set to Prompt you will be prompted for the password on every backup or restore, but it in my experience it appears that TSM stores this password on the local client, probably in a file called tivinv/tsmbacnw.sig so you can then run further backups or restores from that client without having to specify a password and TSM encrypts or decrypts the data as required. If you delete that sig file, or presumably try to recover to a different client, then you will be given a selection screen with the following options
1 Prompt for password
2 Skip this file
3 Skip all encrypted files
4 Abort the restore

Taking option 1, you will be prompted for the encryption password twice, then the restore runs as normal.

back to top

Specifying 2 or more servers from 1 client

The first question is, why would you want to run several servers in the same client? The answer is that you typically do this when you want to handle different parts of you client data differently, maybe for databases or maybe for shared resources in client clusters. In this case you would define some virtual TSM servers in the same dsm.sys file.

On a Windows client, if you want to define TSM servers, and you want to be able to specify either server from a TSM client, add the following lines to the dsm.opt file

     servername s2 tcpserveraddress ip_address or domain_name

     dsmadmc -se=s2 etc

On an AIX client you would define a different dsm.opt file for each server, For example, suppose you want a basic client to backup the rootvg, an oracle client for database backups, and an HACMP client for the non-database data on the shared resource. You need three opt files which for example could be defined like this

dsm.opt  (basic client)
servername base_server

dsm_Oracle.opt
servername oracle_server

dsm_HACMP.opt
servername hacmp_server

Then in your dsm.sys file you would code

 servername        base_server
 tcpserveraddress  tsm_server
 schedlogname      tsm_base_server_schedlog
 errorlogname      tsm_base_server_errorlog  
 nodename          clientname_primary_node
 .. more parameters

 servername        oracle_server
 tcpserveraddress  tsm_server
 schedlogname      tsm_oracle_server_schedlog
 errorlogname      tsm_oracle_server_errorlog 
 nodename          clientname_oracle_node
 .. more parameters
 
 servername        hacmp_server
 tcpserveraddress  tsm_server
 schedlogname      tsm_hacmp_server_schedlog
 errorlogname      tsm_hacmp_server_errorlog 
 nodename          clientname_hacmp_node
 .. more parameters

Note that the tcpserveraddress is the same for each 'server' and is the dns name of the real tsm server. If you make each server stanza write to a different set of logs then that makes it easier to investigate issues. Each of the three nodenames is defined independently to the TSM server, so they can be scheduled independently. You would also define two symbolic links for extra dsmcads, so each stanza can be scheduled independently like this.

 ln -s dsmcad /tivoli/tsm/client/ba/bin/dsmcad_oracle -optfile=/tivoli/tsm/client/ba/bin/dsm_Oracle.opt
 ln -s dsmcad /tivoli/tsm/client/ba/bin/dsmcad_hacmp -optfile=/tivoli/tsm/client/ba/bin/dsm_HACMP.opt

back to top

Which nodes are associated with each schedule

The command syntax is 'query association domain_name schedule_name'. You can query all associations by using

 q assoc * * 

If you want to query a specific schedule, but do not know the domain, use

 q assoc * sched_name

back to top

Synchronising your TSM server with the OS

If your TSM server is out of step with your hosting server, possibly due to a daytime savings change, you can easily change TSM to match the OS server by entering the following command at the admin command line

ACCEPT DATE

back to top

Canceling sessions and processes

To cancel server processes like migration you need to know the process number, which you get with the Q PROCESS command. However note that if you cancel a migration session then a new one will start unless you also reset the pool thresholds.

CANCEL PROCESS process-number

To cancel tape mount requests use the command

CANCEL REQUEST request-number
CANCEL REQUEST ALL

To cancel active sessions you either need to know the session numbers, which you get with the Q SESSION command, or you can cancel all active sessions

CANCEL SESSION request-number

To prevent new sessions or processes from starting use

DISABLE SESSION client
DISABLE SESSION Server
DISABLE SESSION Admin

These commands just prevent new sessions from starting. All active session will run to completion unless you cancel them with the cancel command. The disable session server command will stop new server to server sessions from starting, it will not stop expiration or migration.

To do an emergency cancel of all sessions use the command

DISABLE SESSION ALL
CANCEL SESSION ALL

back to top

Copyright © Lascon Storage Ltd. 2000 to present date. By entering and using this site, you accept the conditions and limitations of use