Amanda-Users

Re: Speed up 400GB backup?

2004-07-20 19:08:55
Subject: Re: Speed up 400GB backup?
From: Frank Smith <fsmith AT hoovers DOT com>
To: Kris Vassallo <kris AT linuxcertified DOT com>
Date: Tue, 20 Jul 2004 18:05:26 -0500
--On Tuesday, July 20, 2004 14:35:53 -0700 Kris Vassallo <kris AT 
linuxcertified DOT com> wrote:
>> NOTES:
> 
>>   driver: WARNING: /tmp: not 102400 KB free.

I overlooked this last night.  I've never seen this message myself,
but perhaps it is relevant.  Any thoughts, anyone?

> 
> I am using tar to do this. The bda1 system is a CVS server which gets
> hammered on all day long and does have tons of smaller files as well as
> a decent amount of larger ones.

As Stefan mentioned, there are probably subdirectories you could exclude
from the backup to speed things up.  You mentioned part of it was used
for CVS, perhaps you can exclude some of the build trees and just backup
the source trees.

> The disks in the venus box are all SATA 150 drives, SCSI is way out of
> the price range for this amount of space. If venus is the machine that
> is taking forever to do the estimates, is it possible that 1. estimates
> start on all machines, 2. the estimates finish on the smaller remote
> file systems first; these systems begin to dump. 3. now along with the
> backup server trying to do an estimate on its own disks, its also
> dealing with a dump coming in from remote systems and all of this
> together is slowing it down? Do I have any valid ideas here?

Possible, although the estimates write to /dev/null, so the remote
dumps shouldn't be slowing them down unless it's your controller
limiting you and not the disks themselves.  You could try commenting
out all the other filesystems in your disklist and see if the estimate
still takes as long.
   Is the system otherwise idle when you are running Amanda?  If
the disks are fairly active (whether from user activity or perhaps
automated nightly builds) it will slow down your backups considerably.
   It could also be kernel related.  Our first attempt at Linux
fileservers had problems under heavy load, the sytem would slow to
a crawl (and sometimes appear to hang) under concurrent loads (a
CVS build and an rsync of the filesystem in our case).  Moving from
a 2.4 kernel to 2.6 solved the problem completely.

Frank

> -Kris
> 
>


-- 
Frank Smith                                      fsmith AT hoovers DOT com
Sr. Systems Administrator                       Voice: 512-374-4673
Hoover's Online                                   Fax: 512-374-4501


<Prev in Thread] Current Thread [Next in Thread>