>>> "bob944" <bob944 at attglobal.net> 12/28/2006 9:01 AM >>>
> RE: bpexpdate, see below
> [...]
>
> > > > > EVEN after you fix the addressing
> > > > > issue! They MUST be EXPIRED first with
> > > > > bpexpdate -d 0 -m MEDIA_ID so they lose that
> > > > > information. If at any point you have an
> > > > > addressing problem and write to tapes, BE SURE
> > > > > that you EXPIRE ALL TAPES written to during
> > > > > that testing phase before you do more testing--
> > > > > after you ensure the address/scsi/acsls mapping
> > > > > is correct of course.
> > > >
> > > > Can you cite documentation for this?
> > > >
> > > Unfortunately not; the Veritas engineer confirmed my
> > > finding verbally.
> >
> > That _is_ unfortunate. I believe you have misinterpreted
> > the situation: there is no tie between a tape and a
> > physical drive, only the normal pre-6.0 ownership of
> > media by its media server as long as the media server
> > has images on it. Please advise if you do come up with
> > docs--perhaps a clarifying statement from your Veritas
> > contact--so I and the rest of the list can learn from it.
>
> Actually this is true and it is tied to the drive index
> number and has nothing to do with ACSLS.
The only place where the drive index is stored, AFAIK, is in the
FRAGMENT records in the backup's metadata file, as the "dwo" (drive
written on) field.
You've identified it, the "dwo" is the key. If your drive addressing
is mismatched from the start and you then discover the error, correct
it, that CAN result in changing the device drive number ASSOCIATED with the
device
path.
The "CAN" may be based on the how many drives are initially
mis-configured from the start. I've done this and when correcting the
problem, hopefully the below will illustrate the mismatch after a tape has been
written too:
Original Configuration:
drive 1 (aka dwo #1) /path 1 (correct)
drive 2 (aka dwo #2) /path 2 (incorrect, but not know at the time of
configuration)
drive 3 (aka dwo #3) /path 3 (correct)
drive 4 (aka dwo #4) /path 4 (incorrect, but not know at the time of
configuration)
Corrected Configuration:
Note: "dnwd" = data previously known to be written on/to device number (x) from
metadata info
drive 1 aka dwo #1 /path 1 (correct)
drive 2 aka dwo #4 /path 4 (corrected): dnwd = 4, which is now drive number 2
drive 3 aka dwo #3 /path 3 (correct)
drive 4 aka dwo #2 /path 2 (corrected): dnwd = 2, which is now drive number 4
Prior to correction the "dwo" assigned from the metadata to the first backup on
an
assigned tape is now recorded, after the drive number/path correction, the
metadata
from an assigned tape is now used to mount a tape again to the drive previously
used,
NOW, the incorrect drive and path previously used.
(Yes, your worst fears, actually working by design is correct.
Have you ever wondered why a tape will mount again and again to the same drive?)
(Metadata (non-dot-f) file information is used for a variety of functions and
processes.)
Wow. That idea implies a lot, doesn't it?
o that NetBackup requires a tape to be mounted on the same physical
drive each time. I'm not buying that--banks of interchangable drives
have been part of the datacenter since the days of 3-inch-wide tape.
(The above: You've been fortunate, you've maintained drive paths and
numbers in your change outs with or with out zoning)
(The below: not applicable as mentioned above)
o that you could never reconfigure your tape environment
o that you could never change out a tape drive
o that a drive could never be down
(The Below - With the metadata written to a mis-configured drive/path
configuration - YES, it wouldbbe upset)
o in the mis-configuration scenario we're talking about, that NetBackup
would later use the same drive index and for some reason be upset about
the different drive it found there
(Assumptions or worst fears were long ago resolved by taking the same pill Neo
chose)
> If the drives are incorrectly addressed, then backups
> are run, and then the drives are correctly addressed,
> those tapes previous written to will upon a next mount
> request will be mounted into the incorrect drive and
> result in an error.
Scott, I respect your testimony, but I've misconfigured many a drive and
never seen this. But beyond that, I have to question why "those tapes
previous[ly] written to will [...] be mounted into the incorrect drive
and result in an error." Wow. That idea implies a lot, doesn't it?
o that NetBackup requires a tape to be mounted on the same physical
drive each time. I'm not buying that--banks of interchangable drives
have been part of the datacenter since the days of 3-inch-wide tape.
o that you could never reconfigure your tape environment
o that you could never change out a tape drive
o that a drive could never be down
o in the misconfiguration scenario we're talking about, that NetBackup
would later use the same drive index and for some reason be upset about
the different drive it found there
o that if you had two drives and a hundred active tapes, and added ten
new drives, that the original two would be the only drives to get used
I don't believe any of those things are true. In a drive
misconfiguration, frozen media happen, down drives happen, but not those
above.
(Sorry, in the Veritas Matrix, swallowing the other pill can result in these
assumptions)
> I too have done this (more times than I care to think
> about) and when working with Veritas support received
> the same resolution (going back to 3.1) about using
> bpexpdate.
>
> I don't recall if there was any documentation about
> this at the time but I'm thinking that information may
> be stored in the non-dot-f file or in one of the DB's
> on the media server (/volmgr/database).
Yes, the metadata file's FRAGMENT records as mentioned above. I use the
dwo field information to track drive usage, troubleshooting and some
other statistics, but I'm unaware of any NetBackup use of it (anyone
know of any?).
(Once written, why not go back, the drive - that is -Veritas Crude - Drive
Gold, that is... )
I am intrigued by your and Justin's assertion, though. Didn't find
anything in 50 technotes I searched.
(Not to be found, they'll say RTFM, and then, as usual, open a case)
Can you supply more details on
what problem(s) you observed, after straightening out your drive
configuration, that forced you to expire the tapes? And, as with
Justin's assertion, my assumption is that you have overlooked
media-server ownership of assigned media--have your misconfigurations
been in multiple-media-server environments? In the original posting,
the claim was that bpexpdate -d 0 is necessary "so they lose that
information," but the only information that I can think of is
media-server ownership after the images are expired.
As I said, this is interesting since two people claim the same thing, so
if you can give me enough concrete information to work with, I'll
request some lab time to test it.
(I'm certain there are many in this forum who could much better articulate
their experience's in this topic/thread but, I'm going to opt out of this very
good and
interesting thread and say - welcome to the "real")
Scott
_______________________________________________
Veritas-bu maillist - Veritas-bu at mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
