Home / Services And Resources / Backup

TSM: Backup on Athena 9.4

 

 

For debathena/Ubuntu machines please see these instructions.

On this page:
Overview
Who Should Use TSM for Athena
Account and Password Information
Backups
Installation
What is Backed Up
Restoring Files
Notes

Overview

TSM (Tivoli Storage Management) is the successor product to ADSM and is very similar to it in terms of functionality and structure. The current version of TSM on Athena is 5.2.3, and is available for Sun/Solaris and Intel/Linux machines.

Note: Scheduled TSM backup for Athena machines is set to only back up files below /var/local by default, with a small number of exceptions. See What is Backed Up for more information.

Files backed up by TSM 5.2.3 cannot be restored by pre-5.x TSM/ADSM clients. However, TSM 5.2.3 can restore files backed up by such older releases. On any platform, if you are not logged in as root, you may find that you are unable to restore files owned by you that were backed up by root (you might not see the files at all when you expand the file tree to do a restore). However if you are logged in as root you should be consistently able to restore all backed up files.

Support Statement
We are only supporting backup-restore (not archive-retrieve) functionality at this time. We are also not currently supporting the TSM Web interface.

Who Should Use TSM for Athena

  • TSM backup on Athena is appropriate for private workstations located in a securable area. It is not appropriate for use with workstations located in public clusters or open to public logins.
  • TSM should not be used to make a full system backup. This is not useful in the Athena environment and can lead to corruption of the operating system of your machine, requiring a complete reinstall.
  • It is only intended to back up user files on the local hard drive, not files on network file systems (including AFS directories). However, you can copy files from network file systems to local hard drives, and back them up with TSM from there.
  • For help with TSM on a private workstation, see the TSM Manual or contact Athena Consulting by running the command olc at your athena% prompt.

Account and Password Information

Get an Account

  1. This only needs to be done once per machine. If you already registered this machine for TSM/ADSM on Athena with a previous TSM/ADSM release, you do not need to do this again and can skip ahead to Backups.
  2. Register online using the registration form. In the comment field, please state that this is for an Athena machine. You can also contact the Service Desk to register for a TSM account; again, please specify that this is for an Athena machine. There is a $7.50 per month charge for each account.
  3. The Help Desk gives you an initial TSM password when they set up your account. Before you run TSM the first time, you need to change it to a more secure password. You will generally not need it to do backups and restores, but you should save it in case you need it again (some unusual operations may require it).
  4. If at some point you need to update information about your TSM account, see Update TSM Information/Request Services. Among other things, you can use this page to request deletion of backups that you no longer want to keep (there is no direct way you can do this yourself).

Change Your TSM Password
After getting confirmation that your account has been set up, log into your machine using your ordinary Athena username, then type the following:

 

attach adsm

(add the ADSM locker)

su

(log in as root; you will need the root password)

Type the following command:

/mit/adsm/setpass

(it will print several prompts. Please respond as indicated)

Please enter password for node "CPU name":

(type the assigned password)

Please enter a new password:

(type a new password of your choosing)

Enter new password for verification:

(retype it exactly as before)

If it then says:

Password updated.

...the operation completed successfully.

If on the other hand you get:

Unable to update password.

...it did not recognize what you entered for the initial password or did not accept the new one for some reason.

Note: If your machine previously had an TSM/ADSM account as a non-Athena machine, this is likely to happen because TSM/ADSM on Athena uses a different server; in any case, please call the Help Desk, x3-1101, for assistance and inform them of this circumstance if it applies to you.

TSM encrypts and stores your password locally in file /etc/adsm/TSM.PWD, accessible only to the root user. It generates a new password automatically when the old one expires, about every ninety days (no user intervention will be required). After this is done, subsequent use of TSM will not prompt you for a password, and you will not need to enter it when you run TSM later on that machine.

Backups

Manual Backup
To use the dsm (GUI) or dsmc (command-line) clients, type:

add adsm

Note: if running TSM on a Linux machine as root, replace the line above by:

attach adsm
export PATH=/mit/adsm/arch/bin:$PATH

(the last command above assumes you are root when you execute it. It uses bash shell syntax as that shell is the default for root on Linux machines)

followed by:

dsm & (for the GUI client)

or

dsmc (for the command-line client)

or

dsmj & (for the new Java GUI client)

When using the dsm or dsmj GUI, please use the Backup function, not Archive. Expand the Local file tree in order: Local -> / -> var -> local to get to where files should be backed up from (/var/local in your UNIX file system), and continue expanding the file tree below there. Click the Backup button when you are ready to proceed.

Wait for the red "stop sign" to clear in the Task List window; this may take several minutes. If the outline of a window appears but without any text inside, TSM is waiting for a network connection to complete. Wait until the text appears before attempting to exit.

Scheduled Backup
In order to install and start unattended TSM scheduled backups on Athena, You will first need to install required files on your local hard drive and start the dsmc daemon as root. This is normally done only once, but you may need to restart the daemon manually if it dies for some reason. The configuration is set to restart this daemon automatically if your machine is rebooted.

If you already have a TSM/ADSM account for this machine but scheduled backups have not been set up, please send mail to computing-help@mit.edu, explaining that you already have a TSM/ADSM account (give the machine name) and state that you are requesting scheduled backups for it. You need to register for scheduled backup even if you already have a TSM/ADSM account for the same machine.

If you don't already have a TSM/ADSM account for this machine, please perform the steps starting from Account and Password Information before proceeding. Be sure to write in the comment field or tell them that you need scheduled backup set up for this machine.

Installation

  1. If you just started a new TSM/ADSM account, make sure you have changed your password before proceeding. This only needs to be done once. Also wait until you receive confirmation that your registration for scheduled backups is in effect. If you are updating from a prior release please turn off the backup daemon first, as explained below in Turn Off Scheduled Backups
  2. attach the adsm locker (if you haven't already done this) by typing:
     
    attach adsm
  3. su to root (if you are not already root) and cd to the root of your file system:

    cd /

  4. Unpack-replace <distfile> below by:

    tsmsun.tar (Sun)



    tsmlnx.tar (Linux)



    tar xvfp /mit/adsm/current/distrib/platform/<distfile>
  5. For Linux ONLY: Edit file /etc/rc.d/rc.local, adding the following line just before the final line containing "fi" at the very end of the file:

    /etc/rc.d/init.d/tsm start
  6. Start the dsmc daemon by typing:

    /var/local/tsm/current/startdsmc

Turn Off Scheduled Backups

These steps should be sufficient to get the daemon running and start scheduled backups. If you need to stop it for some reason (which will turn off scheduled backups), type, as root:

/var/local/tsm/current/stopdsmc

You can check if the daemon is running by typing:

/usr/bin/ps -ef | /usr/bin/grep schedule | /usr/bin/grep -v grep | /usr/bin/awk '{print $2}' (Sun)
/bin/ps axww | /bin/grep schedule | /bin/grep -v grep | /usr/bin/awk '{print $1}' (Linux)

If it's running and you are not in the process of doing a backup, you should see a number printed (the process id of the TSM daemon). It should normally keep running once you start it.

Note: TSM will create a log file /var/local/tsm/current/log/dsmsched.log that records every file that has been backed up. This file can get very large if your backup set has many files. As a rough guide, if you back up around 50,000 files, this log file may be around 75 meg in size. Be sure to allow enough free disk space for the creation of this file. We have set a default option to prune the log file after 30 days. This can be changed by editing or deleting the line:

schedlogretention 30

in file /var/local/tsm/current/dsm.sys. If the entry is deleted, the log file is never pruned (it will grow indefinitely).

You may see some errors recorded in a file dsmerror.log in the same directory as the log file. At times, the client can have trouble connecting to the server and you may see errors like the following:

10/12/00 01:42:32 TcpFlush: Error 32 sending data on Tcp/Ip socket 6.
10/12/00 01:42:32 sessRecvVerb: Error -50 from call to 'readRtn'.

or

10/22/2000 08:44:05 sessOpen: Failure in communications open call. rc: -50
10/22/2000 08:44:05 ANS1017E Session rejected: TCP/IP connection failure

Such errors may appear intermittently but as the client will retry until a connection succeeds, you probably don't need to report these if the log file indicates that backups are successful.

Note: the log file dsmerror.log created during scheduled backups is distinct from the dsmerror.log created if there are errors when you back up files manually. The latter is stored in ~/dsm_backup in your Athena home directory.

Troubleshooting
We have occasionally run into problems with TSM scheduled backups due to the connection between the TSM server and client getting out of sync. If this happens to you, backups will stop taking place. You can see if this has happened by looking at the end of the log file /var/local/tsm/current/dsmsched.log using a command such as:

tail -10 /var/local/tsm/current/dsmsched.log

The last action taken by TSM is the last date that appears in the file. If this date is not the current date you are most likely experiencing the problem. You can reset the connection by stopping, then restarting the client daemon. To do this, first su to root, then type:

/var/local/tsm/current/stopdsmc

followed by:

/var/local/tsm/current/startdsmc

We suggest that you check your log file regularly and take action as above if appropriate.

 

What is Backed Up

The files that are backed up are modified by entries in file:

/var/local/tsm/current/include-exclude

Exceptions to the /var/local Directory Backup Limitation
We allow files in /etc and /var/spool to be backed up by default, as these directories contain files that may be important to some end-users.

We exclude the following files in any location from backup:

ssh_host_key
ssh_random_seed
ssh_host_key.pub
krb5.keytab
srvtab
SERVER_A
TSM.PWD

You can override the scheduled backup default settings by editing your local include-exclude file, but please make sure you understand how TSM interprets directives such as include, exclude, exclude.dir and exclude.fs. This can be complex and difficult to interpret; see Tivoli Storage Manager for UNIX Backup-Archive Clients Installation and User's Guide for detailed information [Adobe Acrobat required].

Note: You will need to stop and restart the dsmc daemon as explained above for changes in the include-exclude file to take effect.

Please also be aware that it is not a good idea to back up and restore any system files that are important to Athena workstation operation- overwriting a newer system file with an older backup may lock up your machine and require a complete reinstall. Unfortunately there is no easy way to completely specify which files are ones you need to be careful with. Unless you are an expert user you are strongly advised to only back up and restore files below /var/local.

Security
If you have subdirectories of /var/local that you don't want backed up, you can exclude them by adding exclude.dir lines to the end of your include-exclude file; for example, to exclude a directory (and all its subdirectories) /var/local/foo, add this to the include-exclude file:

exclude.dir /var/local/foo

If you want to exclude directories at a lower level, consult the TSM include-exclude documentation for details. If you want to exclude entire file systems, use exclude.fs instead, at the mount point.

Please do not change the lines starting with:

SErvername
COMMmethod
TCPPort
TCPServeraddress
passwordaccess
servername
tapeprompt

in your dsm.opt and dsm.sys files -- if you do your backups most likely won't run properly.

Please also don't alter or change permissions on file /etc/adsm/TSM.PWD. It contains your encrypted TSM/ADSM password and defines the identity of your machine to the TSM/ADSM server.

Note: the /var/local/tsm/current/include-exclude file, which controls what is backed up during scheduled backups, may not be the same as the /mit/adsm_v5.2.3/distrib/share/include-exclude file, which applies to manually performed, non-scheduled backups. In particular these will be different if you edit the local file; you can't edit the non-scheduled backup one. The Linux and Sun versions are somewhat different, reflecting differences in the respective file systems.

Restoring Files

Files backed up with TSM release 5.2.3 or later cannot be restored with prior TSM releases. To use the default release (currently 5.2.3) dsm (GUI) or dsmc (command-line) clients now, type:

 

add adsm

Note: If running TSM on a Linux machine as root, replace the line above by:

attach adsm
export PATH=/mit/adsm/arch/bin:$PATH

followed by:

 

dsm & (for the GUI client)

or

dsmc (for the command-line client)

or

dsmj & (for the new Java GUI client)

When using the dsm or dsmj GUI, please use the Restore files option (not Retrieve files), and expand the File Level option, not Backup Sets.

Wait for the red "stop sign" to clear in the Task List window after selecting your restore choices. This may take several minutes.

You restore files backed up by scheduled backup as you restore files backed up manually -- you would generally want to use the dsm or dsmj GUI client and expand the File Level file tree to select files to be restored. You may find that you are unable to restore files owned by you when logged in under your own username. We have seen inconsistent behavior in this regard on various platforms (you might not see the files at all when you expand the file tree to do a restore). However if you are logged in as root you should be consistently able to restore all backed up files.

After the restore completes, you should get a Restore Report window on the screen. Clicking on the Close button of this window will return you to the main dsm GUI. Please be aware that at times of network congestion or heavy server load operations can take a long time, even if you are only restoring a small number of files.

Point in Time Restore is supported (select Point in Time from the Restore window), but only for a period of 30 days prior to the current date.

Restoring Files to a Different Machine

  1. Put in a request that the password for the backed up machine you want to restore elsewhere be reset by contacting the Help Desk with the nodename of the machine.
  2. Change your TSM/ADSM password on the original machine and remember the new password.
  3. Start the dsm GUI with the -virtualnodename switch on the new machine, referring to the name of the original machine. You will most likely need to do this as root. If the original machine is dit.mit.edu, the command would be:
    dsm -virtualnodename=dit.mit.edu &

     

    you will be asked to enter the TSM password of the original machine (use the one set in the previous step), after which you will be able to restore files in the usual way. You won't be able to use this password for more than 90 days because TSM changes it automatically at this time interval. If more time than this has elapsed since the last password reset, you will need to do this again as explained above.

Notes

  1. You are advised to back up or restore files with TSM while logged in under your own username (not root) where possible. This is most simply done by storing your files in a tree owned by you below /var/local. Assuming your username is jdoe, you can start one by doing, as root:
    cd /var/local

    mkdir jdoe (assuming this does not already exist)

    chown jdoe jdoe
    After this step, you will not need to be root to read and write files within the /var/local/jdoe tree; you can use your ordinary, non-root username jdoe. Then, as user jdoe, copy your files into the tree below /var/local/jdoe. If you plan to install software on other physical drives attached to the same machine, you should also put it within a directory owned by you on that drive. The steps are the same as above, but the tree will be located in a different directory (typically, below /u1 for a second drive).
  2. Given the current TSM configuration, any user who can log into a machine for which a TSM backup account has been created can use that account to back up or restore their own files. They will not be able to back up or restore other user's files provided that default ownerships and permissions have not been changed (each user owns his own files, and each user's files and directories are not set to be world-readable or group-readable). The root user can back up and restore anyone's files.
  3. For nonscheduled backups, a default TSM configuration file, dsm.opt, is copied into a configuration directory dsm_backup created in each user's Athena home directory. This file does not need to be updated, however users may edit it (as a text file) to set any options they want to that can be specified in the dsm.opt file. Note that some options can only be specified in the system-wide nonscheduled backup dsm.sys file, which users can't edit. Please consult the TSM Manual for details on options and which file (dsm.opt, dsm.sys) they can be specified in. Please note that this file is distinct from another one with the same name created in the /var/local/tsm/current directory if you configure your machine for scheduled backups.
  4. Backing up or restoring a large file system can take quite a while for the backup/restore process to start, and significantly longer to complete (hours if very large). If you are backing up a very large file system (>5-10 gig or so), you may run into problems. If this happens you might need to break up the backup into smaller separate pieces.
  5. IS&T has established a TSM Listserv list. It serves as an electronic user group where subscribers can ask and answer questions and receive updates on new developments in TSM software. To subscribe, e-mail listserv@mitvma.mit.edu with the following message: SUBSCRIBE MIT-BKUP your-full-name.
 

IS&T Service Desk

Monday-Friday
Telephone/Online: 8am - 6pm
Walk-In (N42) 9:15am - 5pm

Web: IS&T Service Desk
Email: computing-help@mit.edu
Phone: 617.253.1101