ADSM-L

Some strange tape related issues?

2006-04-08 10:21:46
Subject: Some strange tape related issues?
From: Farren Minns <fminns AT WILEY.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sat, 8 Apr 2006 15:05:52 +0100
Hi all

I'm sorry for all the questions that follow, but the level of help I get
from this board is outstanding.

I've been trying to move my TSM Server 5.1.6.2 install from one sun server
to another and today had the second attempt, but I came across some odd
things that made me too paranoid to go ahead (again), when I have a fully
working server to fall back on.

Question 1 (I have only discovered this after attempting to move to the new
server and then moving back)

On the 22nd of March I labelled 10 brand new 3590s, I can see this in the
vol hist. The first 7 of those 10 have already been used (filling) and
there are three remaining that so far have not been touched. Now, I noticed
a strange thing when I issued the q libv command is that those last three
volumes are listed as DbBackup.

3494A          000867        Private
DbBackup
3494A          000868        Private
DbBackup
3494A          000869        Private                   DbBackup

Now, if I do a q vol stg=tapepool status=empty I do see those three
volumes, and other as I would expect.

Volume Name
Storage              Device              Estimated            Pct
Volume
                                          Pool Name            Class
Name           Capacity           Util           Status
(MB)
------------------------          -----------          ----------               
   ---------                  -----          --------

000662                            TAPEPOOL
3590CLASS1             0.0                    0.0           Empty
000686                            TAPEPOOL
3590CLASS1      0.0                    0.0           Empty
000704                            TAPEPOOL
3590CLASS1      0.0                    0.0           Empty
000705                            TAPEPOOL
3590CLASS1      0.0                    0.0           Empty
000861                            TAPEPOOL
3590CLASS1      0.0                    0.0           Empty
000867                            TAPEPOOL
3590CLASS1          0.0                    0.0           Empty
000868                            TAPEPOOL
3590CLASS1          0.0                    0.0           Empty
000869                            TAPEPOOL             3590CLASS1
0.0                    0.0           Empty
000893                            TAPEPOOL
3590CLASS1      0.0                    0.0           Empty

I can see in the activity log that all ten volumes were labelled correctly
and I have done nothing to change them, so any ideas what I'm seeing here
and why?


Question 2 - part 1

After restoring the TSM database to the new server and starting it, I got a
load of the following messages :-

04/08/06 12:41:30             ANR8455E Volume 000155 could not be located
during audit
                                       of library 3494A.  Volume has been
removed from the
                                       library inventory.

Now, most of these were scratch volumes, but seeing as the Library had been
paused and set to auto again (at which point it does an audit), and seeing
as now I have reverted to the old server connected to the same library and
TSM can see all the tape volumes fine, why could the new server not. I got
as far as this part of the test time and then TSM still new all about the
scratch tapes. So what might be different this time?

Question 2 - part 2

Following on from above, the new server also complained that it could not
see two tapes from the tapepool. But the tapes are present and again, back
on the old server I can see/audit them fine. What's going on?

Do I just need to delete the lib/drive/path definitions, recreate and then
checkin the lib volumes, or should I be wary of that if something in the
tape inventory is a bit off?

Question 3

Following on from above, I get very paranoid that I'm going to do something
to knacker the actual library inventory, over write tapes that do not want
to be overwritten etc, and I want to safe guard this to make sure it
doesn't happen.

I have upped the reuse delay from 2 to 5 days for the tapepool and I'm
assuming that nothing I do on TSM with regards to removing recreating
drives/lib/paths, checkin libv/audit etc will directly effect that, but is
there anything I should be wary of doing here? I don't want to do ANYTHING
that would make it impossible to go back to the old server within the first
few days (hence the 5 day reuse delay).

Question 4

For this question I need to tell you the sequence of events.

1) Allow backups to finish
2) Create offsite volumes
3) Migrate all data from the backup pool (caching is off)
4) Backup the DB
5) Move the drm to offsite location = vault
6) Prepare the drmplan and move off site also
7) Halt TSM Server
8) Shut down physical server
9) Connect new server to the library and drives used above
10) Boot and check drives etc are seen
11) Restore the DB to the new server
12) Start TSM

Now, as well as all the scratch tapes it can't see and the two from the
tapepool, it also says that it can no longer see the off site tapes that I
created earlier this morning, even though they were moved off site and the
status of those volumes changed to vault. TSM knew they had been removed
from the library so why is it trying to see them 'in' the library now?

The command I use to move the volumes is as follows :-

move drm * wherestate=mountable tostate=vault remove=bulk

Again, I'm sorry for the lengthy prose, but i thought it best to be as
verbose as possible.

All the best

Farren Minns
John Wiley & Sons Ltd



######################################################################
The information contained in this e-mail and any subsequent 
correspondence is private and confidential and intended solely 
for the named recipient(s).  If you are not a named recipient, 
you must not copy, distribute, or disseminate the information, 
open any attachment, or take any action in reliance on it.  If you 
have received the e-mail in error, please notify the sender and delete
the e-mail.  

Any views or opinions expressed in this e-mail are those of the 
individual sender, unless otherwise stated.  Although this e-mail has 
been scanned for viruses you should rely on your own virus check, as 
the sender accepts no liability for any damage arising out of any bug 
or virus infection.
######################################################################