cancel
Showing results for 
Search instead for 
Did you mean: 

BE2014 doesn't recognise imported tape

DaveyMG
Level 4

I have BE2014 SP1 running on Server 2008R2 with an HP MSL2024 library and LTO5 tape drive. If I import a tape into the library, BE recognises the barcode label but always shows the tape as a scratch tape and "Media Unknown" as the description. This is even though the tape has backup data and is listed in a Media Set. So I end up with the scenario where the tape is listed offline in a media set, in a vault and the same tape label is shown as online but scratch media.

If I inventory the tape then it is recognised correctly. My understanding is that BE should recognise a tape belonging to a media set based on its barcode and not have to be inventoried.

As it stands, if I am cataloging a tape and BE asks for the next tape to be inserted into the library then BE does not recognise the imported tape and I cannot inventory the tape because the catalog job holds the tape drive waiting for the next media. So the catalog can never complete.

1 ACCEPTED SOLUTION

Accepted Solutions

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

If your problem is with tapes known to the media server that have been removed from the library and that at a later time imported,  and not new tapes, I think this may be something that has cropped up before:

http://www.symantec.com/connect/forums/media-seen-different-locations

http://www.symantec.com/connect/forums/be2012-issue-media-media-vault-duplicates-db-when-inserting-t...

and the solution at the time was to run an inventory after an import.

 

Although it could be related to pkh's article.

 

Either way I suggest you do log a formal support case.

 

 

 

View solution in original post

4 REPLIES 4

lmosla
Level 6

Have you created a import Storage Operation job as per this document?

 http://www.symantec.com/docs/HOWTO98957

pkh
Moderator
Moderator
   VIP    Certified

This is a known problem.  See this document

http://www.symantec.com/docs/TECH222866

You should log a support so that your problem can be part of the investigation.

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

If your problem is with tapes known to the media server that have been removed from the library and that at a later time imported,  and not new tapes, I think this may be something that has cropped up before:

http://www.symantec.com/connect/forums/media-seen-different-locations

http://www.symantec.com/connect/forums/be2012-issue-media-media-vault-duplicates-db-when-inserting-t...

and the solution at the time was to run an inventory after an import.

 

Although it could be related to pkh's article.

 

Either way I suggest you do log a formal support case.

 

 

 

DaveyMG
Level 4

Hi, sorry for the very late reply, I didn't receive any notifications that my post had been responded to. Thanks for the replies.

The problem is related to media stored in a vault. I initially thought it was a probem with BE not recognising the media type from the barcode label. Inventory after import as Colin suggested does make BE recognise the tape correctly.

If a tape that isn't associated with a vault is imported into the library then the media details show correctly (capacity, media set etc). However if a tape is imported that belongs to a vault then BE shows it as "Unknown Media" and associates it with the Scratch media set. This results in two tapes with the same label being listed in the media lists.

I've logged a support call and the behaviour has been acknowleged to be "how the system is designed to work", which is very poor design IMO. The result of several hours of Webex sessions is that the call is closed with the support person logging an enhancement request to get the behaviour changed.

The correct behaviour should be that BE recognises that a tape from a vault has been loaded and removes the entry from the vault and makes the correct associations with the database. I've been given all sorts of explanations of how the vaulting rules must be followed and how this behaviour occurs if the rules aren't allowed to run. But really, the vaulting behaviour is broken and I've deleted the vaults in my config to avoid this problem.

Given that the posts referenced by Colin go back to 2012 I'm not expecting a fix very soon.