Hi All
I have just moved my TSM Server 5.1.6.2 from a Solaris 7 server to a new
Solaris 9 box. Now, everything so far has gone fine and I have tested a
couple of backups and also a backup of the database.
When I look at the contents of the tapepool, copypool, q libv etc I see
what I would
OK, this is what I have now found out but had no idea what's going on.
After completely removing and redefining the lib,drives and paths I still
get the same errors as below. So, for example I can't audit volume 000700
without the error below.
BUT..., if I change the state of the volume from
Hi Richard
Well sadly for now I have had to revert to the old server again for
tonights backups. All I can do now is try and work out exactly what is
going on and try to have some kind of a plan to pre-empt this caveat.
As far as the Private and Scratch category goes, the new settings (within
I have a typical arrangement of a disk storage pool, that migrates to a
tape storage pool. Both storage pools have a MAXSIZE of 10G because we
simply don't want to back up files larger than that. They tend to pin
the log, they're a bear to manage, and usually they're some kind of
music or video.
Heh - I wasn't thinking about that many volumes, but it's good to
keep in mind. Thanks.
--- Andy Huebner [EMAIL PROTECTED] wrote:
Be careful with how many disk pool volumes you create. Each volume
uses
1 thread, add this to all of the other threads in use, our TSM
server
would die at
mtlib -l /dev/lmcp0 -q I
will show you the inventory categories for the tapes. You have to
translate it from HEX to check if it matches up with the TSM server categories.
This is probably not your issue, but I will document it here just in
case.
If you see a
Thanks Ben
For now I have brought the old server up again and everything is working
fine, so I am happy that the library is not doing anything silly (well,
reasonably happy).
I have been given a few pointers here to look at but sadly I think it will
be a case of trying this all again next weekend
