----- "yoda woya" <yodawoya AT GMAIL DOT COM> wrote:

> From: "yoda woya" <yodawoya AT GMAIL DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Sent: Sunday, 14 March, 2010 2:47:10 PM
> Subject: [ADSM-L] assessing the health TSM installation
>
> if I were to be looking  to assess the health of TSM, what would be
> the  top
> things to look for

off the top of my head (we use a template for this at the office):
- database backups are frequent enough and allow for the desired recovery point 
of the organisation
- copy pools and database backups are sent off site (i.e. not left in the 
library or in a cardboard box beside it)
- performance bottlenecks (there's a client and server commands to check this)
- spread of tapes - if a restore needs 100 tape mounts then it's not going to 
be acceptable
- daily maintenance routines, is everything getting done or is something 
missing (maybe expiry never gets done or something like that)
- where is the time of the administrator spent, is there a better way to 
achieve the same result?
- what's the history of the installation - has it suffered downtime issues from 
something, etc?
- what's the organisational goals for TSM - do the copygroup settings match 
that, is there wasted space or is data getting missed?

Often I come across installations that are great except for a few minor config 
settings that prevent perfect operation - pulling tapes out of the library from 
the primary stgpool without setting an overflow location, or not setting 
reusedelay on copy pools.