Yes, it's the exact same tape drive I've been using extensively for testing, and all that time it had been sitting in the same position on the floor. I moved it on Monday, and then amanda took off like a lightning bolt.
Wow, that's something I'll be classing as very weird, but very good. I was impressed by the 9 hours it took to do backups, but now I'm speechless... I've introduced a new tape for tonight's backup run. Will see what it tells me tomorrow. Thanks very much for your help! Jon LaBadie wrote: > > On Thu, Aug 03, 2006 at 08:25:43AM -0700, Joe Donner (sent by Nabble.com) > wrote: >> >> Well, I may have "lied" a bit when saying that nothing had changed... >> >> What did change was that I moved the server from temporarily sitting on >> the >> floor to where it will now stay full-time. So it was a shutdown, unplug >> the >> external tape drive and other devices, and then plug them all back in. >> Also, one of the little screws which connects the SCSI cable to the back >> of >> the server has long ago broken off and gone missing. So it's only >> attached >> by one screw. >> >> Well, do you agree with me that it is still backing up the same amount of >> data and all the DLEs? It certainly looks that way from the mail >> reports. >> I'm a bit worried because it's looking "too good to be true". >> >> I also don't see how it can dump 130-odd gigabytes of data within a bit >> more >> than 3 hours?? >> >> Thanks for your help on this. >> >> >> Jon LaBadie wrote: >> > >> > On Thu, Aug 03, 2006 at 02:46:06AM -0700, Joe Donner (sent by >> Nabble.com) >> > wrote: >> >> >> >> That was definitely not the case. The holding disk has been empty all >> >> this >> >> time, except on 31 July. And after I ran amflush it was empty again. >> >> >> >> What I don't understand is the increase in dump time and tape time? >> They >> >> both more than doubled in speed! How is that possible? >> >> >> >> >> >> Olivier Nicole wrote: >> >> > >> >> >> I honestly haven't changed anything. The only thing that happened >> was >> >> >> that >> >> >> I had to run amflush on July 31, because for some reason the >> >> >> amanda-related >> >> >> services on the backup server seemed to have hung (but that's an >> >> entirely >> >> >> different issue). >> >> > >> >> > That si just a wilkd guess, but how about the amflush has freed >> space >> >> > on your holding disk that had been wasted for ages? >> >> > >> > >> > Holding disk issues were going to be my guess also. >> > >> > When the run time (wall clock) and tape time (taper >> > is active) match as the first two: >> > >> > Run Time (hrs:min) 9:43 >> > Dump Time (hrs:min) 6:21 >> > Tape Time (hrs:min) 9:23 >> > >> > Run Time (hrs:min) 9:43 >> > Dump Time (hrs:min) 6:17 >> > Tape Time (hrs:min) 9:23 >> > >> > it "generally" means your dumps are going straight to tape. >> > Contrast that with the last two where time for taping the >> > same amount of data is greatly lower than total run time. >> > >> > Run Time (hrs:min) 4:03 >> > Dump Time (hrs:min) 3:12 >> > Tape Time (hrs:min) 1:17 >> > >> > Run Time (hrs:min) 4:27 >> > Dump Time (hrs:min) 3:37 >> > Tape Time (hrs:min) 1:16 >> > >> > However, if the dumps were going straight to tape then I >> > would expect the dump time (cumulative time for dumping of >> > each DLE - thus can be > run time if DLEs dump in parallel) >> > to match tape time. >> > >> > So it would appear the dumps were going to the holding disk >> > but were severely constrained by slow tapeing. I wonder >> > about the halving of dump time also. There may still have >> > been a problem with the disk system. >> > >> > Did anyone change any scsi cables or terminators. >> > Or maybe the just "jiggled" things back there doing other work? >> > >> > > > Are you using that SDLT drive for which you reported a tapetype > back in early June? If so, you have had a problem since then. > > In June your tapetype showed 2200 k/s. > Similarly, your recent slow dumps had a > tapeing speed of about 2500 and 1800 k/s. > > Your more recent fast dumps were taped at about 13000 k/s. > The sdlt is rated at 16000 k/s. > > I'd say you had tape system problems > fixed by physical movement or reboot. > > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road (609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) > > -- View this message in context: http://www.nabble.com/Dramatic-reduction-in-backup-time-tf2044425.html#a5635442 Sent from the Amanda - Users forum at Nabble.com.