Oops, I mislead you. There is an error message displayed. It is the
classic no dumps available before this date. I am blind and I just
didn't hear it. I am still as puzzled as ever though. I've cut/pasted a
screen cap of my amrecover session. I'll paste in the amindexd log as well.
I see that amindexd runs as user backup. I checked the user backup has
access to the index files. Recall that in an earlier message, I
mentioned that I moved them to the same NFS share that the vtapes are
on. I made sure the user backup has the same uid and gid on both of the
machines onwhich I am trying this. I am fairly sure the user backup has
access to the index files. In my amanda.conf, it says:
indexdir "/nfs.drive/amanda/DailySet1/index"
Doing an "ls -l" of /nfs.drive/amanda/DailySet1/index, shows that the
files in there are owned by user backup and user backup can read/write
the files. I even ungzipped one of the index files just to make sure.
root@turing:/etc/amanda/DailySet1# amrecover DailySet1 -o auth=local -s
localhost
AMRECOVER Version 3.3.6. Contacting server on localhost ...
220 turing AMANDA index server (3.3.6) ready.
Setting restore date to today (2016-11-02)
200 Working date set to 2016-11-02.
200 Config set to DailySet1.
200 Dump host set to turing.
Use the setdisk command to choose dump disk to recover
amrecover> sethost alpha
200 Dump host set to alpha.
amrecover> setdisk /etc
200 Disk set to /etc.
500 No dumps available on or before date "2016-11-02"
No index records for disk for specified date
If date correct, notify system administrator
amrecover>
--- log ---
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: pid 20291 ruid
34 euid 34 version 3.3.6: start at Wed Nov 2 14:01:10 2016
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: version 3.3.6
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: < 220 turing
AMANDA index server (3.3.6) ready.
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: > FEATURES
ffffffff9efefbffffffffff3f
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: < 200 FEATURES
ffffffff9efefbffffffffff3f
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: > DATE 2016-11-02
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: < 200 Working
date set to 2016-11-02.
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: > SCNF DailySet1
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: pid 20291 ruid
34 euid 34 version 3.3.6: rename at Wed Nov 2 14:01:10 2016
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: < 200 Config set
to DailySet1.
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: > HOST turing
Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: < 200 Dump host
set to turing.
Wed Nov 2 14:01:38 2016: thd-0x55d0b8434400: amindexd: > HOST alpha
Wed Nov 2 14:01:38 2016: thd-0x55d0b8434400: amindexd: < 200 Dump host
set to alpha.
Wed Nov 2 14:01:45 2016: thd-0x55d0b8434400: amindexd: > DISK /etc
Wed Nov 2 14:01:45 2016: thd-0x55d0b8434400: amindexd: no recovery
limit found; allowing access
Wed Nov 2 14:01:45 2016: thd-0x55d0b8434400: amindexd: < 200 Disk set
to /etc.
Wed Nov 2 14:01:45 2016: thd-0x55d0b8434400: amindexd: > OISD /
Wed Nov 2 14:01:45 2016: thd-0x55d0b8434400: amindexd: < 500 No dumps
available on or before date "2016-11-02"
Wed Nov 2 14:01:45 2016: thd-0x55d0b8434400: amindexd: > DLE
Wed Nov 2 14:01:45 2016: thd-0x55d0b8434400: amindexd: < 200 "<dle>\n
<program>GNUTAR</program>\n <disk>/etc</disk>\n <auth>BSDTCP</auth>\n
<compress>FAST</compress>\n <record>YES</record>\n <index>YES</index>\n
<datapath>AMANDA</datapath>\n</dle>\n"
On 11/01/2016 09:29 AM, Jean-Louis Martineau wrote:
Any error message in the amindexd debug file?
It looks like the amindexd process can't read the index files.
Jean-Louis
On 01/11/16 10:26 AM, John G Heim wrote:
I tried both "localhost backup" and "localhost root" in the
amandahosts file. No difference. It is odd -- everything seems to
work. I can connect to the localhost, issue sethost and setdisk
commands. In fact, if I give an invalid host or disk name, I get an
error message. But the ls command just shows no backups. It just
gives an empty list. I feel I am tantilizingly close to making this
work.
On 10/31/2016 03:00 PM, Debra S Baddorf wrote:
Is this related to the .amandahosts file on the server, which
needs to have a line for each client, allowing it to access the
index-process
and maybe the tape-process? I have entries like this:
node.FQDN root amindexd amidxtaped
I’m not certain that both of those are still needed, but there was
at one time a reason I put them there.
Deb Baddorf
On Oct 31, 2016, at 12:35 PM, John G Heim <[email protected]> wrote:
Well, that got me a lot closer. I gave user backup read permission
to /etc/amanda/DailySet1/amanda.conf on the "backup" backup server.
Now when I run amrecover, I can do a sethost and a setdisk. But
after doing so, an ls gives me an empty list. No error message.
It's just that there are no files listed. On the real backup
server, where the backups are actually being made, I do get a list
of files, just as normal. I checked the permissions on the index
and info files. They look right.
Actually, I moved the location of the indexdir and infofile to be
on the same remote nfs share as the virtual tapes themselves. So
when I run amrecover on the backup backup server, it is reading the
same files as it is when I run it on the real backup server. I
think moving those files to the remote nfs server was a good thing,
not just for this use but also, now amanda's index and info files
are in another building. I would still like to be able to use
amrecover on two different hosts in my buildijng though.
On 10/28/2016 10:52 AM, Jean-Louis Martineau wrote:
It is the amindexd process that report the error.
Look at its debug file.
It is run as your amanda user, did it have permission to read
/etc/amanda/DailySet1/amanda.conf.
Jean-Louis
On 28/10/16 11:08 AM, John G Heim wrote:
I am using the ubuntu amanda-server and amanda-client packages
(3.3.6) on ubuntu server 16.04 to backup to virtual tapes on an
NFS mounted file system. Everything is great on the backup
server. I can run amrecover locally and recover files. But I
thought I'd try mounting the NFS share on a client machine to
see if I could recover files that way. I thought if the backup
server ever goes down, I might still be able to recover files on
the client machine.
So I installed amanda-server on the client machine and copied the
contents of /etc/amanda/DailySet1/ to the client. Then I ran:
# amrecover DailySet1 -o auth=local -s localhost
That gives me the error message, ""501 Could not read config file
for DailySet1!". I amd doing this as root. Root does have
permission to open/read /etc/amanda/DailySet1/amanda.conf.
--
--
John G. Heim; [email protected]; sip://[email protected]
--
--
John G. Heim; [email protected]; sip://[email protected]
