Hi and happy new year to all of you !
I would like to know if some of you have already implemented some LTO9 drives / tape libraries, and would love to get your feedback about it using Commvault.
My experience on the LTO9 media, using dual tape drives tape libraries, is quite bad.
The Media calibration / optimization / characterization phase that any new LTO9 media has to deal with is a pain, on my side.
Looks like on the first mount of a media -- let me reword it in my ‘old guy’ words -- it has to be somehow formatted to be able to be used by your favourite backup software.
Below a link to Quantum’s FAQs about this :
Short calculation : 50 LTO9 brand new tapes may require up to 2hours each of ‘calibration’ before they can be used. So this equals to 100 hours of ‘calibration’ before you could use the full 50 tape pool.. 😱
My 1st issue was that I had to adjust all the mount timeouts in that LTO9 Commvault tape library from a few seconds/minutes to up to 2 hours to deal with that.
But even after doing this, I still often get media errors, or drive reporting that the tape is bad, marking my brand new LTO9 tapes as bad.
As I have dual drive, I can’t check if it would react the same way with a single drive tape library. Maybe it would work fine as source and target drive would always be the same. But well, so far I could not test anywhere else than on big tape libraries.
As a result, I took the decision to revoke any LTO9 system and only buy LTO8 systems instead.
So, what about you ?
How are you dealing with LTO9 ?
Good morning. Thank you for sharing.
After calibrating all tapes over the webinterface from my tape library it works fine for me.
Problem is when i insert new tapes and they must be calibrated the tape drive goes in Commvault offline.
Are you using single drive LTO9 tape library, or multiple drives tapes LTO9 tape library ?
And have you extended the timeout settings as per experts doc here :
To be crystal clear, I have updated the firmware of each of the LTO9 drives + the tape library itself, and now the logs from the tape library itself provide more details about tapes, reporting mostly ‘unknown errors’, ‘read errors’ but also sometimes ‘environment’ errors like temperature and humidity outside of accepted values. I’m trying to have this troubleshooted physically before blaming the technology 😉
Thanks. Actually i use one tape drive. But we have ordered an additional tape.
I have not modified timeout settings. I will try it :-)
The drive characterization is a new feature from tape HW vendors starting with the LTO9 generation, and it affects all hardware brands of this type of drive. This is part of the new standard and is coming from the tape drive itself. Once the process is started it cannot be interrupted from the software side.
This is required only once per new LTO9 tape media, on the first time it is ever loaded into a drive.
To allow for jobs to wait for this process to complete, two timeout settings are required (MA and Tape Library levels). Please refer to BOL: Setting the Timeout Durations to Support LTO9 Drive Characterization (commvault.com)
If these settings are not in place, drive operations can fail with SCSI timeout errors, and this will place the drive offline until the characterization operation is complete. It may also mark the media bad, but this can just be marked good again. If there are other kinds of errors being seen this is not expected, and a support ticket should be opened for further analysis.
That’s a bit what I thought too, but I have (almost) good news to share on this.
Last wednesday, I applied FR52 (11.28.52) on my FR48 (11.28.48) CS + MAs.
I did not checked this right away, but now it looks like the LTO9 tapes are beeing used normally, up to their real capacity, and are not beeing marked as bad when there are timeouts for backup copies.
Now I can see almost 18TB of data stored per tape, and they are just ‘normally’ filled, while before they would be marked as bad after a hundred gigs or a few terabytes stored.
On may 1st also, our linux has also been yum updated, so I don’t know if this comes from the FR48 to FR52, or from the system updates…