If the bpexpdate does not unassign a tape and it still shows assigned,
And the images on media report has nothing in the database then there
May be a volume database conflict?
We had a situation where we had a UNIX media server and Win 2003 media
server / master server - Controlling the same robot -
I found a situation where I could not use bpexpdate - it said tape not
Found in database - then reports images on media showed nothing,
The only way I could "per Veritas support was using the deassignbyid"
That worked - But what was the real issue was that the UNIX admin had
Pointed the VOLMGR database to his UNIX server so we had 2 volume database
Hosts -
In the robot properties, the volume database host needs to be set to the
Master server regardless of the media server, they all should point to the
Master server as the volume database host. If not there could and will
Be issues, including unable to use bpexpdate to deassign a tapes. Although
You may still show the tapes in the media pools -
Eric Ljungblad
Computer Operator
Copley Information Services
Eric.Ljungblad AT copleypress DOT com
(858) 729-8010
-----Original Message-----
From: Rob Worman [mailto:rob AT worman DOT org]
Sent: Sunday, December 05, 2004 9:19 PM
To: Eric Ljungblad
Cc: veritas-bu AT mailman.eng.auburn DOT edu; Sen
Subject: Re: [Veritas-bu] unable to allocate new media for backup
Hmmm, no offense Eric but I think two of your suggestions below
("vmquery -deassignbyid", and "allow multiple retentions per media")
are a little hasty, mainly because there are significant caveats to
both:
-If the "vmquery -deassignbyid" command is not used carefully, it can
create a situation of inconsistencies between NetBackup's internal
databases, which can in turn lead to data loss. The ONLY situation
that should ever require this command is expiring an old NBU catalog
backup tape, a.k.a. a tape that shows up in the output of "vmquery -a"
but does not appear in the output of "bpmedialist". IF YOU DON'T
UNDERSTAND EXACTLY WHAT THE "vmquery -deassignbyid" COMMAND DOES, AND
WHY YOU'RE RUNNING IT, THEN DON'T!
-I have yet to see a NetBackup environment where enabling the "allow
multiple retentions" causes anything but trouble. This setting might
seem to increase the utilization of tapes in a small robot, but
eventually the result in typically a significant DECREASE in available
tapes, due to the fact that a FULL netbackup tape doesn't get re-used
until EVERY image on that tape expires. (so if a tape fills up with 99
backups with a 2-week retention level and 1 backup with a 7-year
retention level... that tape won't be made available for another backup
until 2011! :-(
Sen-
If you haven't already done so, I would recommend that you start by
taking a look at the "NetBackup Troubleshooting Guide" for some
suggestions about how to approach a "status 96" error.
If I were you, I'd take a look at the backup that failed with a status
96, with these questions in mind:
-what volume pool was this backup class configured to use?
-what retention level was this backup schedule configured to use?
Then run the "available_media" script (in C:\Program
Files\VERITAS\NetBackup\bin\goodies\available_media) and scrutinize
it's output. The tapes in this output are grouped by volume pool, with
a column for "robot type", a column for "retention level", and a column
for "status". You got the status 96 error because NetBackup could not
find any tapes to match all of the following qualifications:
(1) tape is in the robot (i.e. the "robot type" column is something
other than "NONE")
(2) tape is in the right volume pool
(3a) tape has a status of "ACTIVE", along with the right retention
level
or
(3b) tape has a status of "AVAILABLE"
The "status" values are going to be the most help to you. If you have
lots of "FROZEN" tapes, then you have a larger problem (bad hardware?
trying to re-use old tapes?) to track down and resolve. If you don't
have many FROZEN tapes, but you have lots of FULL tapes, then you need
to remove some of the FULL tapes from your robot. (or else expire them
prematurely, using the "bpexpdate -ev <tape> -d 0" command)
See also the NetBackup Troubleshooting Guide. Linked below is the 4.5
version (see page 106) of this document. It's suggestions also apply
to your 3.4 master server in this case.
http://ftp.support.veritas.com/pub/support/products/
NetBackup_DataCenter/246884.pdf
HTH
rob
On Dec 5, 2004, at 9:30 PM, Eric Ljungblad wrote:
> Always ensure that your media server database in on your Master Server
> -
>
> If the bpexpdate does not work the the deassignbyid should work
>
> V:\VERITAS\Volmgr\bin>vmquery -m ntd132
> =======================================================================
> =
> media ID: NTD132
> media type: DLT cartridge tape (11)
> barcode: NTD132
> media description: NT-Daily
> volume pool: NT-DAILY (7)
> robot type: NONE - Not Robotic (0)
> volume group: INCOMING
> vault name: ---
> vault sent date: ---
> vault return date: ---
> vault slot: ---
> vault session id: ---
> created: 3/27/2004 10:40:44 PM
> assigned: 11/8/2004 7:02:50 PM
> last mounted: 11/8/2004 7:06:19 PM
> first mount: 4/5/2004 7:05:30 PM
> expiration date: ---
> number of mounts: 26
> max mounts allowed: ---
> status: 0x0
> =======================================================================
> ==
>
> V:\VERITAS\Volmgr\bin>vmquery -deassignbyid ntd132 7 0
>
> "note the pool number in the command - and 0 for status is required"
> =======================================================================
> =====
> ====
> media ID: NTD132
> media type: DLT cartridge tape (11)
> barcode: NTD132
> media description: NT-Daily
> volume pool: NT-DAILY (7)
> robot type: NONE - Not Robotic (0)
> volume group: INCOMING
> vault name: ---
> vault sent date: ---
> vault return date: ---
> vault slot: ---
> vault session id: ---
> created: 3/27/2004 10:40:44 PM
> assigned: ---
> last mounted: 11/8/2004 7:06:19 PM
> first mount: 4/5/2004 7:05:30 PM
> expiration date: ---
> number of mounts: 26
> max mounts allowed: ---
> =======================================================================
>
>
> In the media server host properties - check the boxes to allow
> overwrite all
> media types, "that's save if you are using tapes that have been used
> before"
>
> In media server properties - Check allow multiple retentions per media
> -
> That's safe as well - Unless you need to only allow the same
> retentions per
> tape.
>
>
> Eric Ljungblad
> Computer Operator
> Copley Information Services
> Eric.Ljungblad AT copleypress DOT com
> (858) 729-8010
>
> -----Original Message-----
> From: Sen [mailto:discussion.groups AT gmx DOT net]
> Sent: Saturday, December 04, 2004 8:37 PM
> To: 'nbu-lserv'; 'netbackup-l'; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] unable to allocate new media for backup
>
> Hi,
> I am running on windows 2000 , NBU 3.4. My backup has been failing
> with this
> error message:
> "unable to allocate new media for backup, storage unit has none
> available(96)"
>
> I have tried bpexpdate and it does not solve the problem.
>
> Pls help. thanks
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
