Amrecover: Cannot connect, then No index records for host
2003-01-10 19:54:28
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Amrecover: Cannot connect, then No index records for host,
Brashers, Bart -- MFG, Inc. <=
- RE: Amrecover: Cannot connect, then No index records for host, Brashers, Bart -- MFG, Inc.
- RE: Amrecover: Cannot connect, then No index records for host, Brashers, Bart -- MFG, Inc.
- RE: Amrecover: Cannot connect, then No index records for host, Brashers, Bart -- MFG, Inc.
|
Previous by Date: |
Re: dumpcycle - amanda with a mind of its own, Deb Baddorf |
Next by Date: |
RE: Amrecover: Cannot connect, then No index records for host, Brashers, Bart -- MFG, Inc. |
Previous by Thread: |
Does anyone actually use amrecover with indexing?, Brashers, Bart -- MFG, Inc. |
Next by Thread: |
RE: Amrecover: Cannot connect, then No index records for host, Brashers, Bart -- MFG, Inc. |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|