Of course I have another problem with this. I only have 1 frame of a
3494 and not many free slots. If I set all the filling tapes to readonly,
after the next backup TSM will grab 36 brand new tapes (as I have
collocation on in the library, 1 for each client).
So realistically I would have to turn collocation 'off' for a period of
time in order to move the data off the filling volumes and then turn it on
again as and when I'm sorted.
Does anybody know of any problems with turning collocation off and then on
again other than slower restores.
Thanks
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.
######################################################################
|
