mlenny Posted July 16, 2003 Report Share Posted July 16, 2003 SPECS ===== Retrospect 6.0 and later upgraded to 6.5. Problem consistent on both. We run a nightly backup of our data volume (D:) followed by the system volume (C:). All held on an integral RAID. Adaptec 39160 Ultra160 controller card. Dell PowerEdge running Windows 2000 Server SP3. Using a Dell PowerVault 122T (LTO Autoloader) we were originally getting backup performances of between 650-700MB/min. Our initial backup of 140GB took 7h19m39s. All acceptable. PROBLEM ====== At the end of April, we had to resize our RAID partitions so the main data volume was erased and restored over a couple of days. The C: was not touched (where we store the Backup Catalogs, etc). We also restructured the data volume's directory structure after the restore. Ever since then, our performance during backups immediately dropped drastically to around 100MB/min, and now stand at around 70MB/min. I tried New Media over last weekend (starting 11pm Friday 11 July) to start a new backup set, hoping to cure our woes with a fresh backup set. The total data to back up was now 228GB. What would have taken overnight to complete pre-April, was still going through the verification of the data volume by *Tuesday* mid-morning, and I had to stop the verification with an estimated 13h still to go!!!! That's after 3d 13h20m already elapsed!!!!! And it hadn't even started the C:!!!! The average speed was 72.8MB/minute. What's gone wrong?! BACKGROUND INFO ============= We've had nothing but problems using this LTO drive with Retrospect, despite it being 'certified' since version 6. The only two changes we've made have been suggested by Dantz support, and were to: * upgrade from version 6.0 to 6.5 to resolve problems controlling the LTO (which didn't work). * move from ASPI to NT Passthrough which did resolve the control problems. Both of these were done after the degradation had started, so are unlikely candidates for the cause. They also are unlikely candidates for the cure!!! Regards, Matt. Link to comment Share on other sites More sharing options...
Mayoff Posted July 17, 2003 Report Share Posted July 17, 2003 The best way to narrow down the heart of the problem is to run a test backup to a file backup set. Create a new backup set, selecting "file" as the type. Save that File Backup Set to a local hard disk and try the backup again. If the performance shoots up, then that is an indication of a device communication problem or drive problem causing the slow performance. Link to comment Share on other sites More sharing options...
mlenny Posted July 17, 2003 Author Report Share Posted July 17, 2003 Thanks Robin. Ran that test - it backed up with an average of 213 MB/min. I would imagine that's about the speed of the RAID 5's write speed - it's certainly higher than the tape is achieving. Do you agree? Any more ideas out there on what to do next? Regards, Matt. Link to comment Share on other sites More sharing options...
Mayoff Posted July 17, 2003 Report Share Posted July 17, 2003 If we assume this is now a device communication issue, we would suggest starting with: 1) Clean the tape heads 2) Try more then one tape 3) Try the tape drive as the only external SCSI device 4) Try changing SCSI cables and termination 5) Try updating the firmware for the SCSI card and LTO drive 6) Check for newer SCSI Card firmware 7) Try the SCSI card in a different computer or try a different SCSI Card. You should also try going to device manager and disabling 3rd party (and windows) drivers for the LTO drive Link to comment Share on other sites More sharing options...
mlenny Posted August 19, 2003 Author Report Share Posted August 19, 2003 OK... it's taken a while as I can only do these sort of things on a weekend, which has meant a month of trying, seeing, trying the next thing. It turned out to be the 39160 card driver in Windows - at some point we had unknowingly updated the SCSI driver to the combined 39160/3960D driver which caused the speed issues. By updating to the 39160 specific driver, we went up to 450MB/min on our main data drive. However, still not the 700MB/min we had experienced previously. I then stopped using NT Passthrough, and reinstated ASPI - last night we got an average of over 800MB/min. Success! The only thing to see now is whether we start getting the drive control issues we had using ASPI before (which is why we started using NT Passthrough). Fingers crossed the latest driver update I applied to Retrospect has solved that, otherwise NT Passthrough means we take almost a 50% performance hit on the drive. Thanks for the advice. Matt. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.