Netbackup Trying to Use Offsite tape for Cat Backup

[hatman]

I don't know if my catalogs are out of sync or what, but everytime I do a backup, the catalog backup fails because its trying to mount a tape thats currently in an offsite group. I 've tried to deassignbyid and expire the tape, but when I try to delete, it says, "could not delete. It is assigned".

Now here's the entire story: all this started happening after I updated the firmware on my IBM 3853 lto drives. They now recognize that L1 at the end of the barcodes. When I did a inventory and update through netbackup, it added all these new tapes. (IE media id and barcode was 000000, but now 000000L1). Because I don't know of a way to change the media id I had to go through and delete all the old 000000 tape listings in NB and rescan. So now I've got 000000 id and 000000L1 barcode, which is fine. But there are about 5 out there that I can't delete and the tape that NB wants to use for that catalog backup that keeps failing is 1 of them. Anyway to delete these listings from NB? Please let me know if anyone has any ideas.

 

[PGPhantom]

Ouch - Adding the L1 to all tapes has definitely created a problem for you. What you should of done is to not use the L1 as Veritas only recognizes 6 characters in a bar code. You could of changed the drives configuration to only see the first 6 - The L1 is just an end of label marker for the bar code reader.

Is this you ronly media server? Might the tape of been assigned to another media server. Also, as NetBackup only recognizes 6 characters, the tape labelled 000000L1 will be seen as tape 0000L1.

 

[hatman]

This is my only media server (set up as media master). Netbackup is now recognizing (at least according to the media lists)the 1st 6 characters as the media id and the entire 8 character label as the barcode. But I haven't got a sucessful catalog backup since last week because it keeps trying to load that tape that's offsite.

 

[hatman]

One more update:

I've noticed that recently all backup throughput has been slowed to at, or about 1kb/s. I don't know if this is related to the problem above or not but the throughput is that slow for every server we have. All buffers look normal.

 

[PGPhantom]

Can you try this ... Reset your tape device so that it will only see the first 6 characters. Insert some tapes and rescan. Make sure that the RVSN and EVSN are the same i.e. Both are 6 characters. Re-run a few backups and see what the difference is.

 

[hatman]

I found out that I had a SCSI card problem which was slowing down the data transfer. So I 'think' that problem's fixed, the speed of all backups are back to normal. I still however need to know if there's a way to delete these old tape listings out of Netbackup.

 

[hogfather]

Could the problem be that you still have the tape defined in the catalog backup config, so it is trying to switch between two tapes?

You could delete the tape from mediamanager, or use bpmedia commands to expire the images then vmquery to deassign the tape?

 

[hatman]

When using bpmedia commands I keep getting the msg "requested media id was not found in NB media database and/or MM volume database"

That is what's making me think that my databases might be out of sync. Unfortunately if this is the case I have no idea how to re sync them.

Any attempt to deassignbyid, I get :could not deassign media ID 000000: volume is already assigned <93>.

Can't delete because NB thinks the tape is 'already assigned' also.

BTW, thanks everyone for your suggestions. Any ideas @ this point helps b/c I'm OUT.

 

[PGPhantom]

Can you please post the exact command that you are typing (Copy and Paste) and from where you are running it, what your master servers name is and media servers name if different.

 

[hatman]

Below is the command I'm running from the Master/Media server console, and the message that I'm receiving.

KHEFRKSRV005 is the Master/Media server name

C:\Program Files\VERITAS\Volmgr\bin>vmquery -deassignbyid 000000 1 0
Could not deassign media ID 000000: volume is already assigned (93)

 

[PGPhantom]

Run the following:
vmquery -m 000000 - This will tell you the pool number, status and media server that it is assigned to.
If the status is other than 0x0 you need to resolve it as the tape may be froze ... If it is:
bpmedialist -m 000000 -h KHEFRKSRV005 - This will verify the status.
If it is frozen:
bpmedia -unfreeze -m 000000 -h KHEFRKSRV005
Then to expire it ...
vmquery -deassignbyid 000000 <Pool> <Status>
Then delete it from the media database.
bpexpdate -m 000000 -d 0 -host KHEFRKSRV005 -force
Then, delete the tape and manually add it back in.

 

[hatman]

Thanks for your help pgphantom. I was able to figure out what the exact problem was. With the vmquery command i was using 1 0, and was informed that it should be 1 1 for the volume pool and location. Don't really know why it worked but for those couple of tapes, it did.

 

[Mark1229]

with vmquery the last number (0 or 1) tells NBU if the tape is used for regular backups(0) or NBU database backups(1). I ran into the same problem a while back...

 

[PGPhantom]

The vmquery -m <tape number> would of indicated the status to be a 0x1 which, as Mark1229 pointed out, is from a database catalog backup.

Other status codes indocate Frozen etc.