Hi,

It is slow because it doesn't use the holding disk. You must find why?
Could you send the amdump.1 log file?

Jean-Louis

Steffan wrote:

So,

Last night was the first run of my upgraded Amanda server. In fact, this morning is too... since it's still running and is only about 1/4 of the way done. (it used to take about 4-5 hours on average... this one has been running for 10 so far) The server CPU is pegged with tar and gzip processes (mostly tar), even though I'm only backing up other machines via dump. Did Amanda always use tar when writing dumps to tape and I'm just now noticing it? The only changes after the upgrade to the config files was the addition of "tape_splitsize 20 Gb" to the global section of Amanda.conf.

Here's the disklist entry for the currently dumping remote host:

bertha   /dev/aacd0s2g   comp-user

Here are the relevant amanda.conf entries:

define dumptype global {
    comment "Global definitions"
    index yes
    tape_splitsize 20 Gb
}

define dumptype comp-user {
    global
    comment "Non-root partitions on reasonably fast machines"
    compress client fast
    priority medium
}

Debug logs don't show anything out of the ordinary.. I'm currently using GNU tar 1.13.25 and FreebBSD 4.7 on that system. Another anomaly that I find strange is that the dump area is not being used by the remote hosts. The initial amcheck showed no complaints about the holding disk being full or permissions issues. ??? Should I not have used my existing config files and built them from scratch? Anything else I might be overlooking?

Thanks