What's actually happening here is that NBU is finding a tape without a
NBU header when it's expecting to find a NBU header.

ALLOW_MEDIA_OVERWRITE is used when NBU encounters a tape which it does
not expect a NBU header on and finds a format that it DOES recognize
(an unrecognized header would be basically the same thing to NBU as a
blank tape).

Therefore, in your situation, NBU is loading a tape which it expects
to have been previously labelled by NBU, but what it finds is
something else (ANYTHING else, it doesn't matter what).  There are two
main causes for this:

1) Drive paths are incorrect.  So when NBU thought it was writing to
   ABC123 it was actually writing to XYZ456.  Now, later when it
   mounts ABC123 "again" (in a properly configured drive) it
   encounters a blank tape (the "real" ABC123 having never been
   used).  

2) Tapes have been moved around without running an inventory update in
   NBU.  Same thing happens as above.

First thing to do would be to confirm that drive configuration is
correct.  Empty all drives, then use tldtest (or acstest if you're
using ACSLS) to (physical) drive one.  Use 'mt status' to determine
which device file corresponds to that drive.  Ensure that NBU drive
configuration matches.  Unload tape TO ORIGINAL SLOT.  Repeat for all
drives.

Next, one at a time load all tapes into drives.  With exactly one tape
loaded, use vmoprcmd to determine what the interal tape label (RVSN)
is.  The RVSN is the same as the mediaID, and you can't change either
one.  You can use vmchange to change the barcode associated with that
mediaID to reflect the physical barcode, but the correct solution
would be to actually change the barcode to match the RVSN.

> Good point Chris, but:
> 
> 1) from bp.conf
> ALLOW_MEDIA_OVERWRITE = TAR
> ALLOW_MEDIA_OVERWRITE = ANSI
> ALLOW_MEDIA_OVERWRITE = CPIO
> ALLOW_MEDIA_OVERWRITE = AOS/VS
> ALLOW_MEDIA_OVERWRITE = DBR
> ALLOW_MEDIA_OVERWRITE = MTF1
> 
> 2) Some of the media volumes used, were expirated medias from the local
> mediaserver, other ones new volumes.
> 
> 3) I have +/- 16 frozen tapes in the last 30 days!!!
> 
> More ideas?
> 
> Thanks
> 
> Javier
> 
> Chris Costa <chris.costa AT veritas DOT com> wrote:
> > The "Non NetBackup Data"  for tape label LVP035 comments in the log you
> sent
> > is the issue. It appears that there is data on this tape that NBU does not
> > recognize and NBU freezes the tape to ensure that it does not get written
> > to. In the Media Section of the Master Server properties, select the option
> > to overwrite the various data formats and NBU will overwrite this tape.
> > 
> > Christopher C. Costa
> > Certified Sr. Veritas Consultant
> > Cell: (516) - 375 - 9631
> > NASDAQ: VRTS
> > 
> >  -----Original Message-----
> > From:       jago [mailto:javier.graf AT usa DOT net] 
> > Sent:       Thursday, July 17, 2003 10:32 AM
> > To: veritas-bu AT mailman.eng.auburn DOT edu
> > Subject:    [Veritas-bu] Problem frozing second tape on backups
> > 
> > Hi nbu's
> > 
> > I have a problem (just another one!)
> > 
> > Enviroment:
> > 
> > HP-UX 11.11
> > HW N Class > 2 proc & > 1 GBRam
> > all FC
> > Robot Tape Library all = L700 STK each w/ 12 LTO1 tape devices
> > 
> > When a backup runs and try to mount a second tape for a backup (and only in
> > none SSO devices), I become the following error:
> > 
> > > 1058439400 1 132 16 testzm006 68165 0 0 testzmb30b.testros.com bptm
> > tapemark
> > or blank tape encountered reading media header, drive index 10
> > > 1058439400 1 132 16 testzm006 68165 0 0 testzmb30b.testros.com bptm non
> > NetBackup media found in drive index 10, FREEZING LVP035
> > > 1058439737 1 132 16 testzm006 68165 0 0 testzmb30b.testros.com bptm
> > FREEZING
> > media id LVP416, External event caused rewind during write, all data on
> > media
> > is lost
> > 
> > Than media is frozen and backup .......
> > 
> > 
> > Any ideas?
> > 
> > TIA
> > 
> > Javier González
> > DATASEC Software GmbH
> > 
> > 

-- 
Larry Kingery 
            ...Every morning is the dawn of a new error...