TSM ( Tivoli Storage Manager ) BASICS

1. Introduction.
2. TSM Architecture
3. Methods of accessing TSM server
4. Essentials for a backup
5. Modes of Communication
6. TSM Installation & configuration
7. Progressive Incremental
8. Active version and Inactive version
9. Backup Status

1.   Introduction:

TSM (Tivoli Storage Manager), a backup tool developed by IBM. The name Tivoli came from (Reverse of I LOVe IT) and works on the concept of “Manager of Managers”.

For a backup to happen we need,

i) TSM server.
ii) TSM client.
iii) Tape library.

     TSM server is software that is installed on any of the Windows or UNIX server. TSM server is responsible for taking backups of all the TSM clients connected to it. TSM clients can be other Windows or UNIX servers for which backups are taken.

2.     TSM Architecture:

3. Methods of accessing TSM server:
There are several ways of accessing the TSM server

i) TSM GUI.
   a. Web console.
   b. ISC Admin. (Integrated Solution console)
ii) Administrative command line.

3.1  TSM GUI:
TSM’s graphical user interface (Web console) looks similar as shown below. 
  i) Operation view.
  ii) Network View.
  iii) Configuration View.
  iv) Object View.
 

You can work with commands by clicking options->show command line.

3.2  Administrative command line:

            Administrative command line is a (CLI) where TSM server commands can be executed. It can be installed on the same server where TSM server software has been installed. Admin command line can also be installed on other servers and can be accessed from the other server.

            To open the Administrative command line go to All Programs->Tivoli storage manager -> Administrative command line. Then type in the user id and password.

From Unix, go to /opt/tivoli/tsm/server/bin and then type in dsmadmc, to open the administrative command line.

            To get the syntax of the commands to be used, type

Help Query (This would display the list of all query commands. To get to know about the syntax of each and every command use help before every command, for instance type help query node to get to know the functions & attributes of this command)

4.  Essentials for a backup:

  The following are essential for a backup to start,

i)                    dsm.opt file (For Unix servers dsm.sys & dsm.opt file).

ii)                  TSM Scheduler service.

The dsm.opt file can be considered to be heart of any backup and no backup can happen without this file. It contains the details of the data to be backed up, the TSM server address, Type of communication method, the node name as registered in TSM server, the port number used for communication, password access which can be either prompt or generate. It can also contain the list of files to be specifically excluded from backup. By default all files are included for backup, to exclude a particular file it has to be explicitly defined.

      The default location of this file,

For Windows clients – C:/Program Files/Tivoli/TSM/BA Client/

For Unix clients -- /opt/tivoli/tsm/client/ba/bin/

                                     (Or)

                            /usr/tivoli/tsm/client/ba/bin/

Note: For Unix clients dsm.sys & dsm.opt files are essential.

5.  Modes of Communication:

There are 2 types of communication methods possible between TSM server and TSM client, they are

i)                    Polling.

ii)                  Prompted.

i)                    Polling.—The TSM client contacts with the TSM server for a specified duration (Time depends upon the value specified in polling interval parameter).

ii)                  Prompted.—TSM server tells the TSM client when its next backup is scheduled.

If the communication method is set to prompted then it will increase the load of the TSM server as it has to keep informing its clients about the start time for backup. If it is set to polling method then the TSM client keeps contacting the TSM server as per the duration interval and hence there is comparatively less load on the TSM server.

The retry period duration and the maximum number of retries value will come into picture when the session with the TSM server has been lost and the TSM client tries to establish the session back as per the values set here.

For any backup to trigger there should be a proper communication between TSM server & TSM client, for this TSM scheduler service should be running always.

6.   TSM Installation & configuration:

           

TSM 5.5 is the latest version released. We are using mainly TSM 5.4, though some clients are still in older version.

For a backup to happen, we need to install TSM client software and then configure the opt file & scheduler service. From TSM server end we need to register a node. Nodes are the windows and Unix TSM clients configured for backup. On the TSM server we need to then configure schedules, which will enable the backup to start in the specified time. We then need to associate the node to the schedules for the backup to start in the specified time. Association provides the link between nodes & schedules; if nodes are not associated then backup will not happen.

6.1 Registering new nodes:

 Syntax:

     Register node <node name> <password> domain=domain name << all other parameters are optional>>.

Updating node details:

Syntax:

    Update node <node name> <<parameters to be updated>>

6.2 Defining new schedules:

  To define a new schedule,

i)                    Create a new schedule.

ii)                  Define the association between the schedule and the node.

i)                    Creating a new schedule.

     Syntax:

   Define sched <domain name> <sched name> type =<client/administrative> action=<incremental/archive/…> start date=<as per req> start time=<as per req> duration=<as per req> duration units=<hours/mins/…> ….

  Except for domain name and schedule name other parameters are optional, if they are not specified the default values will be taken.

ii)                  Defining association.

    Syntax:

   Define association <domain name> <schedule name> <node name>

          All parameters are mandatory, defining association is critical as it provides a link between the schedules defined and the nodes. If the association is not defined between the schedule and node then there will be no backup happening.

6.2.1 To remove association:

Syntax:

Delete assoc <domain name> <sched name> <node name>       

If association is removed backups can no longer occur. 

6.2.2 Updating Schedules:

     Syntax:

       Update sched <domain name> <sched name> <<required parameters same as in define sched>>

  This command will update an existing schedule with the new parameters as used in the above command.

      6.2.3 To find the list of schedules running for a node:

Syntax:

  Query sched <domain name> * nodes=<node name>

      6.2.4 To find the list of nodes associated to a particular schedule:

Syntax:

  Query assoc <Domain name> <sched name>

  If (*) is used in place of domain name all the nodes that are associated for that particular schedule will be listed.

6.3        Sessions:

  When ever a TSM client interacts to the TSM server a session is created and the same can be observed from the TSM server. There can be 2 types of sessions,

a)      Normal session.

b)      Scheduled session.

Normal sessions are just an interaction between the TSM server and TSM client, like if we set the polling interval to be 1 hour there will be a session established for every 1 hour. Scheduled sessions are those that are created during the scheduled time. There will be maximum limit set for the number of sessions and number of scheduled session a particular TSM server can handle this value can be obtained by using Query system or Query status command.

If a particular session remains in idle state for a long time or if a session needs to be cancelled then the following 2 steps are followed,

i)                    Get the session number,

                  Syntax: Q session

                  This will display the list of current sessions; identify the session to be            cancelled and the session number.

ii)                  Cancel the unwanted session,

                  Syntax: cancel session <session number>

6.4   Process:

There can be several process like migration, reclamation, expiration, backup storage pool, backup db running on the TSM server, to list the current process that are running on the system use the following command,

                        Syntax: Query process

6.5  Creating new domains:

Domains are logical combination of similar type of nodes scheduled for backup. To create a new domain the following command is used,

Define domain <domain name> description=<description of the domain>

            This will create a new domain.

     6.6 Defining new policy sets, management class, and copy group:

            Once a domain is created we cannot directly register a node to that domain, before registering any node we need to create a copy group. For creating a copy group we need to define a policy set and management class.

            Policy set: A policy set contains management classes, which contain copy groups. You can define one or more policy sets for each policy domain. To put a policy set into effect, you must activate the policy set by using the ACTIVATE POLICYSET command.

Only one policy set can be active in a policy domain. The copy groups and management classes within the active policy set determine the rules by which client nodes perform backup, archive, and space management operations, and how the client files stored are managed.

            To define a new policy set issue the command,

            Define policyset <domain name> <policyset name>

            Management class:  To allow clients to use the new management class, you must activate the policy set that contains the new class. You can define one or more management classes for each policy set in a policy domain. A management class can contain a backup copy group, an archive copy group, or both. The user of a client node can select any management class in the active policy set or use the default management class.

Note: The DEFINE MGMTCLASS command fails if a copy storage pool is specified     as the destination for space-managed files.

            Copy group:  Define copy group is used to define a new backup or archive copy group within a specific management class, policy set, and policy domain. The server uses the backup and archive copy groups to control how clients back up and archive files, and to manage the backed-up and archived files. To allow clients to use the new copy group, you must activate the policy set that contains the new copy group.

You can define one backup and one archive copy group for each management class. To ensure that client nodes can back up files, include a backup copy group in the default management class for a policy set.

Note: The DEFINE COPYGROUP command fails if you specify a copy storage pool as a destination.

The DEFINE COPYGROUP command has two forms, one for defining a backup copy group and one for defining an archive copy group. The syntax and parameters for each form are defined separately.

To define a new copy group following command is used,

Define copygroup <domain name> <policyset>  <mgmtclass> destination=<destination stg pool name> verdataexists=<value> verdeleted=<value> retextra=<value> retonly=<value>

Note: An active policy set can neither be defined nor activated. In order to activate an active policy set the only way is to define a new standard policy set and then activate the standard policy set using activate policy set.

            Activate policyset <domain name> <policy set name>

           

The activate policyset command fails if any of the following conditions exist:

• A copy group specifies a copy storage pool as a destination.
• A management class specifies a copy storage pool as the destination for space-managed files.
• The policy set has no default management class.
• A tocdestination parameter is specified, and the storage pool is either a copy pool or has a data format other than native or non block.

The active policy set and the last activated policy set are not necessarily identical. You can modify the original policy set that you activated without affecting the active policy set.

If the server has data retention protection enabled, the following conditions must exist:

• All management classes in the policy set to be activated must contain an archive copy group.
• If a management class exists in the active policy set, a management class with the same name must exist in the policy set to be activated.
• If an archive copy group exists in the active policy set, the corresponding copy group in the policy set to be activated must have a retain version value at least as large as the corresponding values in the active copy group.

Note: Retention protection only applies to archive objects.

Before activating any policy set, first we need to validate the policy set using the command,

            Validate policyset <domain name> <policy set name>

The validate policyset command fails if any of the following conditions exist:

• The policy set has no default management class.
• A copy group within the policy set specifies a copy storage pool as a destination.
• A management class specifies a copy storage pool as the destination for space managed files.
• A tocdestination parameter is specified, and the storage pool is either a copy pool or has a data format other than native or non block.

The server issues warning messages for the following conditions:

• A copy group specifies a storage pool that does not exist as a destination for backed-up or archived files. If you activate a policy set with copy groups that specify nonexistent     storage pools, the client backup or archive operations fail.
• A management class specifies a storage pool that does not exist as a destination for files migrated from HSM clients.
• The policy set does not have one or more management classes that exist in the current Active policy set. If you activate the policy set, backup files bound to the deleted    management classes are rebound to the default management class in the new active policy set.
• The policy set does not have one or more copy groups that exist in the current Active policy set. If you activate the policy set, files bound to the management classes with deleted copy groups are no longer archived or backed up.
• The default management class for the policy set does not contain a backup or archive copy group. If you activate the policy set with this default management class, clients using the default cannot back up or archive files.
• A management class specifies that a backup version must exist before a file can be migrated from a client node (MIGREQUIRESBKUP=YES), but the management class does not contain a backup copy group. If the server has data retention protection enabled, the following conditions must exist:

Ø  All management classes in the policy set to be validated must contain an archive copy group.

Ø  If a management class exists in the active policy set, a management class with the same name must exist in the policy set to be validated.

Ø  If an archive copy group exists in the active policy set, the corresponding copy group in the policy set to be validated must have a retain version value at least as large as the corresponding values in the active copy group.

6.7 Scheduling new servers for backup:

To register a new node for backup following steps have to be followed:

 

i.                         Define domain.

ii.                       Define a policy set for the new domain. (active policy set cannot be defined)

iii.                     Define a management class for the new policy set and domain.

iv.                     Define a copy group with all retention policy parameters.

v.                       Assign the new management class as the default management class to the new domain. Use assign defmgmt command.

vi.                     Activate the policy set that has been defined.

vii.                   Register the node.

viii.                 Define a schedule.

ix.                     Create association between the domain, schedule and the node that has been registered.

7.         Progressive Incremental:

    When a new node is registered with the TSM server the first backup by default will be a full backup and then subsequent backups will be incremental. This will be sufficient enough to restore a deleted file or restore the data even if the system crashes. This is one of the most important features of TSM.

8.         Active version and Inactive version:

           

If a data is being backed up today and today’s backup version is set to be the active version and yesterday’s backup will become inactive version.

  If suppose a particular file is not being backed up today (Assuming we take an incremental backup and file has not changed since yesterday) then yesterday’s backup version will be the active version of backup for that particular file. Active versions would be retained for ever unless it is deleted manually by using delete filespace command.

 The following 4 parameters will decide about the retention period.

i)  Version Data Exists. – Denotes number of inactive versions of a file that is retained.

ii) Version Data Deleted. – Denotes number of versions retained for deleted files.

iii) Retain extra Version.  – Denotes number of days for which inactive versions are retained. 

iv) Retain only Version.  – Denotes the number of days for which last version of a  file is retained.