>Would using ufsdump the way we are slow the backups down. ... Yes, or rather, I can easily believe it would.
>As you can imagine this is not satisfactory as amanda is trying to >backup these partitions as users are accessing them. ... Well, that's simple. Kick those silly users off. I mean, really, what's more important here??? :-) >This server >is a sun E450 and is only backing up it's internal disks. So I'm >running out of ideas as to why it's so slow. Any ideas? Are the dumps going to/through your holding disk, or are they going direct to tape? Look for FILE-DUMP (holding disk) vs. PORT-DUMP (direct to tape) in the amdump.<nn> file. How much holding disk space do you have? What is maxdumps set to? Amanda can get into a mode where it has enough holding disk space for one image, but no more. So it does that dump into the holding disk while the tape drive sits idle. After it's done, it gets written to tape but there isn't enough space to do another dump so the dumpers go idle. It's odd, but in this case *less* holding disk space is actually better. This problem will go away when the tape overflow code goes in. If you run: amstatus <config> --stats --summary --file amdump.1 after the run, you can get some clues about how busy each of the pieces of Amanda were during the run and what kept more of them from kicking in. You might also look into amplot, which does some of the same things but in living color with charts (thereby making it appropriate to show to management types). >David Flood John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
