--On Monday, May 24, 2004 14:01:27 -0400 Jon LaBadie <jon AT jgcomp DOT com>
wrote:
> On Mon, May 24, 2004 at 10:48:17AM -0700, Kris Vassallo wrote:
>> In response to my own message, I was reading around a bit more and the
>> broken pipe could be many things but usually means that the data isn't
>> being dumped fast enough and the server gives up on the client (in my
>> case the same machine). So I was thinking, I am trying to backup 281GB;
>> therefore reading the data, compressing it and then dumping it back to
>> disk all on the same controller... maybe its just taking a long time?
>> Here are the lines in amanda.conf that pertain to this backup, maybe
>> this will give some clues:
>
> In an earlier response, someone replied:
>
>> > > You need to raise dtimeout in this case.
>
> Have you done this yet?
>
> I'd suggest raising it a massive amount and see if the dump
> completes at some point.
>
> You can monitor that things are still running with commands
> like top, ps, prstat, ... depending on your OS and available tools.
Amstatus is also a good way to check on how backups are progressing.
Besides increasing the data timeout value, you might also consider
splitting your DLE into smaller chunks using includes and excludes.
Filesystems with huge numbers of small files seem to take quite a bit
longer than ones with fewer large files.
You might also try disabling compression, especially on older hardware.
On a Sun v480 client I have, the directories backed up up with client
compression only average about 3MB/sec dump rates, while the other
directories not using compression run 12 - 15 MB/sec (all these are
NFS-mounted over gigibit, the connection to the Amanda server is a
100Mb link).
Frank
>
> --
> 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)
--
Frank Smith fsmith AT hoovers DOT com
Sr. Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
|
