Veritas-bu

Re: [Veritas-bu] Problem with volumepool !!

2007-06-23 17:11:54
Subject: Re: [Veritas-bu] Problem with volumepool !!
From: "bob944" <bob944 AT attglobal DOT net>
To: <veritas-bu AT mailman.eng.auburn DOT edu>
Date: Sat, 23 Jun 2007 16:45:57 -0400
>       I have faced this problem twice but still not able
> to get its root cause.
> Problem
> ------------
> *     Medias automatically getting assigned to different
> Volumepool (WEEKLY_CDL)even though they are new tapes with
> SCRATCHPOOL as vol pool.

That's the way it's supposed to work if I understand you correctly.  See
below.

> *     I cant change the vol pool nor I can delete the
> media manually.
> *     Then I tried the following sequence of steps
> *           # bpexpdate -ev <mediaID> -d 0
> *           Eject the media.
> *             Delete the media from media catalog.
> *             Inventory the robot.
> *     Then I was able to change the Vol pool to
> SCRATCHPOOL .
> *     But during this time one vault was in progress. An
> it vaulted backups which had the same volume pool(
> WEEEKLY_CDL). Is this the cause of problem ?But we usually
> fire the same vault but donot face the problem 

You might not get much response on a weekend, so here goes:

I don't understand your setup nor the sequence you describe above, so
I'll just reduce it to "tapes show up in WEEKLY_CDL and I don't know
why."

One likely possibility is that someone has set up the inventory rules on
the robot to assign new media to the WEEKLY_CDL pool.  By default, new
media go to the NetBackup pool.  See "Volume Configuration for a Robot"
in the NetBackup Media Manager System Administrator's Guide.

In any event, quit deleting media.  The only time most NetBackup users
should delete media is when it will never be used in that environment
again (it's going to be destroyed, used in another environment forever,
...) and you then have no reason to ever know again that it even
existed.  If you quit deleting tapes, all the inventory process does is
recognize a volume that it already knows about and change its
location--that's all that needs to be done.

Understand that once all images on a tape expire (naturally or through
your bpexpdate -d 0), it will return to its previously assigned pool
(since maybe release 4.5... certainly since 5.0).  Since most people put
new tapes in, say, Scratch, and Scratch is marked with the "scratch
pool" attribute, a backup that needs a new tape will draw it from
Scratch, it gets changed to "weekly_cdl" or whatever, and when the
backups expire, it reverts to the Scratch pool.  Remember that it
reverts to the _previously assigned_ pool, which may not be the scratch
pool.

To sum up, regarding your original "how do these volumes get into
WEEKLY_CDL" point, I guess:
o  your robot inventory rules put new media there
o  a class is drawing a tape from scratch and assigning it to WEEKLY_CDL
o  some other person or process is changing the pool
o  you never successfully expired a tape and moved it to your scratch
pool
o  the tape was manually assigned to WEEKLY_CDL and, when Changed to
another pool and used, reverts to WEEKLY_CDL when expired

Whatever the reason, move a tape through your processes and track its
status in the GUI or from the command line to see the behavior.


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

<Prev in Thread] Current Thread [Next in Thread>