Ok, it appears lots of people successfully use amrecover with indexing, so
here's my sob story...

For the first time ever (after testing during setup, that is) I need to
recover a file from my amanda tapes (Amanda version 2.4.2p2).  The same
machine holds the disks, is the amanda server, and is the tape server.  

So I become su, cd to the directory listed in my disklist, and type
"amrecover" (since my default set is Daily).  I get:

[root]% amrecover Daily
AMRECOVER Version 2.4.2p2. Contacting server on foo.bar.com ...
amrecover: cannot connect to foo.bar.com: Connection refused

I tried a bunch of things, including re-compiling (my subnet had changed,
thus changing the IPs of the server).  After looking closely at the
FAQ-o-matic, I changed /etc/xinetd.d/amandaidx to have "wait = no" (it was
"wait = yes") and restarted xinetd.  I've included the above in this email
so other users can find the fix in the archives.  This produced better
results:

[root]% amrecover
AMRECOVER Version 2.4.2p2. Contacting server on foo.bar.com ...
220 foo AMANDA index server (2.4.2p2) ready.
200 Access OK
Setting restore date to today (2003-01-10)
200 Working date set to 2003-01-10.
200 Config set to Daily.
501 No index records for host: foo.bar.com. Invalid?
Trying foo.bar.com ...
501 No index records for host: foo.bar.com. Invalid?
Trying foo ...
200 Dump host set to foo.
Can't determine disk and mount point from $CWD

And yet the entry in /var/lib/amanda/Daily/index/foo for the directory in
question exists, and has 20030109_3.gz in it from last night's dump.  That
file even lists the file I need to recover.  

I'm using gtar 1.13.19, so that's ok.  I tried "amrecover -C Daily -s foo -t
foo", with the same result.  

I was able to extract the file I needed by using amrestore (along with a
bunch I didn't, and only on the 2nd identical try).  So I'm off the hook for
now, but I feel I should fix this so it's not an issue the next time I need
to restore a file.

I have "index yes" in the dumptype "global", but in one of my dumptypes I
had just "index" on the line, no "yes" or "no".  Could this be the issue?  I
don't think so, because the index is there.  The files under
/var/lib/amanda/Daily/index/foo are all owned by amanda:disk; dirs have
permissions "drwxr-sr-x" and files have "-rw-------", so amanda should be
able to read them all.

The disklist entry:

foo /data     my-low-tar

i.e. not the FQDN, just "foo".  The relevant dumptypes:

define dumptype global {
    index yes
    record yes
}
define dumptype root-tar {
    global
    program "GNUTAR"
    compress none
    exclude list "/usr/local/lib/amanda/exclude.gtar"
    priority low
}
define dumptype my-low-tar {
    root-tar
    compress none
    priority low
    index
}

So the only possibility for things I'm doing wrong I see is using disklist
entries like:

foo.bar.com /data     my-low-tar

but the example disklist that comes with the tarball doesn't use FQDNs...

Any hints would be greatly appreciated.

Bart
---
Bart Brashers                       MFG Inc.
Air Quality Meteorologist           19203 36th Ave W Suite 101
bart.brashers AT mfgenv DOT com            Lynnwood WA 98036-5707
http://www.mfgenv.com               425.921.4000 Fax: 425.921.4040