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)