Barcode and Media Label mismatched? Not number of characters issue

[Ryan_Aubrey]

Hi all, first time poster.

Running BE2012 on a Windows server (64 bit WinSvr 2008R2).  I noticed after adding a batch of new tapes that all of them have mismatched Barcode and Media Label information.  I saw several discussions about the description field, and about it cutting off characters, but this is a totally wrong number, in some cases, already existing to a different tape.  For instance, new tape with barcode 000327L4 has assigned Media Label 000313L4.  Barcode 000334L4 has Media Label 000275L4.  And of course, it thinks it is associating them with the Media Label, thinking 000327L4 was used in May for a job that needs stored for years instead of a daily backup that should be kept for 2 weeks (because that's what 000313L4 was).

Thoughts/solutions?

[WaitingForLTO-6]

Same problem here...I swap tapes in my LTO-5 autoloader and do a scan.  The scan changes the barcode but not the media label.  If left alone, I believe I've seen it get the media label right when it goes to run a backup using that tape but in my case it's a problem because I normally move media between vaults (e.g. to OFFSITE-Temporary) and I can't if it still thinks it's in "DELL 02".

The workaround to this bug appears to be running an inventory on the slot.  You run an inventory, it gets the media label right and in my case I can then move media to my offsite vault. 2010 R3 would get the media label and barcode correct if you did a scan, so I haven't performed an inventory in years.

The bug also extends to the media coming back from the vault...until you perform an inventory or run a backup, it will still see it as being in the vault.  I can have it sitting on my desk but until I run an inventory, it's stuck in the vault which means looking at the contents of a vault is misleading.  In 2010 R3, I would manually move media back and forth from my vaults each week, so my vaults were always accurate.

[Larry_Fine]

So running an inventory job fixes the issue?  temporarily or permanently (for that media)?

The inventory job log will show both the bar code label and the media label, which normally should match.

If an inventory fixes it, then it sounds like something is confused in the database or the UI.

I have not seen this issue, but I don't use vaulting.

[WaitingForLTO-6]

It only fixes it for that week.  As soon as I rotate tapes out of my autoloader the next week, I have to inventory again.  The Scan function under 2012 will only change the barcode and not the media label.

[Ryan_Aubrey]

Inventory did NOT fix it for me.  Updated the Allocated Date, but left the Media Label and even Media Set with the old #...  Opened a ticket with them, and after 45 mintues with a Tech, it was pushed to the Advanced team. 

[pkh]

There is one possible explanation for all this.  You said that you have new tapes.  Until they are written for the first time, the internal physical tape label which appears as media label is not written.  This may account for the discrepancy that you are seeing between the barcode labels and the media labels.  A scan reads the barcode label, but it does not read the internal physical label, whereas an inventory reads the internal physical label.  This is the reason why an inventory takes much longer than a scan.

Try running a small backup to the new tapes and then scanning them again.

[Ryan_Aubrey]

But why did that change with 2012?  That's... insane behavior.  We've always added new tapes with new barcodes ok.  I could even buy that if it was a blank Media Label, but it's pulling Media Labels for existing media...

[pkh]

Obviously this is not desirable and you would need to take this up with Symantec by opening a support case.

More importantly, does the label mismatch happens after the new tapes are written to?

[Ryan_Aubrey]

I have a support case open now, so far, no luck. 

At the moment, it hasn't written to the new tapes AT ALL yet, because the media labels it is it arbitrarily assigning them are in sets that need retained, so I can't just Scratch them or something to make them overwritten.

[WaitingForLTO-6]

Any word from support, Ryan?  I don't want to open a case for the same thing...it's inevitably going to development.

[Ryan_Aubrey]

Yes and no.  After several days of no response from the support line, and always being told I would be called back "within 2 hours", I found a work around from someone else who had similar issues.  Essentially, any time we insert new tapes, (and it only happens with brand new tapes) I have to power down our back up server and tape drive.  Bring up the tape drive first, bring up the server, then run inventory jobs on each tape individually.  I don't know why, but trying to do more than 1 at a time did nothing.  Inventory 1, waid until complete, and start the next did.

In other news, we are currently looking at other backup options right now, including waiting for Veeam to support writing to tape itself...