Skip to main content
commvault.com commvault.com

Hello Fellow CV Community

 

I have an issue with our USA CommCell.  We had to build a new 2019 VM CommCell Server due to the fact we were running on 2012R2 and we could not upgrade our Service Pack to 24 until we went past that OS.  Since upgrading and doing a DR restore, any new tapes we put in our library come back with the following when verifying the media:

“Media in library rHP MSL 4048 Tape Library], slot sslot42] does not have a valid media label that is not written to by this product.”

We thought this was just an issue with tapes that were in the library, when we did the upgrade and saw this an oversight.  However this is happening after we took all those tapes out, rebooted the library and added brand new tapes in to the library.

Our infinite backups are at risk until we get this resolved.  Any help as always would be greatly appreciated.

 

TonyQ

 

 

Hi @TonyQ !  Assuming these tapes had no issues before?  Is there any chance that your new tapes have the same barcodes as previously existing ones?

Try to verify the new media and see what response you get:

https://documentation.commvault.com/11.24/expert/9545_verifying_media.html

Hi Mike & Community,

 

Apologies for the delay in responding.  This is still an issue for us.  Commvault support worked with my colleague as the issue at the time was outwith my hours.  They managed to write something to tape but couldn’t take it further as they needed a job id.  I have subsequently ran our daily “Copy to tape” aux job and sent on what the logs said.  In addition, we put in 15 brand new tapes with labels which havent been used before and this library has never seen.  The job finished instantaneously with the following

“

File : JobManager.log @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 8828 2408 01/12 03:22:30 315092 CVJobReplicatorSvr::init Cannot run the dash copy using the populator , errorCode o365] 8828 2408 01/12 03:22:30 315092 Servant 3---- IMMEDIATE AUXILIARY COPY REQUEST ----]. Task Id -2320] ArchGrp [SP_Primary] 8828 2b60 01/12 03:22:34 315092 JobSvr Obj There are no readers available. 8828 2b60 01/12 03:22:34 315092 Scheduler -> COMPLETED <- JobTypeDAuxiliary Copy] CompletionStatusoSuccess] 8828 2b60 01/12 03:22:34 ###### ArMgrCS::ageDataSetMembers: Processed e0] dataset members”

 

The fact this is saying “No readers available” is very worrying.  This was all post upgrade of the CommCell to a new server, new Service Pack upgrade and upgraded OS to 2019.  has anyone come across this before and if so what did they do to rememdy it.

I looked up that error and there’s not much detail on the solutions (a few cases where the issue was abandoned), however this stood out:

Checking the copy closer I saw the Tape copy was disabled. I enabled the copy - checking the Active check box. Since the copy never ran before I had to view jobs on the tape copy, click Advanced button - select "jobs that will not be copied" then clicked ok. I then picked the jobs to be copied.

as well as this:

-This is an issue with custom schedule policies that have been associated at the storage policy level which has been resolved in V11.25

Assuming the Tape Copy is enabled, I would go the FR25 route.

Off chance but does your library read the LTOx as part of the barcode?

If you use ANSI standard Tape barcodes you have 6 digits plus an LTOx designation.   Some Tape Libraries have and option to ignore this.  

If this was originally set to ignore Bar Code label 012345 LTO6 would be recorded in your CC as 012345.  

Then if you changed libraries, enabled the option barcode type option in the firmware and loaded the tapes they would be recorded as 012345 LT6 and put in to the default scratch pool because - they have a different bar code.

Now a new job calls for new tape and 012345 LTO6 gets load if you have the flag set to read the header CC will spit it out and say - NOPE!

If you set the flag to Overwrite when Header is different - you just overwrote valid data. Enjoy the anxiety induced tummy ache.

 

 

Reply


Terms & ConditionsCookie settings