there must be some way to get brightstor to ignore the write protection. the tapes are not physically write protected. they were in use on an irix system before. i need to get the headers blown away off those tapes. pleas help!
linux, arcserve 11.5, hooked up to L700. all tapes show up as write protected. they are not physically write protected. they are not new tapes they were used by Netbackkup before i believe.
i can load tapes then kill CA services and do a mt -f /dev/st* erase. then i reinventory the tape and...
i've seen sdlt tape drives go forever with no issues at all. can't say the same for dlt thought. lto has performed the best of all 3.
with lto you also have the option of lto: 1,2, or 3. lto3 being the fastest. but you don't always need the speed of lto3. as a matter of fact if you don't...
comtec17 is correct. lets say ur using version A of the firmware and want to go to the latest, C. well there is one special version, B. that the library must have on the mpc card atleast once or else you will hose the mpc card. there may have been some updates to this issue since i did one...
thanks for the help! we were actually backing up off of a f825 and things were running slow on the lto-3's. we then tried the 3020 hoping that it would help but it didn't.
so the bottleneck you're saying is at the filer? you think a dual gig-e connection would help?
i got a backup server hooked up to an L20 with 2 HP-lto3 drives. when i go to backup from the NAS which is a 3020 netapp, the backups run extremely slow. there are hundreds of thousands of small files on the NAS, so i want to setup multiple streams. according to CA documentation you can only...
check the connector pins, reseat the dongle if pins look good. if that doesn't work get another dongle. still a no go i would say replace the mpc card.
the unrecognized media error we corrrected and attribute to a patch. which one i forget exactly b/c we put so many on. the scsi error that occurs at the same time we had as well. one of the servers is querying the library. which one we do not know yet. we don't have a SAN sniffer available...
correct you are! i did reinit the library and the bridge and had the bridge probe the scsi buses again. sorry i didn't make that clear in preceding post. using slots 2 and 3 the bridge could still not see the drive in slot 3. then when i moved the drives to slots 3 and 4 the bridge was able...
i have run full diags on the all the hardware using scsi toolbox. and looked at all the logs. the l40 has four slots available for tape drives. the top two were occupied at first and the top drive was failing. so i moved the top drive to the third slot and now the fibre/scsi router was not...
1. having user clean the tape drives.
2. customer does not want to do this just yet. escalated issue as high as we can at CA.
3. on the latest version with all patches.
the only customers i support that use 9940's are also using the powderhorn. they do use them in the l700 as well. so unless you have that type of scalability. comparing the lto's and 9940b's is almost like apples and oranges if you ask me. i would say go with lto3 fibre drives :)
you should be able to find the firmware you need on the stk support site. i never flash dlt drives using scsi toolbox... i've seen it fail too many times. i only use sagetalk to update firmware on the dlt's.
i've installed dozens of these libraries and maintain them as well. the spit out accurate error codes 99% of the time and as long as you have a service contract i don't think parts will be hard to find at all.
this problem has been going on for over a month. My customer is in a HP SAN env. that hooks up to a STK L40 via fibre/scsi router. the tape drives(2) are all certance lto. library and drives are all on the latest firmware.
so many things have gone wrong i have no idea where to begin. last...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.