Re: [Veritas-bu] Status 96 media allocation issues
2008-03-26 02:10:18
Mark.Donaldson AT cexp DOT com wrote:
> Still, all you should have to do is "bpexpdate" the tape number and the
> tape should be reusable.
>
That has worked in the past. It just seems to be this one batch had
problems.
> deassignbyid is a bit of a big hammer to use casually. I'd do:
>
> bpexpdate -d 0 -m <tapenum> -force
> ..then a...
> bpexpdate -deassignempty -m <tapenum> -force
> ..this'll make the tape available sooner..
>
I'll look into using these. The deassignbyid came up for a reason at
some point. I think it was because a policy would pull a tape from the
scratch pool and not the archive pool it was supposed to. It seems this
was needed before it would let us move the tape from the archive pool.
It's legacy and can probably be removed. I'll try the "-force" options
with these and see how they do.
> Loaded every tape, then requested a new one? I've seen this on
> write-protected tapes and on physical drive errors. If it loads the
> tape, finds it unusable for some reason, it'll dump it and request a new
> one. Did some enthusiastic tape monkey write-protect all your tapes?
I wondered about them being write protected because I wasn't sure how
they may have been put into the boxes for Iron Mountain. I was told by
the local guy that he verified the tapes are not write protected. It
seems something still has the VSN recorded somewhere or something like
that. The local person had some blank tape labels. When he put them on
the tapes and scanned them into the library, everything was fine. The
nightly backups started using them. It isn't the ideal solution but it
works for now.
I'm out of town working on another project and will try and re-visit
this next week sometime.
Thanks for all the help.
Jeff
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
|
|