Hints an tips on how to administer a TSM server
 |
 |
 |
|
 |
|
 |
TSM Administration Hints
TSM Command line or GUI?
Using the dsmcutil command
Setting up an Enterprise Server
Which IP ports does TSM use?
Compression, yes/no
Compression Statistics
Selective Compression by Directory
How TSM allocates space on disk and tape
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
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
Investigating install problems
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. However, since the old style TSM GUI is no longer supported in TSM versions 6.x your only option, apart from the command line, is that horrendous Admin Center.
UNIX Server Command Line
To start a TSM server command line in AIX, you use the dsmadmc command with an optional servername. The command line is useful if you want to do bulk upgrades, as you can then do them with a script. For example, if you want to register 10 new nodes, rather than go through the tedium of adding 10 nodes through a panel, it is much easier to set this up as 10 commands within a UNIX script, then just execute the script. A typical script could look like
dsmadmc -se=servername -id=youruserid -pa=yourpassword register node nodename nodepassword passe=9999 con=\"This server contact details\" do=policy-set clo=cloptset userid=none comp=no archdel=no backdel=no etc.
you obviously need to substitute your own values for the parameters, and note how special characters like quotes are escaped out with a forward slash. The command is also split over 3 lines to make it readable, but it is actually all one line.
Other dsmadmc options
The command can also be very useful if you want to start a TSM server up in different modes. for example, if you want to run some queries that you want to feed into an excel spreadsheet or maybe programs, and you do not want the screen titles displayed you would use the following. -commad means comma delimited output, the dataonly switch suppresses the headers.
dsmadmc -se=servername -dataonly=yes -comma
an alternate option is -tab for tab delimited. These commands can be usefully argumented with the -out parameter, which writes the console output into an external file. For example if you start a server session as below, then the output of any commands you issue will be placed in sqlout.txt
dsmadmc -se=servername -dataonly=yes -comma -out="c:\program files\tivoli\tsm\sqlout.txt"
Two other useful options are
dsmadmc -con dsmadmc -mount
The first one starts a server session in console mode, so all the console messages
automatically scroll past your terminal. This is useful if you are waiting
for a process to complete, as it saves you from keep typing q actlog
or q pr commands.
The second option is similar, but instead of displaying all the console messages, it just displays tape mount messages. This one was intended for a media librarian that had to mount tapes manually
dsmadmc with Storage Agents
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
To get out of the Storage Agent type 'quit'. If you type 'halt', you will stop the storage agent then exit.
Logging into a remote TSM server
With Windows servers, you can log into any remote TSM server, provided you have the dsmadmc command code loaded with your TSM client, and provided your firewall rules permit remote access. If you have a remote server on a Windows box with IP address 99.245.24.123 and with a DNS name of WSTSM01, you can start a session by navigating to \program files\tivoli\tsm\baclient and running either
dsmadmc -tcps=99.245.24.123 or dsmadmc -tcps=WSTSM01
If you get a message like "dsmadmc not found" then you've got a basic client install and you need to install the server management component.
This works on the IP address of the Windows box that is hosting TSM. What if you are running more than one TSM server on that box? By default you will get TSM Server1. To reach the other servers you need to add a -tcpp switch that specifies the port of the other server
dsmadmc -tcps=WSTSM01 -tcpp=1502
Client command line or Gui?
On the client side I used to prefer a command line simply because you get much more control over backups and restores. In fact on an AIX machine, the command line is probably the best option. 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
On Windows clients, I find the GUI by far the best for doing restores, and probably the command line for doing anything else, but it's all a matter of personal taste.
Using the dsmcutil command
You can use the dsmcutil command to add and remove schedules from TSM, - much faster than using the DSM GUI Wizard. To define a standard node, use
dsmcutil inst /name:"TSM Scheduler Service - Z095XFSU1" /optfile:"C:\Program Files\Tivoli\TSM\baclient\dsm.opt" /node:z095XFSU1 /password:xxxx /autostart:yes /startnow:yes
The command should go to the opt file and get the sched and error log file names
To remove a schedule service, use
dsmcutil remove /name:"Tivoli Integrated Portal - TIPProfile-Port-16310"
you can also work with services using the Windows sc.exe program. For example,
sc query | FIND "TSM" /I
sc query lists all Services, then pipes the result into a find command to just list out the services that start with TSM, the /I switch means ignore case. Once you get the service name from the query command, you can use other sc commands on that service, for example
sc start 'Service-name' sc stop 'service-name' sc delete 'service-name'
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.
Which IP ports does TSM need open on a firewall?
This is a list of listener ports that various Tivoli Storage Manager products expect other hosts to connect to, and may be useful in firewall setup. This applies to Tivoli Storage Manager version 6.2.2 and higher
Tivoli Storage Manager server configurable listener ports
Port name Default Comments --------- ------- ----- TCPPORT 1500 Inbound client, server, admin TCPADMINPORT 1500 Same as TCPPORT unless defined SSLTCPPORT none Used for client SSL comm if defined SSLTCPADMINPORT none Admin client SSL comm if defined NDMPCONTROLPORT 10000 Inbound NDMP control connections NDMPPORTRANGE range NDMP initiated backups
Operating system ports which the Tivoli Storage Manager server might use
Port type Default Notes
--------- ------- -----
ssh 22 Only used for graphical wizard during initial config.
Not necessary if manual config is done.
acsls portmapper It is possible to define static ports
smb 45 Windows: Server Message Block
Tivoli Storage Manager client configurable listener ports
Port name Default Notes
--------- ------- -----
TCPCLIENTPORT 1501 Classic scheduler listener for PROMPTED
(Note: Not common. Use of the dsmcad is recommended.)
WEBPORTS none(*) dsmcad: (schedule listener agent listener)
HTTPPORT 1581 webclient listener
(*)WEBPORTS: If a firewall is used with the dsmcad scheduler and/or webclient, the WEBPORTS option MUST be manually set.
Tivoli Storage Manager Administration Center version 6.1 listens on http ports 9043 or 9044.
Tivoli Storage Manager Administration Center version 6.2 listens on http port 16310 and https port 16316. Connecting to 16310 simply redirects the connection to the https port.
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.
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.
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/.../*
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.
Storage Pool migration processing triggers on the "Pct Migr" value not the "Pct Util" value as found in the query storage pool output. This can cause confusion as a Storage Pool can appear to be full when most of the data is cache data. You may then expect automatic migration processes to run, but they will not run until the "Pct Migr" threshold is reached.
How TSM allocates space on disk and tape
The amount of physical space used by TSM when saving files will depend on the blocksize used. A small file will always use a minimum of a full block to store the data. Random access disk pools use a 4K block size, Sequential access files on both disk and tape use 256K blocks, so these are the mimumum file sizes. This means that a 2K file will occupy 4K on a disk pool, then 256K when it gets migrated to tape. Quote from IBM, "This will be true for each object saved". Any object bigger than 4K will use a whole number of 4K blocks, for example a 21K object will use 6*4K blocks, or 24K of disk space. The unused space at tghe end of the block cannot be used for anything else.
LTO tapes have a minimum space requirement on top of this called a dataset space. For LTO1 and LTO2 this is approximately 400KB and for LTO3 and LTO4, it is approximately 1.6MB. Data is written out to LTO when a transaction ends, but this does not necessarily correspond to a single object, but would be a concatention of all the objects written in that transaction. So if a single 5K object is written to an LTO4 tape, that object will use the mimumum dataset size of 1.6MB on the tape. However if a number of objects totalling 2.4MB are streamed to the tape, for example as part of migration, then TSM will send them in 7*256K blocks and the LTO dataset would use 1,792K, the size of those 7 blocks.
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.
QUERYING TSM OPTIONS
The SHOW command below still works, but now it's official, you can just use a 'query option' command instead
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.
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.
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. The kill -9 is a dirty kill and should just be used as a last resort.
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
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.
Querying data transfer rates
how do you find out yesterdays data transfer rate for client sessions?
Use the command - This will display all client messages, not just data transfer messages
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
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.
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
you then have a 'primary' server which you pick up by default, and you can invoke the secondary server using
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
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
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
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
Investigating install problems
If you have problems when installing either a TSM server or the Admin centre, both installs create a log.zip file that can be used to work out what went wrong. log.zip contains a collection of log files for the TSM server, the DB2 Database and the Admin Centre. The location of these files depends on the operating system, and can be found in :
Windows C:\IBM\AC\logs.zip ...Admin center logs C:\Program Files\Tivoli\TSM\logs.zip ...TSM server logs Unix/Linux : /var/tivoli/tsm/logs.zip