Admin schedules:

Adminstrative schedules are used make sure that there is a continuity in Backup cycle .

Order of Admin schdules plays a very important role

Backup client data and ensure backups are complete in time

Backup of storage pools
TSM database backup
Backup of devconfig / volhist
DRM movement of tapes eject offsite volumes and insert scratches
Generate the DRM file
Send the drm media and plan offsite
Expiration on DB
Reclamation
Migration

Backup client data Schedule the backups in a proper manner and ensure the backups
are completed in time.
Daily incremental backups
Weekly backup for the faster restores
Log and archive backups should go to the right storage pools in case of LAN free
environment
Make sure to cancel the reclamation or any admin schedule process before backup
schedule start

Backup of storage pools

We can backup multiple storage pools to the single copy pool.
We can backup the storage pools simultaneously at the same time

TSM DB Backup

DB backup plays a very important role

Without the information stored in the database, it is impossible to restore or recover the
data that has been backed up or archived.
This is why it is essential that you backup database frequently
Types Full , Incremental , Snapshot

Full never been backed up ,more 32 incrementals , db is extended or reduced , Log

mode is changed

If you are in roll-forward mode you should consider the size of the recovery log.
In this mode, the recovery log keeps all transactions since the last database
backup and normally requires more space than normal mode does.
We can make use of dbbackup triggers to avoid the out of space in recovery logs
Define DBBackuptrigger DEVclass=devclassname LOGFullpct=percentage
( 50% default ) NUMINCremental=number (6 default)

Snapshot backups can be used during Disaster recovery . It can be used for Point in
restore but not for most recent backups
It will not affect normal incremental series
It will not flush the recovery log space

Proper estimation about the sizes of recovery log and DB log need to be considered.
Make use of DBB triggers and space triggers
Mirroring on Recovery log can help in case of media failures and it does not require more
space
DB backups on scratches
If your backups are stored on site, and you suffer from a disaster, your backups are likely
to also be destroyed. Make sure that your database backups are safe.
For those sites that are running operations 24 hours a day, the database mirroring feature
is the only way to protect against a database media failure.
Schedule database backup immediately following storage pool backup
Use Disaster Recovery Manager to automate the recovery of the TSM database

Prepare commad generate the DRM file which contains

Recovery Procedures
Database and storage pool information
Hardware information

Server option file

Device configuration
Volume history file

Best practices make a proper naming convention while you prepare for a DRM

If you do not have a DRM plan schedule the admin schedules to take backup of
Device configuration file and volume history file
It just take the backup of these file or refreshes the file by reading the database to have a
proper sync

Have a proper script to automate the DRM Media movements and to send the offsite
volumes .

Expiration

To have a proper sync and bound with management classes defined on client data
Runs on db, to remove the metadata of obsolete versions .
exp interval 12 ( dsmserv.opt, if 0 - default automated, admin schedule, server restart ,
command manually by expire inventory )
duration parameter
it requires tables in db

MIGRATION

Moving data from one stg to other stg pool

If a migration or reclamation process is already running for the storage pool, you cannot
start another migration process for the storage pool.
To avoid deadlock situation

MIGDELAY - eligible for migration

most space in a storage pool is selected first for migration.
Also which are not accessed for a long time

MIGCONTINUE - migrate even if it in not eligible

MIGPROCESS - no of process to be run when migration is started
HIGHMIG 100 to prevent automatic migration
Cache - yes, maintain

To prevent automatic migration from running, set HIGHMIG attribute of the storage pool
definition to 100.

3 types

manual

admin schedule
update stg stgpoolname hi=0 low=0
but we need to update back to the values

using migrate stgpool but only on primary storage pools

MIGrate STGpool pool_name LOwmig=number DUration = minutes

REClaim = No or Yes

RECLAMATION
We can reclaim unused space or

This makes the original volume available for reuse.

Reclamation will not move inactive versions of backup data from volumes in active-data
pools.
RECLaim STGpool pool_name THreshold=number DUration=minutes
Or
upd stgp tapepool reclaim=80

Reclamation run on stgpool

Parallel
It allows commands in script to run parallelly
Privilege class
Any administrator can issue this command.
Syntax
>>-PARALLEL----------------------------------------------------><

SERIAL
Use this command in a script to ensure that any preceding commands are
complete before proceeding and to ensure any following commands are run
serially.
When a script starts, all commands run serially until a PARALLEL command is
encountered.
Privilege class
Any administrator can issue this command.
Syntax
>>-SERIAL------------------------------------------------------><

Return Code
The script return code following a PARALLEL command will be the same as the
script return code prior to the PARALLEL command. When a SERIAL command
is encountered, the script return code will be set to the maximum return code from
any previous commands run in parallel.

WAIT parameter after a PARALLEL command, the behavior is as follows:

If you specify (or use the default) WAIT=NO, your script will not wait for the
completion of the command when a subsequent SERIAL command is
encountered and the return code from that command will reflect processing only
up to the point that the command starts a background process. The final return
code from the command will not be available to your script.
If you specify WAIT=YES, your script will wait for the completion of the
command when a subsequent SERIAL command is encountered and the return
code from that command will reflect processing for the entire command.

Example

/*run multiple commands in parallel and wait for them to complete before
proceeding*/
PARALLEL
 /*back up Three storage pools simultaneously*/
BACKUP STGPOOL PRIMPOOL1 COPYPOOL1 WAIT=YES
BACKUP STGPOOL PRIMPOOL2 COPYPOOL2 WAIT=YES
BACKUP STGPOOL PRIMPOOL3 COPYPOOL3 WAIT=YES
/* wait for all previous commands to finish and set up running serial commands*/
SERIAL
/*after the backups complete, migrate stgpools simultaneously*/
PARALLEL
MIGRATE STGPOOL PRIMPOOL1 DURATION=90 WAIT=YES
MIGRATE STGPOOL PRIMPOOL2 DURATION=90 WAIT=YES
MIGRATE STGPOOL PRIMPOOL3 DURATION=90 WAIT=YES
/*wait for all previous commands to finish*/
SERIAL
/*after migration completes, relcaim storage pools simultaneously*/
PARALLEL
RECLAIM STGPOOL PRIMPOOL1 DURATION=120 WAIT=YES
RECLAIM STGPOOL PRIMPOOL2 DURATION=120 WAIT=YES
RECLAIM STGPOOL PRIMPOOL3 DURATION=120 WAIT=YES

Reuse delay Paramater Choose this value > or = to DB expiry

It is specified in days and can be applied individually to primary sequential and

copy storage pools (in other words storage pools that handle tapes).
The reuse delay parameter is used to define how long a tape will stay in a pending
state.
Tapes that are empty but not yet available to be used as scratch tapes have a status
of PENDING

Why do we need this parameter?

This parameter is used to ensure that if you had to restore your TSM Database to
a previous days backup that the tapes will be in a consistent state with the TSM Database
as at the point of the restore.

Example

To Illustrate this, assume that the reuse delay parameter is set to 0 so that tapes become
scratch tapes as soon as they are empty.

Monday
A TSM Database Backup is taken on Monday
Tape A1 currently has data for Node ZZ

Tuesday
 The data for Node ZZ on tape A1 expires and because the reuse delay parameter is set
to 0 tape A1 becomes a scratch tape
Tape A1 is now immediately used to backup node YYs data

Wednesday
For some reason, you have to restore to the last TSM database backup which was
taken on the Monday.
Because the database is now running as at Monday TSM believes that tape A1 holds
the data for Node ZZ. A decision is made to restore data for Node ZZ which resides
on A1 and TSM complains that the volume is corrupt because the data on the tape is
not what TSM is expecting. In this case if the reuse delay parameter had been set to 2
days then tape A1 would not have been written on and the restore would work as
expected.

Command

Update STGPOOL STGPOOL_NAME REUSEDELAY=days

Where STGPOOL_NAME is the name of the storage pool and days is the value for
the REUSEDELAY parameter
Example - for 2 days
UPDATE STGPOOL TAPEPOOL REUSEDELAY=2

Best practices using the scripts : Automate the admin schedules using the scripts and
generate the reports .

Media management using scripts

Daily health using scripts
Cancelling the process before backup window starts
Send the DRM plan file to all mail ids
Notify the user when server is down or any if any thing goes wrong on the TSM server
end
Mail the appropriate user with log details when the back up fails

Canceling Process

For example Reclamation or Migration process before the backup schedule

window

UNIX

Explanation : TSM has the list of tables . AWK is used to capture the process number
that need to be cancelled

To complete the script:

PROC=`dsmadmc -id=userid -password=user_password -dataonly=yes "q
proc" | grep "Space Reclamation" | awk '{print $1}'`

dsmadmc -id=userid -password=user_password -dataonly=yes "cancel

$PROC"

Windows - The batch file you have to create must be in c:\Program

Files\Tivoli\TSM\baclient

Using batch file

@echo off
IF EXIST OUT DEL OUT
dsmadmc -id=USERID -password=PASSWORD "q process" | findstr "Space
Reclamation" | awk '{print $1}' > IN
GSAR -s, -r -f IN OUT
IF NOT EXIST OUT ( COPY IN OUT)
ELSE
(ECHO > NUL)

for /F %%i in (OUT) do dsmadmc -id=USERID -password=PASSWORD "cancel

process %%i"

Cancelling All Process Using the while loop

dsmadmc -se=myserver -id=myadmin -pa=mypw -dataonly=yes "select process_num

from processes" | while read procnum
do
dsmadmc -se=myserver -id=myadmin -pa=mypw can proc ${procnum}
done

Sending Mails In case of TSM server is down notify the TSM admin
Using return code or dsmserv process

# Check every five minutes to ensure that the TSM application is running
00,05,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/serverup_check

#########
dsmadmc -id=xxx -pass=xxx 'quit'
#Whether the server is up or down it will return you to the
#prompt
# Now test the return code
if [ $? != 0 ] ;
then
mail -s "TSM IS DOWN" you@domain.com
Fi
#########

In many cases

Health checks
IMP files
DB status

Other Best Practices

Sending Tapes to offsite with an encryption to have more safety

Having 2 copies of data
Make sure of enough scratches
Shredding the data