--On Monday, May 24, 2004 14:01:27 -0400 Jon LaBadie <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road (609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
