>the speed of our hp surestore seems to be ok, but the amdump takes too much ti
>me 
>  (6 hours for 23 GB, we want to use now client fast compression).

There are several areas that can affect speed, and it's important to
understand the flow of data through Amanda to see where the potential
bottlenecks are:

  * The client dump program reads data from the client disk.

      - How fast is the disk?

      - How fast is the disk -> system connection (e.g. SCSI bus/controller)?

      - Are you backing up lots and lots of little files, which will
        involve more seeking?

  * If you have maxdumps set greater than one, more than one backup may
    be going on at the same time.  If these are backing up separate areas
    on the same physical disk, seeking will slow things down.  You can
    control this with the "spindle" field in the disklist file.

  * If you have client compression enabled, the dump image is run
    through either "compress" or "gzip", depending on how Amanda was
    built.  Using "best" translates to "-9" on gzip, which is known to
    take up to several times as long to compress the data, but with
    minimal improvement in compression ratio (depending on the data,
    of course).

    Also, if maxdumps > 1 and multiple backups are running at the same
    time, that will multiply the system load.

  * The image is then sent over the network to the server.  Are you
    seeing collisions or errors in the network statistics on either side?
    That's often an indication of a duplex mismatch.

    What kind of transfer rate to you get if you do a test ftp from
    client to /dev/null on the server of a few MBytes?

  * On the server side, if you have compression turned on (which cannot
    also be on if client side compression is enabled), the image is sent
    through a compression program and the same points as on the client
    apply.

  * If there was enough space in the holding disk, the image is written
    there.  The same questions that were asked about the speed of the
    client disk apply here.

    In addition, if you have multiple clients or maxdumps > 1, multiple
    images may be stored in the holding disk at the same time which will
    increase seeking.

  * If there is not enough holding disk space, the image will be written
    directly to tape.  How fast is the tape drive?  How fast is the
    interface to it?

    If you are using software compression on either the client or the
    server, make absolutely certain you do not also have hardware
    compression turned on.  In addition to expanding the amount of tape
    space used, this can slow down the transfer.

    As others have said, how hardware compression is enabled or disabled
    is highly OS specific, and you didn't mention what your server
    is running.

Note that I'm not asking you to post answers to these questions to
the list.  They are being presented for you to ask yourself, although,
of course, if you continue to have trouble you might want to share
the details.

My guess from what you've said is that the client is doing "best"
compression and that's killing the throughput.  I'd certainly suggest
dropping that back to "fast".  You might also consider which system is
faster, the client or the server, and shift to doing compression on the
server if it's faster and the extra network traffic (because the whole
image will be transmitted, not the compressed version) warrant.

There are other factors (TCP stream buffer size, routers, bent cable pins,
etc), but the above should be checked out and eliminated first.

>In amanda.conf:
>netusage 600 Kbps # maximum net bandwidth for Amanda, in KB per sec
>But we have a 100mbit LAN, so there should be 10240 kbps, thats right? Or what
> 
>is the meaning of this entry? Which values do you have?

This entry controls whether another backup may be started on a client.
For instance, if Amanda estimates a currently running backup is going
to use 500 Kbps (based on the estimated size and historical speed
information) and a candidate second backup is going to use 200 Kbps, the
second backup will be held up (500 + 200 > 600).  If the first backup is
estimated to use 250, the second will not be held up due to the bandwidth
(interface) limit (250 + 200 <= 600).

Note that several things go into deciding whether a second (or third,
etc) backup may be started -- is there enough holding disk space, is there
an available dumper (inparallel), will the client support another backup
(maxdumps), etc.  Network use is just one constraint.

The interface speed value does **not** control how fast Amanda moves data.
Once data starts flowing, all that is left entirely up to the OS and
hardware.

>In /etc/amanda/interfaces:
>define interface local {
>     comment "a local disk"
>     use 1000 kbps
>}

I use 10000 kbps.  Basically, this is to make sure the interface is not
a limit when dumping local disks (it could even be made much higher).

>define interface eth0 {
>     comment "100 Mbps ethernet"
>     use 10240 kbps
>}

I use 6000 kbps.  No particular reason, except it is somewhat less than
the theoretical bandwidth of 12800 kbps.

>Have to be an /etc/amanda/... - directory also on the client site (in our case
>the file server?)

Not sure what you have in /etc/amanda, but if you're asking if you
need configuration information on the client, such as amanda.conf, the
answer is "no".  Clients do not (currently) have configuration files.
Just the program binaries.

>Dalton

John R. Jackson, Technical Software Specialist, jrj AT purdue DOT edu