Paul Bijnens wrote:
<snip>

Common misconcepton.  Amanda actually only schedules and manages
the backup, but the backup itself is done by another program,
dump or gnutar or smbclient currently.  You run into limitations
of the dump/restore programs (supplied by the OS).
Dump or restore does not have any intelligence build into
that can fast skip forward in a tape device (much too device
dependant probably).

The fast skip forward only works on a "file" on tape.  Amanda
makes one tapefile for each backup image.  A possibility
is to split up the one huge filesystem into smaller ones, where
fsf can skip over in less than a minute.

But from the statistics below, you can see the dump itself
took 1 hour 43 minutes.  The restore was done in about one
hour and a half, about in the time I would have expected.

Ok...  Not ideal but at least it's working as designed.

Actually, depending on where the file is located in the
complete backup image, you can have the file restored already
after a few minutes if you're lucky.

The restore program does not break off, after restoring
that one file, but reads the rest of the image, comparing
each file to the list to be restored.  I never tried this
with restore, but using gnutar, I just hit ctrl-C when the
file is restored to the filesystem.

<snip>

Yeah I watched for it and the directory structure was created
right away but the file didn't appear till the end. :(

Tip:  have a look a the "columnspec" directive in amanda.conf to avoid
this kind of unreadable output where columns run together without space
between them.

Thank you for everything!