One caveat to this all, don't confuse the volume expiration date, part of
the VolDB & visible with the vmquery command, with the media expiration
date. The the VolDB setting is the date that the tape is too old to continue
to be used (not set by default).  The latter is the date that the last image
will expire from the tape, ie: all retentions fulfilled.  It is visible
using bpmedialist.

I'll agree, though, avoid using "-deassignbyid".  It modifies only the VolDB
without concern for the ImageDB or the MediaDB.  If you're using this option
without proper care, you're going to cause mismatched databases between your
VolDB host (usually your master server) and your distributed databases on
your media servers.  If you cause mismatches, you can start to write off
your ability to restore files which, of course, is really the name of the
game.

bpexpdate is the proper tool to expire any uneeded images on tapes.  You can
determine if there's images on a tape with bpmedialist or bpimmedia.  It
helps, sometimes, to determine the media server assigned to the tape.  (I
think v4.x fails these commands if the media server isn't either your
current server or if it isn't supplied on the command line.  v5.x, I know,
does a lengthy search of the media servers to find needed information for
bpmedialist).

The tape should automatically return to the scratch pool if it once
originated there.  I think NB uses the previous pool field in the VolDB.  If
you've got an environment that's been migrated from from v3.x or you
implemented Scratch pools after setup, then there's a chance that you've got
tapes with won't automatically return to the Scratch pool since their
previous pool isn't "scratch".  I find these & manually move them to the
scratch pool with a daily script.  Even if the tape *should* return to the
scratch pool, this isn't instantaneous with expiration, being managed by a
NB on a periodic basis.

I set my offsite return date to be the same as the media (image) expiration
date.  The tapes returned from offsite are either expired on their arrival
or will expire within hours of their return.  If you pull them back before
that date, I'd suggest either shelving them until they expire or just stuff
them in the library in their current state and let them expire normally.
Using bpexpdate, in my opinion, means you didn't plan well.

HTH - Mark

-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of Martin,
Jonathan (Contractor)
Sent: Monday, December 19, 2005 7:56 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Media Experation


N00b question here I know, but what sets the media expiration date?  I'm
taking over a Netbackup 5.1 environment and we seem to have a load of
issues with media never expiring / having to vmquery -deassignbyid to
get stuff to go back into the scratch pool.  I'd say the GUI is useless
for 80% of my media returns from offsite.

-Jonathan

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu