On Tue, Apr 23, 2002 at 09:29:57AM -0400, Uncle George wrote:
> I presume u are using tar?!
>  From My experience, 17gigs of a (few) large files does not take a long
> time.
> On the other hand, backing up a large amount of files in a (single)
> directory takes a long time. The orig tar that came with this (linux)
> sys readily reached 80% cpu usage. The later tar fixed that, so now it
> still takes a long time ( but mainly it just waits for all the
> disk/directory activity ?! )
> 
> So whats the culprit? Since there are 2 phases ( size estimate, and then
> data transfer ) i suspect that each part takes about 4 hours.To find
> out, you can do a "time tar cf - ...... " just like what the sendsize
> program would do on your system. just to See how long that takes.
> 
> Then how fast is your tape drive? a 5.0mb/sec tape drive would take 56
> min just to back up 17gig. This presumes that the tape is screaming ( i
> ment streaming ) . 
> 
> a "df -i" might help in determing how many files might be out on the
> system.
> 
> David Flood wrote:
> > 
> > We kick off our backup at 10pm at the moment we are only
> > backing up 4 seperate directorys i.e. 4 seperate disklist entries.
> > These are estimated by amanda to be 17.4GB. The estimates are
> > taking just short of 8 hours to complete which is unacceptable.
> > This is after making every dump a full dump in an attempt to cut
> > down time with doing estimates for level 1 & 2. To force it to do full
> > dumps I have did the following in amanda.conf:

Another datapoint, also Solaris, but Solaris is not the culprit :)

If I understand the scheme, the planner can't finalize its actual dumps
until all estimates are in.  Thus when the dumping begins is dependent on
the speed of the slowest system's estimates.  In my case, the Solaris
estimates (5 drives, about 90G capacity) takes about 30 minutes.  But I
also have a W2000 system and the estimates for its 1 drive (4 partititions)
of 30G takes 3+ hours.

When I added the M$ system I had to move the dumps from 3AM to 2AM to
prevent them from still running when I awoke.

To David, see if one (or more) systems are causing the total system
to be slow to completion.

-- 
Jon H. LaBadie                  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

Reply via email to