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 jon AT jgcomp DOT com
> 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.
|
