Skip over navigation

Frequently Asked Question (FAQ) for TSM

(click each one for details)

Knowledge Base Documentaion Link for Crash Plan (04/21/2014)

Read the KB documentation for a detailed explanation of Crash Plan. Crash Plan

Knowledge Base Documentation link for TSM (04/21/2014)

Read the KB TSM documentation for a detailed explanation of TSM and the ins and outs of managing client data here.

Tivoli Storage Manager was originally designed as a server backup and recovery support application, and will continue to be used at Princeton for Department Projects and Infrastructure management.

Crash Plan will be available to students and faculty for workstations, laptops, and mobile device backups. New backups should install Crash Plan.

When do the backups run?

The standard backup window for TSM is 6:30pm-6:30am daily. When clients are first registered in TSM, this is the default time.

However, many clients run during the day (upon request), clients in the DeSC program run a specific window early in the evenings, and some clients, such as database clients, do not have scheduled backups, or Bulk backups (upon request) will run once a week. Note that TSM backs up incrementally - this means only files which have changed on a client since the last backup will be picked up. Some files will never change, and so TSM will never back them up twice.
 

"Failure 21" or "Error '2' on S Registry Key" on Windows 7+ scheduler (04/21/2014)

This is an issue occurring on Windows 7+ during configuration of the TSM scheduler. (Note that this happens more often on Dell).

Sometimes when attempting to define the scheduler and journal service, "Error 21, the service exists" or a failure "Error 2 on the 'S' Registry Key' pops up.

Two scenarios: 1) Looking in the Services, TSM Client Scheduler and TSM Journal Service are present, BUT will not start - because they do not actually exist. 2) There is actually no scheduler in the Services, but during configuration, it continues to insist there is a scheduler.

The fix for Scenario 1 is to remove the service using the TSM utility command "dsmcutil". Open a command window (cmd.exe):

c:\> cd 'c:\program files\tivoli\tsm\baclient\'

Verify the names of the scheduler and the journal service for removal:

c:...baclient\> dsmcutil list

c:...baclient\> dsmcutil remove /name:"TSM Client Scheduler"

c:...baclient\> dsmcutil remove /name:"TSM Journal Service"

Refresh the Services window, the two scheduler services should now be gone.

Next, restart the client. Again, log on as Admin, open a command window:

c:\> C:

c:\> net stop McAfeeFramework

c:\> net stop McShield

c:\> cd 'c:\program files\tivoli\tsm\baclient\'

c:...baclient\> dsmcutil install scheduler

/name:"TSM Client Scheduler"

/node:<nodename> /password:<password> /optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt" /schedlogname:"c:\program files\tivoli\tsm\baclient\dsmsched.log" /errorlogname:"c:\program files\tivoli\tsm\baclient\dsmerror.log" /autostart:yes

c:...baclient\> dsmcutil install journal

IF THE CLIENT CONTINUES TO INSIST THE SCHEDULER EXISTS name the scheduler slightly differently (NOTE: use double quotes when listing the options!):

c:...baclient\> dsmcutil install scheduler /name:"Tivoli Client Scheduler" /node:<nodename> /password:<password> /optfile:"c:\program files\tivoli\tsm\baclient\dsm.opt" /schedlogname:"c:\program files\tivoli\tsm\baclient\dsmsched.log" /errorlogname:"c:\program files\tivoli\tsm\baclient\dsmerror.log" /autostart:yes

c:...baclient\> dsmcutil install journal

Restart the client one more time, and review the services. The now-defunct TSM Client Scheduler will appear - remove it.

How do I configure the client scheduler? [10/18/2011]

The client schedule is controlled by TSM on the server side, not the client side, BUT a scheduler is configured on the client side and this scheduler must be active for the backup to begin.

The windows scheduler is defined using the configuration link on the TSM Administration page. Mac instructions are found there as well. Unix and Linux client files are defined similarly to Macs.

A scheduler uses this basic information in the dsm.opt or dsm.sys files on the client. The basic information is the Node (client) name, the communication method, TCPIP, the Port for the server connection, and the network servername.

NODENAME   JOHNDOE
PASSWORDACCESS GENERATE
   COMMMethod         TCPip
   TCPPort            1601
   TCPServeraddress   tsm1.princeton.edu

Additionally, specific options are defined in this file for include and exclude files, as well as data streaming. Any changes to the dsm.opt or dsm.sys files requires a re-start of the TSM scheduler to pick up changes. There is also a domain-specific option set on the TSM server side, which determines times of backup as well as setting certain backup controls.

When the scheduler is configured properly on the client side, every 12 hours TSM runs a "heartbeat" check to verify the client is ready, and writes the information to the dsmsched.log on the client side:

05/03/2011 11:57:19   Server date/time: 05/03/2011 12:08:25  Last access: 05/03/2011 12:08:04

05/03/2011 11:57:19 --- SCHEDULEREC QUERY BEGIN
05/03/2011 11:57:19 --- SCHEDULEREC QUERY END
05/03/2011 11:57:19 Next operation scheduled:
05/03/2011 11:57:19 ------------------------------------------------------------
05/03/2011 11:57:19 Schedule Name:         1205
05/03/2011 11:57:19 Action:                Incremental
05/03/2011 11:57:19 Objects:              
05/03/2011 11:57:19 Options:              
05/03/2011 11:57:19 Server Window Start:   12:05:00 on 05/04/2011
05/03/2011 11:57:19 ------------------------------------------------------------
05/03/2011 11:57:19 Schedule will be refreshed in 12 hours.

This shows the next time the schedule "1205" will back up JOHNDOE is 05/04 at 12:05pm, and this was verified on 05/03 at 11:57am, following the backup completion. Be aware of the time disparity - the server time was 12:08pm, the local client time was 11:57am, don't be confused by this, the important thing is the next backup is scheduled!

Note that the client does not have to be active when the backup runs - users do not have to be logged on - but the power must be on, and the scheduler must be running.

How do I change the scheduled backup time? [10/18/2011]

The standard backup window is 6:30pm-6:30am, this is the default defined when the client is first registered, and about 75% of the clients currently backing up to TSM run during these hours.

But some clients do not run in this window, e.g., laptops - which are usually off-campus at night - or specific project workstations - which run heavy processing at night - may require a different time slot. Many laptop users back up at noon, Mon-Fri, certain project run only on weekends, etc.

To change your scheduled backup, call the Help Desk or open an OPM ticket by sending a message to tsm@princeton.edu, and ask what time slots can be applied.

How do I change the password?

If you are the administrator to the client, you can change it yourself by going to http://tsm.princeton.edu, click "Maintain" and enter your network ID. Update the client you wish to change the password. After updating, count to 15, and try the TSM client with the new password.

How do I change the financial account for a TSM client?

Complete and Bulk backups are charged to various grant accounts all over Princeton, which periodically change. The data storage is maintained indefinitely so long as the account is valid. When the account expires, send an email to tsm@princeton.edu with the new account. If there is no need to maintain the data, send a message to tsm@princeton.edu to delete the TSM client.

How do I add/remove contacts from the TSM client control?

To change a ownership for a TSM client, open http://tsm.princeton.edu, click "Maintain", and enter your network ID.

Be careful here: do not remove yourself from the access list before adding other users, you will lose all access! Be sure to make the additions before removing your ID!

For each update, you (and the other owners) will receive two confirmations from TSM, the first adding the new person, the second removing your ID.

If you have a large number of clients (20 or more) which require ownership changes, email tsm@princeton.edu with the client names and the new user to be added, and you will be notified when the batch job changes (you will also receive emails from TSM)

How do I change the frequency of the TSM reports?

The default is a daily report, but especially when you "own" many clients, this can become so much junk - go to http://tsm.princeton.edu, click "Maintain" and enter your network ID. This is a blanket change, it is not possible to change the frequency of reports for only one client.

How do I read the TSM reports?

Owner: youyouyou@princeton.edu

*
*  Computer: CLIENT (WinNT, TSM2, 4 days, 17.2 GB)
*
*    Backup Date/Time  Filespace/Disk Name
*    ================  ===================================
*    11/04/2010 00:06  \\client\c$
*    07/15/2009 04:53  \\client\d$
*    10/06/2010 01:22  \\client\e$
*

You are the owner of "CLIENT"
The o/s is WinNT
The TSM server is TSM2
The last time TSM was able to register a heartbeat for the client was 4 days ago
The client has 17G of data in TSM storage *
The last time the C drive was backed up was Nov 4, 2010
The last time the D drive was backed up was July 15, 2009
The last time the E drive was backed up was Oct 6, 2010

* Most clients don't back up program files or system o/s files. On the client side, it may show 25G of a hard disk is used, so if TSM only backs up 17G, that is just data, the rest is programs which can be re-installed.

Often laptops show an extended number of days inactive, because they go off-campus and are not in regular communication with TSM. Also, users may turn off their machines instead of logging off, and the TSM server cannot tell what is the status of this client until it is powered on. Remote users can run backups, but a full backup it is not recommended when off-site! An off-campus backup is terribly SLOW, what would take 20 minutes on-campus can take 20 hours (not an exaggeration!). It is better for a user to bring a laptop in regularly, and run a local backup. If a client must be off-campus for an extended period, the TSM GUI can be opened, and a file-specific or folder-specific backup can be run ad hoc.

What does an "Incomplete!" mean for a backup? [10/18/2011]

TSM runs incremental backups - a primary backup is run, and then as files change, they are updated. The average change to data on a client (this is an IBM statistic) is 3%, and almost always to the same files.

By this logic, the first time a backup runs for a client is the longest backup time, and depending on the size of the client, it can sometimes take 1-2 days to complete the first backup. Subsequent incremental backups may take only minutes - sometimes only seconds!

TSM updates client information using the scheduler, and updates filespace information with the scheduled job: if a client is not in daily communication, the "inactive" flag for the client pops up with TSM support, and if the client is not backing up data via the TSM scheduler, the filespace information is not being updated. The regular reports showing "Incomplete!" can be unsettling if the user does not understand what it means.

If the user is manually running backups, the TSM support staff should be notified of this fact - even though the client is connecting daily, if the filespace shows it has not connected for six months, or that it has never completed the backup, the user may be asked (repeatedly) if help is needed to correct their connection.

If the standard 6:30pm schedule is not proactical for use, send a request to tsm@princeton.edu to change the backup time: a simple change of schedule can make all the difference!

How can I tell what data has backed up?

The dsmsched.log and dsmerror.log files are both on the clients, and they are the best source for details of backup, what went across, what failed, when the next backup is scheduled. Errors are embedded in the dsmsched.log along with all the activity, but they are specifically written to the dsmerror.log. The dsmerror.log is the best source for failure patterns.

How do I restore data to the TSM client? [05/04/2011]

Data can be restored from a file, a folder, or a complete drive, using the TSM GUI or a command line, depending on preference. You

must

have administrative privileges to a client in order to manage a restore. If you are not the administrator, call your local SCAD or the help desk.

If you are the administrator, on Windows or a Mac, open the GUI (admin interface), select "restore" drill down to the file or folder to be restored, and begin. Options to restore to a new location or a prior version can be selected.

When using a command line, the syntax is similar for all operating systems. Connect to the local client and query for the information before restoring:

Query the filespaces:

tsm> q fi
  #    Last Incr Date              Type     File Space Name
---    --------------                    -------    -----------------------
  1   05/03/2011 12:08:25   EXT3    /          
  2   05/03/2011 12:08:25   EXT3    /boot      

On this client, there is a root directory and a /boot directory

Query for the backup of a directory under the root filespace:

tsm> q backup /*
Size                 Backup Date                Mgmt Class   A/I File
------                ----------------------------  -----------------  ---  ----
4,096  B  10/01/2011 12:08:18             DEFAULT    A   /
4,096  B  12/02/2009 12:20:33            DEFAULT    A   /home

tsm> q backup /home/*
Size                 Backup Date                Mgmt Class   A/I File
------                ----------------------------  -----------------  ---  ----
4,096  B  12/02/2009 12:20:44            DEFAULT    A   /home/johndoe

tsm> q backup /home/johndoe/*
Size                 Backup Date                Mgmt Class   A/I File
------                ----------------------------  -----------------  ---  ----
4,096  B  10/11/2011 12:09:39          DEFAULT    A   /home/johndoe/DATA
4,096  B  02/04/2010 13:40:42           DEFAULT    A   /home/johndoe/WORKSTUFF

tsm> q backup /home/johndoe/DATA/*

Size                 Backup Date                Mgmt Class   A/I File
------                ----------------------------  -----------------  ---  ----
2,526,241  B  03/26/2011 12:08:18   DEFAULT      A    /home/johndoe/DATA/D00440.txt
     11,743  B  03/26/2011 12:08:18   DEFAULT      A    /home/johndoe/DATA/D00628.txt

Restore one of the files in the directory:

tsm> restore /home/johndoe/DATA/D00440.txt

For a full list of options, choosing inactive versions, targeting, etc., enter "h restore" at the command line and the syntax will be displayed. Or send an email to tsm@princeton.edu and we will find the specific commands you want to use.

How do I restore data to a different TSM client? [06/08/2011]

To restore from one client to another, you must know the Source servername and the password. If you are not the owner of the Source, it is possible for the TSM administrator to update the client password, but permission should be asked of the Source Owner.

On the target client, create an alternate options file:

c:\program files\tivoli\tsm\baclient\> copy dsm.opt dsm-<sourcenode>.opt

Edit the options file to match the new alternate client:

nodename <sourcenode>
servername <server>.princeton.edu
tcpport <port>

Then use the alternate options file to access:

c:\program files\tivoli\tsm\baclient\> dsm -optfile=dsm-<sourcenode>.opt

This will open up the TSM client interface, accessing the alternate data, which when restored will land on the current client.

For Macs, Linux, and Unix, edit dsm.sys, add the following lines:

(Mac): Library/Preferences/Tivoli Storage Manager/> vi dsm.sys

(Linux): /opt/tivoli/tsm/client/ba/bin/> vi dsm.sys

(Unix): /usr/tivoli/tsm/client/ba/bin/> vi dsm.sys

servername  <sourcenode>
NODENAME  <sourcenode>
PASSWORDACCESS GENERATE
   COMMMethod         TCPip
   TCPPort            <port> for sourcenode
   TCPServeraddress   <tsm#>.princeton.edu

/Library/Preferences/Tivoli Storage Manager/> dsm -se=<sourcenode>

/opt/tivoli/tsm/client/ba/bin/> dsm -se=<sourcenode>

/usr/tivoli/tsm/client/ba/bin/> dsm -se=<sourcenode>

Can I change the operating system of a client?

If a user wishes to retain the same name of a client, but is changing o/s, it is possible to retain the old data for a protracted period of time, but the data may not be directly accessible on the new client. If this is acceptable, REMOVE THE SCHEDULER from the old client completely, install TSM on the new client, configure the scheduler, and back it up. The new data will come across in different filespaces on the server side, and TSM will update the o/s seamlessly.

Can I restore data from one operating system to another?

For the most part, this is not possible.

However, most applications have conversion capabilities, so what is possible is to restore the data to similar o/s, copy it to the client with the different o/s, and convert the file using the application engine.

Be aware that simple files - text files, and basic documents - will convert easily, but art, fonts, and links can sometimes get clobbered! Review the converted files!

What is the storage policy?

Data is retained for 30 days, guaranteed, but only up to four copies of a file are maintained in TSM. This means if a backup runs every single night on a client, and there is a file which changes on a daily basis, only the last four days of that file are available for restore; thus, if a restore is required from that file from 10 days ago, the user will be disappointed. However, if the file only changes once a week, that version of the file will be marked "inactive", but older versions are available for a longer historical period.

A word of caution: if a file is deleted from a client and has not been updated (or backed up) for over 30 days, that file will only be available in TSM until the next expiration runs! However, if the file was updated recently, but was deleted by the user, the file will be retained up to 30 days - so if a file backed up seven days  previously and is deleted from the client, it will be still available in TSM for an additional 23 days.

How long is inactive data retained in TSM? [01/12/2012]

TSM clients should be in communication regularly with the servers, and data should be backed up at least once a month for TSM to be of any use to the user. When a client is out of contact for a protracted time, the data may be protected in TSM, but it can become seriously obsolete.

There are exceptions, of course, students go away for the summer, sometimes they spend a year abroad in a study program, and while they are away, their laptops remain idle. Professors go on sabbatical, sometimes they teach elsewhere for a semester or two.

During this time, TSM support should be aware the client is going to be inactive, because the stated retention policy is 30 days. This does not mean the data is going to be deleted from the system, it means it's reliability can only be guaranteed for 30 days!

Before leaving for an extended period of time, send a message to tsm@princeton.edu, include the expected length of absence. In absences over 90 days, the client may be renamed: "JohnDoe" would become "HOLD_365days_JohnDoe", and this will leave no question that the data for JohnDoe is going to be out of communication with TSM for a year.

At other times, a user may replace their client, and often the client (this is a Mac Address thing) gets renamed, so the fresher backup will create a second file in the backup database, all the same data, but kept in a newer, fresher state of being. Periodically, TSM support will purge this old data (with notification!).

There is a difference between "inactive" clients and "inactive files":

  • An inactive client is not in contact with TSM at all. The client may be powered off completely, the scheduler may have been turned off but the client is still running, or the client may have been surplused
  • Inactive files are parts of the backup which may not be used often or may even no longer be necessary.
    - If the backup type changes, for instance, from a Personal backup to a DeSC backup, only the c:\ drive user files are included in DeSC, so other disks - a D, G, or other drives - are no longer of value
    - Alternately, as mentioned, if a client is renamed, the old files will age as the new one backs up. In cases such as these, the extra data expires after 30 days

Of note:

If the client is having communication issues, SCADs and software support should get involved to keep the client (and the data) active. Bottom line - make sure the client is in communication with TSM! (look at the dsmsched.log, or check to be certain the scheduler is running!). Call the Help Desk if there is a question about what kind of support is available.

If inactive files are no longer necessary, their removal from TSM will not affect the client connection or the active files.

If a client is inactive for 180 days or more, and no hold has been placed on it, there will be a question if the data is no longer necessary. SCADs and department heads will be asked, and if they respond there is no value, the data is purged and the client removed from TSM.

Also - the complete deletion of a TSM client from the TSM server will not have a negative effect on the actual client, it will only mean there is no longer a means for Princeton OIT to back up the data on that client.

What are the backup categories [04/21/2014]

Crash Plan - Code 42's backup application software, Crash Plan is being made available to students, faculty, and staff across the Princeton Campus as of April, 2014. New clients are being directed to install Crash Plan. Infrastructure servers and Project Servers will continue to use TSM.

Complete - With the implementation of Crash Plan, the billing structures will be changing. Backups in TSM will be for servers and projects. Project grants will still apply.

Bulk - A bulk backup is a larger scale billed backup - 1T or larger. This category is requested from the TSM Administrator, and runs to specific servers with larger CPUs. Bulk backs up only once a week, due to the capacity. The data is available for restore from tape. The cost is significantly cheaper than Complete despite the size of the clients, but is generally intended only for disaster recovery purposes.

Archive - Archiving is a long-term retention of data in a static state, expiring completely after a set period of time. A billing code is required: a client must first be a Complete (or Bulk) client to archive data. Data restores are available on tape.

Database - SQL and Oracle databases are managed by the DBA team and are defined on specific servers. These are billed backups, including archives, and data restores are generally available on tape.

Personal - The Personal backups are converting to Crash Plan.

DeSC - The DeSC installations are converting to Crash Plan.

Vista - The Vista installations are converting to Crash Plan.

What are the types of backups? [10/18/2011]

Automated backups on TSM are incremental, this means a backup is run of all the data on a client, but then only incremental changes are backed up. Standard changes are about 3% of data, and depending on the user of a particular client, sometimes less than that.

Selective backups on TSM mean a forced backup of a file or folder every time the backup runs, regardless of whether the data has changed or not. These can be set within the TSM client options. A selective backup should always be run before a client changes configurations, to ensure data.

Manual backups on TSM are run at the client level. They are recommended for remote users, and should apply to specific files or folders. Remote backups are *very* slow and often tie up memory, this is because off-site connections are "incoming", where backups are "outgoing". If a user needs to run a manual backup, it should be a time when the machine will be unused, and if the data backing up is large, the user should not expect it to transfer quickly.

Archive backups on TSM are snapshots of specific data at a specific date and time. Many groups use archives to maintain records for legal reasons. The advantage to archiving is the data can be deleted off the local client, or changed, or updated, and the older version is still retrievable. The disadvantage is the data will eventually be deleted at the end of the storage term.

For instance, the OPM Help Desk ticketing system has over 1.5 million tickets, including attachments - this is a lot of data, over 400G! The Help Desk server, however, is a standard workstation server, which would be seriously compromised if it were required to hold all of this! Closed tickets with all included data, attachments, and resolutions are archived, and are then purged off the workstation, making the maintenance easier. The archived tickets are maintained in TSM and can be retrieved, if needed.

Archiving is only available to billed clients. Before using it, please consult the TSM administrator to discuss what storage terms exist and how to use the archive tool.

How do I change what backs up to the client? [10/18/2011]

On each client is an option file, dsm.opt for windows, dsm.sys for Mac, Unix, and Linux. On Windows and Macs, the options can be updated in the GUI (preferable), or edited in the text. Depending on how the client was registered, there is also a domain option set on the TSM servers, which determine if only User files, or all drives but not System Objects, or all data for snapshots, etc., will be backed up.

For instance, a DeSC client backs up only User files on the C drive in Windows. Files kept at the C root, or in a special folder stored under the Program Files directory will never be touched.

A Mac client will back up data under the root. But Mac users are often warned, Time Machine is not to be backed up by TSM. The Time Machine is a local backup, and the compressed files cause complications and eventually can stall back ups to TSM. For this reason users are cautioned: if Time Machine is going to be activated on a Mac, do not change the default storage information, TSM excludes it at the server level using the defaults defined by Apple.

The syntax for include and exclude statements is similar across all operating systems:

include.fs /<directory>/<directory> includes all data in a specific file system
exclude.fs /<directory>/<directory> excludes all data in a specific file system
exclude /.../*.<filetype> excludes all existences of a specific filetype

There are several variables for including and excluding data. Look at the dsm.sys or dsm.opt to review all the defaults defined when the TSM client was installed. Note that changes to the options require a re-start of the TSM scheduler!

What does a "Failure 12" mean on the TSM backup? [10/18/2011]

There are several failures associated with a TSM backup: Failure 1, 4, 8, 1092, and 12.

Failure 1 is a connection issue: each TSM server has about 150 sessions available for backup at any time. This means that every client has to wait in queue. If a client is never able to access the server during the scheduled time, it will have a Failure of "1".

Failure 4 is specific: files were skipped during backup because they were in use. TSM does not back up data in use, only static data comes across.

Failure 8 is a "severed" backup: the client was backing up and stopped abruptly. It may be the user was unaware the backup was running and shut down, or perhaps it runs on battery power and the battery ran out of juice, or perhaps the network connection was lost. It is actually referred (by IBM) as a "catastrophic" failure because data can become compromised, but if it is just a case of a client shutdown, it's usually recoverable the next time the backup is scheduled.

"Severed", by the way, is one of the causes of an "Incomplete!" report on a filespace. If an inadvertent shutdown was the cause, be sure to allow TSM to complete the next scheduled backup.

Failure 1092 (or any 4-digit code) is a software failure reference: when a backup shows a code like this, the client has to be re-installed, the software has been overwritten, or it is an incompatible version of software with the server.

Failure 12 is the bane of every TSM Administrator's existence: it's just too generic!

  • The most common reason for a Failure 12 is the backup "overran" the scheduled time - in a 12-hour window, jockeying for position with a thousand other clients, the backup may have taken 12.5 hours to complete, so it "failed" to back up within the allotted time.
  • Sometimes files were skipped which were skipped the night before - and in this case, it's not a good thing, but it's not a terrible thing, either!
  • Sometimes the backup ran, but a large file was backing up and the backup had to let go of the connection to TSM while buffering the data, picking up later, so it "failed" to keep the connection.

The reasons are myriad. The good part of a Failure 12 is - it's usually benign. If a client backs up with a "Failure 12" all the time, however, it should be reviewed, there may be a slow connection which should be addressed, or perhaps the scheduled time for backup should be changed.

How do I change the TSM client name? [01/12/2012]

Before changing the name of the client, contact TSM support and ask for a client-name change. After the client name has been changed by TSM support, the new name has to be initiated on the local machine with correct definitions.

*************************

For information on changing a nodename in Windows, please refer to this document from Software Support:

https://sp.princeton.edu/oit/imagedocs/Documents/SFI.aspx

A network ID is required to access this document.

*************************

On a Mac or Unix or Linux client, the concept is the same - within the dsm.sys file is the connection stanza for the client.

Why is this name being changed? Is it a new client and the old data is being renamed to be accessible to the new client? Or is the name of the existing client changing for a specific purpose? If it is a new client, the standard configuration process can be followed, using the name as defined in TSM on the new machine. If it is an existing client, the dsm.sys file is edited and communication is tested.

Before editing the dsm.sys file, no client connection should be running, and the scheduler should be stopped.

To access the local client, the default client stanza sits at the top of the dsm.sys file, and is the client TSM will access first whenever the local client is opened (the first client is also the default for the local scheduler).

servername     TSM3
NODENAME       MYCLIENT
PASSWORDACCESS GENERATE
   COMMMethod         TCPip
   TCPPort            1603
   TCPServeraddress   tsm3.princeton.edu

Whether from a GUI (with a Mac) or on a command line, "MYCLIENT" and its server identifer "TSM3" is called unless referenced otherwise. So a second client can be added to the dsm.sys and the second client can be access (if this is required - e.g., a restore is being requested from another client) from the local machine if it properly defined:

servername     OTHERCLIENT
NODENAME       OTHERCLIENT
PASSWORDACCESS GENERATE
   COMMMethod         TCPip
   TCPPort            1602
   TCPServeraddress   tsm2.princeton.edu

cmd line> dsmc -se=OTHERCLIENT

The first time this alternate client is referenced in the login, the id and password will be requested. The next time OTHERCLIENT is opened, there should be no prompt. But to get to OTHERCLIENT, it must always be included in the command line call.

To change the name of MYCLIENT to NEWCLIENT, a new stanza can be added to the top of the dsm.sys file, creating a new default:

servername     TSM3
NODENAME       NEWCLIENT
PASSWORDACCESS GENERATE
   COMMMethod         TCPip
   TCPPort            1603
   TCPServeraddress   tsm3.princeton.edu

servername     TSM3
NODENAME       MYCLIENT
PASSWORDACCESS GENERATE
   COMMMethod         TCPip
   TCPPort            1603
   TCPServeraddress   tsm3.princeton.edu

servername     OTHERCLIENT
NODENAME       OTHERCLIENT
PASSWORDACCESS GENERATE
   COMMMethod         TCPip
   TCPPort            1602
   TCPServeraddress   tsm2.princeton.edu

Then NEWCLIENT has  to be initiated on the TSM server:

Mac-os> dsmc -se=TSM3

The id and password will be requested the first time. Close and re-open the client, there should not be an ID and password prompt this time, and the startup should show NEWCLIENT, not MYCLIENT (This is output from a command line):

[admin_id@NEWCLIENT]# dsmc
IBM Tivoli Storage Manager
Command Line Backup-Archive Client Interface
  Client Version 6, Release 2, Level 4
  Client date/time: 01/12/2012 15:28:59
(c) Copyright by IBM Corporation and other(s) 1990, 2010. All Rights Reserved.

Node Name: NEWCLIENT
Session established with server PRINCETON_TSM3: AIX-RS/6000
  Server Version 5, Release 5, Level 4.2
  Data compression forced on by the server
  Server date/time: 01/12/2012 15:53:39  Last access: 01/12/2012 12:10:17

tsm> The files from MYCLIENT will be visible on NEWCLIENT, now.

Start up the scheduler, and look in the DSMSCHED.LOG, NEWCLIENT should be referenced for the next backup job:

01/12/2012 11:45:39 TSM Backup-Archive Client Version 6, Release 2, Level 4
01/12/2012 11:45:39 Querying server for next scheduled event.
01/12/2012 11:45:39 Node Name: NEWCLIENT
01/12/2012 11:45:39 Session established with server PRINCETON_TSM3: AIX-RS/6000
01/12/2012 11:45:39   Server Version 5, Release 5, Level 4.2
01/12/2012 11:45:39   Data compression forced on by the server
01/12/2012 11:45:39   Server date/time: 01/12/2012 12:10:17  Last access: 01/12/2012 12:09:15

01/12/2012 11:45:39 --- SCHEDULEREC QUERY BEGIN
01/12/2012 11:45:39 --- SCHEDULEREC QUERY END
01/12/2012 11:45:39 Next operation scheduled:
01/12/2012 11:45:39 ------------------------------------------------------------
01/12/2012 11:45:39 Schedule Name:         STANDARD
01/12/2012 11:45:39 Action:                Incremental
01/12/2012 11:45:39 Objects:              
01/12/2012 11:45:39 Options:              
01/12/2012 11:45:39 Server Window Start:   18:30:00 on 01/13/2012
01/12/2012 11:45:39 ------------------------------------------------------------
01/12/2012 11:45:39 Schedule will be refreshed in 12 hours.

At this time, the stanza for MYCLIENT is no longer necessary, because the client on the TSM server has been initiated with the new name, so the MYCLIENT stanza can (but does not have to) be deleted out of the dsm.sys file.

How do I upgrade the TSM client? (under construction)