Netbackup will not use 2 of my SCRATCH Tapes - why?

[LeeClayton]

I have a tape library which holds 30 tapes and there are two tapes in there that are in the SCRATCH pool which netback doesn't want to use. I've tested this by leaving those two tapes as the only scratch tapes and doing a manual backup to tape, the backup fails due to no media in the storage unit although theres these two scrach tapes, all other scratch tapes are working fine. What can i do to find out more. the tapes in question are not frozen or suspended.

[Andy_Welburn]

e.g. HCART or HCART3 etc?

[Andy_Welburn]

Not to be confused with the expiration of the data on them.

See this TechNote: http://support.veritas.com/docs/304757

[LeeClayton]

Yes, just doubled checked, HCART3 LTO3 - same as all my other tapes.

[LeeClayton]

ran vmquery -m tape and one tape expired on April 2009 and the other May 2009

[Andy_Welburn]

apart from the physical expiration mentioned above in my last post, is whether a maximum number of mounts has been set & reached by these tapes?

[LeeClayton]

the maximum mounts is not set so not a problem.

[Andy_Welburn]

If this is coming up with a date then I would say that the tapes have physically expired (passed their sell-by date).

Try running the vmchange command from the TechNote I referenced & see if that sorts the issue.

[LeeClayton]

If I search under reports, tape reports for my two tapes, they are not listed, do i need to import them or something like that? it's as though the media servers don't know they exist although they can see them in the library.

[LeeClayton]

Nice, ran the command below and now it works.

vmchange -exp 0 -m <media id>

[Andy_Welburn · Accepted solution]

(the one where I missed your previous one about expiration dates!!!!) :p

If I put an expiration date on a tape then run the vmquery command:
bash-2.05# vmquery -m 300739|grep expiration
expiration date: Wed Jun 23 15:59:46 2010

Then this tape will not be available for writes after that date.

If I remove the date & run the command again:
bash-2.05# vmquery -m 300739|grep expiration
expiration date: ---

Then this tape hasn't physically expired & so can be written to.

[Andy_Welburn]

Both posting at the same time's not good for the soul!

[dglee]

I've run in to the similar problem, and your solution worked for me.  I was wondering if this premature physical expiration date issue can arise when you use the bpexpdate -0 <mediaid> command?  I had a problem some time ago where all of my media was allocated, but not written to.  I had to run this command on a majority of our media just to get them usuable again. 

Could this have been the origin of my problem?  Great work on this solution, BTW.

[Abesama]

Running bpexpdate command does not make "this premature physical expiration date issue arise"

Speaking in pre-NBU6 terms, bpexpdate works on mediaDB/imageDB and vmchange works on volDB - they touch different area each.

Cheers,

Abe