Some strange tape related issues?

2006-04-08 Thread Farren Minns
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 

Re: Some strange tape related issues?

2006-04-08 Thread Richard Sims

Farren -

The kind of inconsistencies you're seeing are the kind I would expect
if your new TSM server db is stale or otherwise inconsistent with the
state of your production server.  This particularly shows up where
you have multiple TSM servers in any manner sharing the same
library.  There should have been a good db restoral as you went to
the new server today.  One quick way to check that is to do:

SELECT DATE_TIME AS "DATE   TIME
",TYPE,BACKUP_SERIES,VOLUME_NAME -
FROM VOLHISTORY WHERE TYPE='BACKUPFULL' OR TYPE='BACKUPINCR'

and check the date-time values for currency.

Richard Sims


Re: Some strange tape related issues?

2006-04-08 Thread Farren Minns
Hi Richard

I see the following which to me looks as I would expect and vol 000188 was
indeed the volume I used this morning. I did not see any errors during
backup or restore.

The only thing is that the database volumes on the new server had mirrored
copies already in place. These were stale when I started the server but
then syncd ok. Could this have caused a problem?

date               time
TYPE                                   BACKUP_SERIES            VOLUME_NAME
---
--                     -
--
2006-04-03 10:14:19.00-             BACKUPFULL
1912                             000193
                   
2006-04-04 09:40:02.00-             BACKUPFULL
1913                             000370
                   
2006-04-05 09:32:03.00-             BACKUPFULL
1914                             000413
                   
2006-04-06 09:59:45.00-             BACKUPFULL
1915                             000441
                   
2006-04-07 09:36:42.00-             BACKUPFULL
1916                             000488
                   
2006-04-08 10:05:48.00-             BACKUPFULL
1917                             000188
                   

Thanks

Farren
|-+---|
|   Richard Sims <[EMAIL PROTECTED]> |  
 |
|   Sent by: "ADSM: Dist Stor |   |
|   Manager"  | To|
|   |[EMAIL PROTECTED]|
| |U  |
|   08/04/2006 16:40  | cc|
| |   |
| Please respond to   |Subject|
| "ADSM: Dist Stor|Re: [ADSM-L] Some  |
| Manager"|strange tape   |
|   |related issues?|
| |   |
| |   |
| |   |
| |   |
| |   |
| |   |
|-+---|







Farren -

The kind of inconsistencies you're seeing are the kind I would expect
if your new TSM server db is stale or otherwise inconsistent with the
state of your production server.  This particularly shows up where
you have multiple TSM servers in any manner sharing the same
library.  There should have been a good db restoral as you went to
the new server today.  One quick way to check that is to do:

SELECT DATE_TIME AS "DATE       TIME
",TYPE,BACKUP_SERIES,VOLUME_NAME -
FROM VOLHISTORY WHERE TYPE='BACKUPFULL' OR TYPE='BACKUPINCR'

and check the date-time values for currency.

    Richard Sims


##
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.
##


Re: Some strange tape related issues?

2006-04-08 Thread Richard Sims

On Apr 8, 2006, at 1:20 PM, Farren Minns wrote:


Hi Richard

I see the following which to me looks as I would expect and vol
000188 was
indeed the volume I used this morning. I did not see any errors during
backup or restore.

The only thing is that the database volumes on the new server had
mirrored
copies already in place. These were stale when I started the server
but
then syncd ok. Could this have caused a problem?


Farren -

Unused mirrors should not be an issue, in that the unmirrored copy of
the database should be fully viable unto itself.  The Vary On which
performed synchronization just copies the primary image data.

You mentioned in your first posting today that the library was in
Pause mode for some reason when the new instance of the TSM server
was started.  The library needs to be viable when TSM goes to use it
at any time; and at start-up time, TSM is trying to do a lot of
communication with it, for volumes consistency checking.  Putting the
3494 back into Auto mode does not result in an audit, but rather a
library-specific Inventory check (depending upon library settings),
where the accessor runs around scanning storage cell and drive
contents.  Manually performing a TSM Audit Library may correct TSM's
knowledge of its volumes in the library.

I would use mtlib commands to get a list of the library tapes with
Category Codes reported, to assure that all volumes seem reasonable
and appropriate for use with the Library category code numbers as end
up in the new TSM server.  Presumably, your atldd driver is in good
shape on the new server (?) and the 3494's Library Manager has been
updated to allow access by the new server system?  (I expect so, but
want to assure that basics are not overlooked.)

The only other thing I could think of is that there may be some
architectural inconsistency which makes a db restoral type of server
transfer dubious or invalid, possibly one system being 32-bit and the
other 64-bit, for example.  I would pore over the Activity Log in the
new server looking for other problem indications.

  Richard Sims


Re: Some strange tape related issues?

2006-04-08 Thread Bill Kelly
Maybe I can chip in something useful on question #4 (then again, maybe
not...)

It looks to me as if the DB backup you took in step 4 was what you used
to restore the DB to the new server in step 11?  If so, then I think
that the fact that you did the 'move drm' in step 5, *after* the DB
backup was made will be lost when that backup is restored.  So I would
expect the "new" server to think that whatever tapes were involved in
the drm move offsite were still in the library...that's what its
database says.

Or do I misunderstand what's wrong in question 4?

Regards,
Bill

Bill Kelly
Auburn University OIT
334-844-9917
>>> Farren Minns <[EMAIL PROTECTED]> 04/08/06 9:05 AM >>>

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