ADSM-L

Re: Update - Tape problem after moving TSM to new server

2006-03-27 05:41:47
Subject: Re: Update - Tape problem after moving TSM to new server
From: Farren Minns <fminns AT WILEY.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 27 Mar 2006 11:36:38 +0100
Hi Ian

I only deleted and recreated the library, drives and paths, but I did not
touch the 3590 Device Class. Do I need to remove and recreate that too? If
I do this, how will it effect the tapepool & copypool that this device
class specified?

I actually printed screen dumps of the drives etc before removing and
recreating to make sure that they were the same (apart from the
/dev/rmt/???? entry of course). As far as I know, no special declarations
of device class are made during the addition of drives/libs/paths etc
anyway.

I did not do a manual audit of the library? But i figured that as it could
use scratch tapes and audit volumes that were full or filling (readonly),
things were already OK. I could be wrong.

Thanks

Farren
|-----------------------------+-------------------------------------------|
|   "Smith, I (Ian)"          |                                           |
|   <Ian.Smith AT RABOBANK DOT COM>  |                                          
 |
|   Sent by: "ADSM: Dist Stor |                                         To|
|   Manager"                  |                  ADSM-L AT VM.MARIST DOT EDU    
 |
|   <ADSM-L AT VM.MARIST DOT EDU>    |                                         
cc|
|                             |                                           |
|   27/03/2006 11:00          |                                    Subject|
|                             |                  Re: [ADSM-L] Update -    |
|         Please respond to   |                  Tape problem after moving|
|         "ADSM: Dist Stor    |                  TSM to new server        |
|             Manager"        |                                           |
|      <ADSM-L AT VM.MARIST DOT EDU> |                                          
 |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|-----------------------------+-------------------------------------------|











Did you make any changes to mountlimit or format on the device classes?
When you recreated the drives and paths after the migration did you bind
them to the correct device class/device type?

After the migration did you audit the library?

_____________________________
Ian Smith
SAN/TSM Specialist
IT Infrastructure
Rabobank International
Thames Court, One Queenhithe
London EC4V 3RL
t: +44 (0)20 7809 3046
f: +44 (0)20 7809 3599
m: +44 (0)7843 689914
Mailto: ian.smith AT rabobank DOT com


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Farren Minns
Sent: 27 March 2006 10:48
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Update - Tape problem after moving TSM to new server

Good morning Roger

Thank you so much for that information. Backing out wasn't a big problem
for me as the old server was still left as it was so all I had to do was
connect the drives and lib again and bring it back up (phew).

This is a very annoying problem though. Surely TSM should be able to see
that even though the /dev/rmt/???? entry has changed, it's still the exact
same device type and that it should still be able to write to the volume/s
in question. Is this something that is 'working as designed' or a
bug/fault?

Also. It's odd that I could not even audit any of the filling volumes until
I changed the state to readonly. BUT, TSM could happily write to scratch
tapes that had been labelled on the old server.

I really don't know why this should be? I have certainly not seen this in
any documentation.

Thanks again

Farren
|-----------------------------+-------------------------------------------|
|   Roger Deschner            |                                           |
|   <rogerd AT UIC DOT EDU>          |                                         
  |
|   Sent by: "ADSM: Dist Stor |                                         To|
|   Manager"                  |                  ADSM-L AT VM.MARIST DOT EDU   
  |
|   <ADSM-L AT VM.MARIST DOT EDU>    |                                         
cc|
|                             |                                           |
|   26/03/2006 18:54          |                                    Subject|
|                             |                  Re: [ADSM-L] Update -    |
|         Please respond to   |                  Tape problem after moving|
|         "ADSM: Dist Stor    |                  TSM to new server        |
|             Manager"        |                                           |
|      <ADSM-L AT VM.MARIST DOT EDU> |                                         
  |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|-----------------------------+-------------------------------------------|








This happened to me too, when doing a similar migration. I looked up my
notes from the time.

The problem is that your Filling tapes were started on a different drive
type than you have now, and so it won't append any more data onto them.
(Even if they are the very same drives, this can still happen.)

How to deal with it:

1. Get some extra tapes, to use while you do the following steps. Before
you do anything else after the big change, LABEL LIBVOL these new tapes so
there will be something for migration and DB backup to use.

2. Mark all your Filling and Full tapes Readonly. You will still be able to
restore from them OK. If you don't already have it, set a REUSEDELAY of a
day or two.

3. The Full tapes should reclaim themselves normally. However, reclamation
will not select any tape that is still marked as Filling, so you've got to
reclaim them manually yourself with MOVE DATA. Might take a while, which is
OK as long as you don't run out of tapes.

4. As tapes are cleared, whether they had been Filling (via MOVE DATA) or
Full (via reclamation), you may need to do CHECKOUT LIBVOL on them followed
by a LABEL LIBVOL OVERWRITE=YES before it will reuse them as scratch tapes.
When you get a mixture of Pending tapes from before and after the big
change, then you can easily tell which ones you need to relabel - they will
be the ones that are both Pending and Readonly.

When this happened to me, it was a hassle, but I found that it was a
manageable hassle. I did not have to do anything as drastic as the backout
you did. Sorry to hear about that - because you are having to do
3 times the work with a migrate-backout-migrate cycle.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu



On Sat, 25 Mar 2006, Farren Minns wrote:

>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 read/write to
>readonly, I can. What's that all about? I can also audit volumes that
>have an access
of
>read/write but that are 'full' and not 'filling'. This is very strange.
Has
>anyone else ever seen this behaviour before ?
>
>Many thanks again
>
>Farren Minns
>
>
>>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 expect.
>
>>BUT, when I try to run migration from disk to tape there is a problem.
>>In
>this example tape 000700 which is in a filling state is required but I
>see the following error :-
>
>>ANR1000I Migration process 4 started for storage pool BACKUPPOOL.
>>ANR8447E No drives are currently available in library 3494A.
>>ANR1401W Mount request denied for volume 000700 - mount failed.
>
>>Instead, TSM loads a new scratch tape and then continues fine. What is
>going on here? Has any body seen this before?
>
>>Thanks in advance
>
>>Farren Minns
>
>
>######################################################################
>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.
>######################################################################
>


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

This email (including any attachments to it) is confidential, legally
privileged, subject to copyright and is sent for the personal attention of
the intended recipient only. If you have received this email in error,
please advise us immediately and delete it. You are notified that
disclosing, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. Although we have taken
reasonable precautions to ensure no viruses are present in this email, we
cannot accept responsibility for any loss or damage arising from the
viruses in this email or attachments. We exclude any liability for the
content of this email, or for the consequences of any actions taken on the
basis of the information provided in this email or its attachments, unless
that information is subsequently confirmed in writing. If this email
contains an offer, that should be considered as an invitation to treat.
_____________________________________________________________


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