Archive for February 2013

28 February 2013

Reusing TSM server Database backup and export tape volumes

02:46 No Comments
IBM Tivoli Storage Manager allows us to reuse tape volumes which are used for other server processes. However, there are some limitations if the tape volumes are used for important processes like TSM DB backup & Export.  You cannot reuse volumes that were used for database backups and export operations until you delete the volume information from the volume history file.

 When you backup the database or export server information to a tape, Tivoli Storage Manager records information about the volumes used for these operations in the volume history file. Tivoli Storage Manager will not allow you to reuse these volumes until you delete the volume information from the volume history file. To reuse volumes that were previously used for database backup or export, use the DELETE VOLHISTORY command.

But if the server uses the disaster recovery manager function, the volume information is automatically deleted during MOVE DRMEDIA command processing, otherwise you need to manually run or schedule DELETE VOLHISTORY command.

 Also Read: Steps to do after successful TSM DB restore

For users of DRM, the database backup expiration should be controlled with the SET DRMDBBACKUPEXPIREDAYS command instead of this DELETE VOLHISTORY command. Using the DELETE VOLHISTORY command removes Tivoli Storage Manager's record of the volume. This can cause volumes to be lost that were managed by the MOVE DRMEDIA command. The recommended way to manage the automatic expiration of DRM database backup volumes is by using the SET DRMDBBACKUPEXPIREDAYS command.
Some important points to remember while using this command.
  • Volumes for the most recent database backup series are not deleted.
  • Existing volume history files are not automatically updated with this command.
  • You can use the DEFINE SCHEDULE command to periodically delete volume history records.

DELETE VOLhistory Syntax

>>-DELete VOLHistory--TODate--=--date--------------------------->

   .-TOTime--=--23:59:59-.   
>--+---------------------+-------------------------------------->
   '-TOTime--=--time-----'   

>--Type--=--+-All---------------------------------------+------><
            +-BACKUPSET---------------------------------+   
            +-DBBackup--+-------------------------+-----+   
            |           '-DEVclass--=--class_name-'     |   
            +-DBSnapshot--+-------------------------+---+   
            |             '-DEVclass--=--class_name-'   |   
            +-DBRpf-------------------------------------+   
            +-EXPort------------------------------------+   
            +-REMote------------------------------------+   
            |         .-DELETELatest--=--No------.      |   
            +-RPFile--+--------------------------+------+   
            |         '-DELETELatest--=--+-No--+-'      |   
            |                            '-Yes-'        |   
            |              .-DELETELatest--=--No------. |   
            +-RPFSnapshot--+--------------------------+-+   
            |              '-DELETELatest--=--+-No--+-' |   
            |                                 '-Yes-'   |   
            +-STGNew------------------------------------+   
            +-STGReuse----------------------------------+   
            '-STGDelete---------------------------------'   
Ex:   To delete TSM DB backup volumes which are created 1 week ago

            delete volhistory todate=today-7 type=DBBackup

26 February 2013

Steps to do after successful Tivoli Storage Manager (TSM) Server Database restore

04:04 No Comments
After restoring any Tivoli Storage Manager (TSM) server to earlier point in time DB backup by using DSMSERV RESTORE DB command,  there are some more additional steps required before resuming normal operations of the TSM Server.

Restore of the TSM server database to an earlier point in time can cause TSM to encounter data on disk and tapes for which it has no record, resulting in ANR1330E and ANR1331E errors.

It is important to save a copy of the volume history file (volhist.out, captured by running the BACKUP VOLHIST command) on a regular basis. The information in this file can be used to reduce the amount of volume auditing that is necessary after TSM DB restoration process. 

 Also Read: How to increase or decrease TSM DB, active log and archive log size ?

After a TSM Server restore to a previous point in time, it is necessary to ensure that the storage pool volumes are consistent with the TSM database which has been restored The following steps should be performed prior to returning the TSM server to normal use

TSM Server Database Restoration after steps

  • Immediately after the TSM server database is restored, place the following options into the dsmserv.opt  file
     NOMIGRRECL 
    (Prevents migration and reclamation from kicking off when the server is started)

     DISABLESCHED YES 
     (prevents any schedules from starting when the server is started)

      EXPINT 0 
     (prevents expiration from running when the server is started) 

 If set to something other than 0, change the setting to 0 and record the original setting. After few steps we will remove or reset this option back to the original setting.
  • Start the server in the foreground (./DSMSERV)
  • When the TSM server prompt comes up, enter the command DISABLE SESSIONS so that clients will be unable to connect to the TSM Server.
  • Review the saved volhist file, and locate sequential tape or FILE volumes marked as "STGDELETE" and "STGREUSE" in the list. You will need to audit only these types of volumes created after the date of the database backup that has been restored. If the volhist file is lost or unrecoverable, then all sequential volumes must be audited. The audit command is performed as follows
            AUDIT VOLUME <volume_name> FIX=YES

 Also Read: Restoring damaged Storagepool volumes


This command will verify the data on the volume against the entries in the TSM Server database. Any items that are not found will be removed from the TSM Server.
  • It is also necessary to audit all of the disk pool volumes with the same command above.
  • Once the audits complete, the data on the volumes will be synchronized with the TSM Database at the point in time of the last full database backup.
  • Halt the server and remove the options added in step one, nomigrrecl, disablescheds yes, and set the expinterval back to its original setting.
  • Restart the server as normal. Issue the command ENABLE SESSIONS so that the clients can connect to the server.

What is the use of Tivoli Storage Manager (TSM) SANDISCOVERY Server option ?

03:52 No Comments
Tivoli Storage Manager (TSM) has a new server option called SANDISCOVERY from version 5.3, which allows TSM Server to check automatically if the attached SAN devices has changed their configuration information. When this option is set to ON, the server will perform SAN discovery in the following instances:
  • During server initialization
  • When the device path has been changed
  • When the QUERY SAN command is issued

What is SANDISCOVERY ?

The SANDISCOVERY option specifies whether the Tivoli Storage Manager SAN discovery function is enabled. Using SAN discovery, the server can automatically correct the device's special file name if it has been changed.

 Also Read: Storage Area Network (SAN) Basic Free Tutorials


To use SAN discovery, all devices on the SAN must have a unique worldwide name (WWN). Some virtual tape libraries use the same WWN for all of their drives, SAN discovery will fail for these libraries. If this happens, set the SANDISCOVERY option to OFF and manually define or update the drive paths. If the virtual tape library provides no WWNs, SAN discovery will attempt to use serial numbers to identify the drives.


>>-SANDISCOVERY--+-ON------+-----------------------------------><

                 +-OFF-----+   
                 '-PASSIVE-'   

Parameters

ON
With this option specified, the server will perform SAN discovery during server initialization, when the device path has been changed, or when the QUERY SAN command is issued. This is the default.

OFF
With this option specified, the server will not perform SAN discovery during the server initialization, when the device path has been changed, or when the QUERY SAN command is issued. This is the default.

PASSIVE
With this option specified, the server will not perform SAN discovery during server initialization, when the device path has been changed, or when the QUERY SAN command is issued. This conceals the message produced when you disable SAN discovery and does not take device paths off-line.
The SAN environment can shift dramatically due to device or cabling changes. Device IDs assigned by the SAN may be altered due to bus resets or other environmental changes. This "dynamically" changing nature of the SAN can cause the "static" definitions defined and known to the server (or storage agent) to fail or become unpredictable.

For instance, the server may know a device as id=1 based on the original path specification to the server and original configuration of the LAN. However, some event in the SAN (new device added, cabling change) causes the device to be assigned id=2. When the server tries to access the device with id=1, it will either get a failure or the wrong target device. The server assists in recovering from changes to devices on the SAN by using serial numbers to confirm the identity of devices it contacts.

When you define a device (drive or library) you have the option of specifying the serial number for that device. If you do not specify the serial number when you define the device, the server obtains the serial number when you define the path for the device. In either case, the server then has the serial number in its database. From then on, the server uses the serial number to confirm the identity of a device for operations.

When the server uses drives and libraries on a SAN, the server attempts to verify that the device it is using is the correct device. The server contacts the device by using the device name in the path that you defined for it. The server then requests the serial number from the device, and compares that serial number with the serial number stored in the server database for that device.

If the serial number does not match, the server begins the process of discovery on the SAN to attempt to find the device with the matching serial number. If the server finds the device with the matching serial number, it corrects the definition of the path in the server's database by updating the device name in that path. The server issues a message with information about the change made to the device.

Then the server proceeds to use the device. You can monitor the activity log for messages if you want to know when device changes on the SAN have affected Tivoli Storage Manager. The following are the number ranges for messages related to serial numbers:

 ANR8952 through ANR8958
 ANR8961 through ANR8968 
Restriction: Some devices do not have the capability of reporting their serial numbers to applications such as the Tivoli Storage Manager server. If the server cannot obtain the serial number from a device, it cannot assist you with changes to that device's location on the SAN.

What is a IBM Storage Agent ?

03:33 No Comments
You can configure the Tivoli Storage Manager client and server so that the client, through a storage agent can move its data directly to storage on a SAN. This function is called LAN-free data movement, it is provided by IBM Tivoli Storage Manager for Storage Area Networks. 

 As part of the configuration, a storage agent is installed on the client system. Tivoli Storage Manager supports SCSI, 349X, and ACSLS tape libraries as well as FILE libraries for LAN-free data movement. The configuration procedure you follow will depend on the type of environment you implement; however in all cases you must do the following:
  1. Verify the network connection.
  2. Establish communications among client, storage agent, and Tivoli Storage Manager.
  3. Configure devices for the storage agent to access.
  4. If you are using shared FILE storage, install and configure IBM TotalStorage SAN File System, Tivoli     SANergy, or IBM General Parallel File System .
  5. Start the storage agent and verify the LAN-free configuration.


 To help you tune the use of your LAN and SAN resources, you can control the path that data transfers take for clients with the capability of LAN-free data movement. For each client you can select whether data read and write operations use:
  • The LAN path only
  • The LAN-free path only
  • Either path
Example:

      register node nodename nodepasswd dom=lanfreedom datareadpath=any
     register node nodename nodepasswd dom=lanfreedom datareadpath=LANFree
     register node nodename nodepasswd dom=lanfreedom datareadpath=LAN

Validating your LANFree Configuration

Once you have configured your Tivoli Storage Manager client for LAN-free data movement, you can verify your configuration and server definitions by using the VALIDATE LANFREE command. The VALIDATE LANFREE command allows you to determine which destinations for a given node using a specific storage agent are capable of LAN-free data movement. You can also issue this command to determine if there is a problem with an existing LAN-free configuration. You can evaluate the policy, storage pool, and path definitions for a given node using a given storage agent to ensure that an operation is working properly.

 To determine if there is a problem with the client node NODEA using the storage agent NODEA_STA, issue the following:

                   validate lanfree NODEA NODEA_sta

 The output will allow you to see which management class destinations for a given operation type are not LAN-free capable, and provide a brief explanation about why. It will also report the total number of LAN-free destinations.

SAN discovery functions for non-root users

To configure Tivoli Storage Manager for LAN-free data movement, you can use the QUERY SAN command to obtain information about devices that can be detected on a SAN. To allow both root and non-root users to perform SAN discovery, a special utility module, dsmqsan, is invoked when a SAN-discovery function is launched. 
The module performs as root, giving SAN-discovery authority to non-root users. While SAN discovery is in progress, dsmqsan runs as root. Note that SAN discovery on AIX requires root user authority. The dsmqsan module is installed by default when the Tivoli Storage Manager server is installed. It is installed with owner root, group system, and mode 4755.

 The value of the SETUID bit is ON. If, for security reasons, you do not want non-root users to run SAN-discovery functions, set the bit to OFF. If non-root users are having problems running SAN-discovery functions, check the following:
  • The SETUID bit. It must be set to ON.
  • Device special file permissions and ownership. Non-root users need read-write access to device special files, for example, to tape and library devices.
  • The SANDISCOVERY option in the server options file. This option must be set to ON.
The dsmqsan module works only for SAN-discovery functions, and does not provide root privileges for other Tivoli Storage Manager functions.

 NEXT Steps to configure TSM LANFree backup through Storage Agent

Use PERFORM LIBACTION command to define all tape drives

01:04 No Comments
Tivoli Storage Manager has a new feature command PERFORM LIBACTION where we can define or delete all drives and their paths for a single library in one step. This command is only valid for library types of SCSI and VTL. 

If you are setting up or modifying your hardware environment and must create or change large numbers of drive definitions, the PERFORM LIBACTION command can make this task much simpler. You can define a new library and then define all drives and paths to the drives. 

 OR

 If you have an existing library that you want to delete, you can delete all existing drives and their paths in one step. The PREVIEW parameter allows you to view the output of commands before they are processed to verify the action that you want to perform. If you are defining a library, a path to the library must already be defined if you want to specify the PREVIEW parameter. You cannot use the PREVIEW and DEVICE parameters together.

If you are defining drives and paths for a library, the SANDISCOVERY option must be supported and enabled.

 Read: IBM Spectrum Protect (TSM) Basic Free Tutorials

PERFORM LIBACTION Syntax

Skip visual syntax diagram
>>-PERForm LIBACTion--library_name------------------------------>

>----ACTion--=--+-DEFine--| A |-+------------------------------->
                '-DELete--------'     

                               .-PREView--=--No------.   
>--+------------------------+--+---------------------+---------><
   '-SOURCe--=--source_name-'  '-PREView--=--+-Yes-+-'   
                                             '-No--'     

A (DEFine)

|--+--------------------------------+--------------------------->
   '-DEVIce--=--library_device_name-'   

   .-PREFix--=--library_name------.   
>--+------------------------------+-----------------------------|
   '-PREFix--=--drive_prefix_name-'  
Read: 200+ TSM Interview Question & Answers to crack any interview
library_name (Required)
Specifies the name of the library to be defined or deleted. The maximum length of this name is 30 characters unless you are issuing PERFORM LIBACTION with ACTION=DEFINE and using the default PREFIX value. In that case, the maximum length of the name is 25 characters.

ACTion
Specifies the action for the PERFORM LIBACTION command. Possible values are:
DEFine
Specifies that drives and their paths are defined for the specified library. SAN discovery must be enabled before you specify this parameter value.
DELete
Specifies that drives and their paths are deleted for the specified library.

DEVIce
Specifies the library device name that is used when you define paths if a path to the library is not already defined. If a path is already defined, the DEVICE parameter is ignored. The maximum length for this value is 64 characters. This parameter is optional.

PREFix
Specifies the prefix that is used for all drive definitions. For example, a PREFIX value of DR creates drives DR0, DR1, DR2, for as many drives as are created. If a value is not specified for the PREFIX parameter, the library name is used as the prefix for drive definitions. The maximum length for this value is 25 characters.

SOURCe
Specifies the source server name to be used when you define or delete drive path definitions on a library client or LAN-free client. Use this parameter only if the drives in the library are set up for the local server. If no value is specified for the SOURCE parameter, the local server name, which is the default, is used. The maximum length for the source name is 64 characters.

If a source name other than the local server name is specified with ACTION=DEFINE, drive path definitions are defined with the token value of UNDISCOVERED. The path definitions are then updated dynamically by library clients that support SAN Discovery the first time the drive is mounted.

PREView
Specifies the output of all commands that are processed for PERFORM LIBACTION before the command is issued. The PREVIEW parameter is not compatible with the DEVICE parameter. If you are issuing the PERFORM LIBACTION command to define a library, you cannot specify both the PREVIEW and the DEVICE parameter. Possible values are:
No
Specifies that a preview of the commands that are issued for PERFORM LIBACTION is not displayed.
Yes
Specifies that a preview of the commands that are issued for PERFORM LIBACTION is displayed.

Ex: To set up a VTL library named VTLLIB, complete these steps:
  • Define the library.
          define library VTLLIB libtype=vtl
  • Define two drives and their paths for your new library, VTLLIB. 
         perform libaction VTLLIB action=define device=/dev/lb3 prefix=dr

 The server then issues the following commands:

 define path tsmserver VTLLIB srct=server destt=library device=/dev/lb3 

 define drive VTLLIB dr0
define path tsmserver dr0 srct=server destt=drive library=VTLLIB device=/dev/mt1 

 define drive VTLLIB dr1
define path tsmserver dr1 srct=server destt=drive library=VTLLIB device=/dev/mt2

Virtual Tape Library (VTL) configuration in Tivoli Storage Manager TSM

01:01 1 Comments
A Virtual Tape Library or VTL, is an backup solution that combines traditional tape backup methodology with low-cost disk technology to create an optimized backup and recovery solution.  It is an intelligent disk-based library that emulates traditional tape devices and tape formats. Acting like a tape library with the performance of modern disk drives, data is deposited onto disk drives just as it would onto a tape library, only faster. Virtual tape backup solutions can be used as a secondary backup stage on the way to tape, or as their own standalone tape library solution. A VTL generally consists of a Virtual Tape appliance or server, and software which emulates traditional tape devices and formats.

 Defining a VTL to the Tivoli Storage Manager server can help improve performance because the server handles mount point processing for VTLs differently than real tape libraries. The physical limitations for real tape hardware are not applicable to a VTL, affording options for better scalability.  You can use a VTL for any virtual tape library when the following conditions are true: 
  • There is no mixed media involved in the VTL. Only one type and generation of drive and media is emulated in the library. 
  • Every server and storage agent with access to the VTL has paths that are defined for all drives in the library.
Read: Storage Area Network (SAN) Basic Free Tutorials
If either of these conditions are not met, any mount performance advantage from defining a VTL library to the Tivoli Storage Manager server can be reduced or negated.

 VTLs are compatible with earlier versions of both library clients and storage agents. The library client or storage agent is not affected by the type of library that is used for storage. If mixed media and path conditions are true for a SCSI library, it can be defined or updated as LIBTYPE=VTL.

You have to define a virtual tape library (VTL) to TSM Server to take advantage of mount performance and scalability advantages. VTLs are identified by using the DEFINE LIBRARY command and specifying LIBTYPE=VTL. Because a VTL library functionally interacts with the server in the same way that a SCSI library does, it is possible to use the UPDATE LIBRARY command to change the library type of a SCSI library that is already defined. You do not have to redefine the library. 

To help prevent out-of-space errors, ensure that any SCSI library that you update to LIBTYPE=VTL is updated with the RELABELSCRATCH parameter set to YES. The RELABELSCRATCH option enables the server to overwrite the label for any volume that is deleted and to return the volume to scratch status in the library. The RELABELSCRATCH parameter defaults to YES for any library defined as a VTL.

Read: IBM Spectrum Protect (TSM) Basic Free Tutorials

How to add a new VTL to TSM Server 

If you have a new VTL library and want to use the VTL enhancements that are available in Tivoli Storage Manager Version 6.3, define the library as a VTL to the server:
                            define library VTLIB libtype=vtl

This sets up the new VTL library and enables the RELABELSCRATCH option to relabel volumes that have been deleted and returned to scratch status.

How to update an existing SCSI library to a VTL in TSM

If you have a SCSI library and you want to change it to a VTL, use the UPDATE LIBRARY command to change the library type:

                            update library TSMIB libtype=vtl

 You can only issue this command when the library being updated is defined with LIBTYPE=SCSI.

 Read: What is Offsite Reclamation ?

How to revert a real tape library from the VTL library type

If you define a SCSI tape library as a VTL and want to change it back to the SCSI library type, update the library by issuing the UPDATE LIBRARY command:

                               update library VTLLIB libtype=scsi

How to label and checkin tapes into Tivoli Storage Manager TSM tape library

00:30 No Comments
Tivoli Storage Manager (TSM) requires labelling and checkin of tape volumes to use them in the tape library. All the tape volumes should be labelled and checked into library with appropriate commands, misuse of these LABEL & CHECKIN commands will result in loss of the complete data in that particular volume. The procedures for volume checkin and labeling are the same whether the library contains drives of a single device type, or drives of multiple device types. 

 Always ensure that enough labeled volumes in the library are available to the server so that you do not run out during an operation such as client backup. Label and set aside extra scratch volumes for any potential recovery operations you might have later.

Each volume used by a server for any purpose must have a unique name. This requirement applies to all volumes, whether the volumes are used for storage pools, or used for operations such as database backup or export. The requirement also applies to volumes that reside in different libraries but that are used by the same server.

 Read: IBM Spectrum Protect (TSM) Basic Free Tutorials

How to label library volumes in TSM Tape Library ?

Syntax:

>>-LABEl LIBVolume--library_name-------------------------------->

>----+-volume_name----------------------------------------------------+---->
     '-SEARCH--=--+-Yes--| A |--+--LABELSource--=--+-Barcode--------+-'     
                  '-Bulk--| A |-'                  +-Prompt---------+       
                                                   '-Vollist--| B |-'       

                                .-OVERWRITE--=--No------.   
>--+-------------------------+--+-----------------------+------->
   '-CHECKIN--=--+-SCRatch-+-'  '-OVERWRITE--=--+-No--+-'   
                 '-PRIvate-'                    '-Yes-'     

   .-WAITTime--=--60----.   
>--+--------------------+--------------------------------------><
   '-WAITTime--=--value-'   

A (SEARCH=Yes, SEARCH=Bulk)

|--+-VOLRange--=----volume_name1,volume_name2---+---------------|
   |               .-,-----------.              |   
   |               V             |              |   
   '-VOLList--=--+---volume_name-+--+-----------'   
                 '-FILE:--file_name-'               

B (LABELSource=Vollist)

                 .-,-----------.      
                 V             |      
|--VOLList--=--+---volume_name-+--+-----------------------------|
               '-FILE:--file_name-' 

Where CHECKIN Specifies whether the server checks in the volume. This parameter is optional. The following are possible values:
SCRatch
Specifies that the server checks in the volumes and adds them to the library's scratch pool. If a volume has an entry in volume history, you cannot check it in as a scratch volume.
PRIvate
Specifies that the server checks in the volumes and designates them as private. Private volumes are available only when you request them by name.
If you do not specify a value for this parameter, then the command will only label the volume but will not check it in. If you do not specify a value for this parameter and you want to check in the volume, you must issue the CHECKIN LIBVOLUME command.
Ex: label libvolume TSMLIB search=yes labelsource=barcode checkin=scratch
        label libvolume TSMLIB search=yes labelsource=barcode checkin=private
Read: Tape Library related Interview Questions

How to Checkin library volumes into TSM Tape Library ?

Syntax:

 
>>-CHECKIn LIBVolume--library_name------------------------------>

                    .-SEARCH--=--No-.       
>----+-volume_name--+---------------+-+------------------------->
     +-SEARCH--=--Yes--+-------+------+     
     |                 '-| A |-'      |     
     '-SEARCH--=--Bulk--+-------+-----'     
                        '-| A |-'           

                           .-OWNer--=--""----------.   
>--STATus--=--+-PRIvate-+--+-----------------------+------------>
              +-SCRatch-+  '-OWNer--=--server_name-'   
              '-CLEaner-'                              

   .-CHECKLabel--=--Yes---------.  .-SWAP--=--No------.   
>--+----------------------------+--+------------------+--------->
   '-CHECKLabel--=--+-Yes-----+-'  '-SWAP--=--+-No--+-'   
                    +-No------+               '-Yes-'     
                    '-Barcode-'                           

   .-WAITTime--=--60----.                                 
>--+--------------------+--+--------------------------+--------><
   '-WAITTime--=--value-'  '-CLEanings--=----number---'   

A (SEARCH=Yes, SEARCH=Bulk)

|--+-VOLRange--=----volume_name1,volume_name2---+---------------|
   |               .-,-----------.              |   
   |               V             |              |   
   '-VOLList--=--+---volume_name-+--+-----------'   
                 '-FILE:--file_name-'

Where SEARCH Specifies whether the server searches the library to find volumes that were not checked in. This parameter is optional. The default is NO. Possible values are:

 No
Specifies that only the named volume is checked into the library. For SCSI libraries: The server issues a request to have the volume inserted into a cartridge slot in the library or, if available, into an entry port. The cartridge slot or entry port is identified by its element address. For 349X libraries: The volume could already be in the library, or you could put it into the I/O station when prompted.

 Yes
Specifies that the server searches the library for volumes to be checked in. You can use the VOLRANGE or VOLLIST parameter to limit the search. When using this parameter, consider the following restrictions:
  • If the library is shared between applications, the server could examine a volume required by another application. For 349X libraries, the server queries the library manager to determine all volumes that are assigned to the SCRATCH or PRIVATE category and to the INSERT category.
  • For SCSI libraries, do not specify both SEARCH=YES and CHECKLABEL=NO in the same command.
Bulk
Specifies that the server searches the library's entry/exit ports for volumes that can be checked in automatically. This option only applies to SCSI libraries.

 Ex: checkin libvol TSMLIB search=bulk status=scratch 
       checkin libvol TSMLIB VOL007 status=private
Restrictions:
  • Do not specify both CHECKLABEL=NO and SEARCH=BULK.
  • You can use the VOLRANGE or VOLLIST parameter to limit the search.
Read: TSM Storage Pool Concepts (V7 Revised)

How to configure Tivoli Storage Manager (TSM) Tape Library with Multiple device type drives

00:25 No Comments
Tivoli Storage Manager supports both single device type drives & multiple device type drives  for example, a StorageTek L40 library contains one DLT drive and one LTO Ultrium drive. In this post we will see how to configure Tape Library with multiple device type drives in TSM environment.

How to Configure Multiple device type drives in TSM

  • Define a SCSI library named MIXEDLIB. The library type is SCSI because the library is a SCSI-controlled automated library. Use the following command:
        define library mixedlib libtype=scsi
  • Define a path from the server to the library. The DEVICE parameter specifies the device driver's name for the drive, which is the device special file name.
          define path server1 mixedlib srctype=server desttype=library device=/dev/lb3
  • Now, Define the drives in the library:
             define drive mixedlib dlt1
             define drive mixedlib lto1
  • Both drives belong to the MIXEDLIB library. This example uses the default for the drive's element address. The server obtains the element address from the drive itself at the time that the path is defined. The element address is a number that indicates the physical location of a drive within an automated library. The server needs the element address to connect the physical location of the drive to the drive's SCSI address. You can have the server obtain the element address from the drive itself at the time that the path is defined, or you can specify the element address when you define the drive. Depending on the capabilities of the library, the server may not be able to automatically detect the element address. In this case you must supply the element address when you define the drive. 
  • Define a path from the server to each drive. The DEVICE parameter specifies the device driver's name for the drive, which is the device special file name.
define path server1 dlt1 srctype=server desttype=drive library=mixedlib device=/dev/mt4

define path server1 lto1 srctype=server desttype=drive library=mixedlib device=/dev/mt5

 Read: Tape Library related Interview Questions

 If you did not include the element address when you defined the drive, the server now queries the library to obtain the element address for the drive.
  • Classify the drives according to type by defining Tivoli Storage Manager device classes, which specify the recording formats of the drives.
  • This is the important step, Do not use the DRIVE format, which is the default. Because the drives are different types, Tivoli Storage Manager uses the format specification to select a drive. The results of using the DRIVE format in a mixed media library are unpredictable.
        define devclass dlt_class library=mixedlib devtype=dlt format=dlt40
       define devclass lto_class library=mixedlib devtype=lto format=ultriumc
  • Verify your definitions by issuing the following commands
         query library
         query drive
        query path
        query devclass
  • Define storage pools associated with the device classes. For example:
         define stgpool lto_pool lto_class maxscratch=20
        define stgpool dlt_pool dlt_class maxscratch=20
  • Scratch volumes are empty volumes that are labeled and available for use. If you allow scratch volumes for the storage pool by specifying a value for the maximum number of scratch volumes, the server can choose from the scratch volumes available in the library, without further action on your part. If you do not allow scratch volumes, you must perform the extra step of explicitly defining each volume to be used in the storage pool.
  • Collocation is turned off by default. Collocation is a process by which the server attempts to keep all files belonging to a client node or client file space on a minimal number of volumes. Once clients begin storing data in a storage pool with collocation off, you cannot easily change the data in the storage pool so that it is collocated.
Read: IBM Spectrum Protect (TSM) Basic Free Tutorials
Subscribe to: Posts (Atom)