Ah ha! At first it gave a warning for each of my virtual tapes, there
are 80 of them. So then I used rsync to replicate
/var/log/amanda/DailySet1/ from the real backup server to the backup
backup server. At that point, "amadmin DailySet1 find" showed a list of
backups. And now amrecover works on the second server.
I am a little uncertain as to how to pprocede now though. Maybe I could
move the log directory to the NFS share as well. Is that what you'd
recommend?
On 11/02/2016 02:08 PM, Jean-Louis Martineau wrote:
John,
Then it is the tapelist or the log.<timestamp>.0 files that are not
correct.
What 'amadmin DailySet1 find' returns?
It should list all dumps available.
Jean-Louis
On 02/11/16 03:04 PM, John G Heim wrote:
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 <jh...@math.wisc.edu>
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; jh...@math.wisc.edu; sip://jh...@sip.linphone.org
--
--
John G. Heim; jh...@math.wisc.edu; sip://jh...@sip.linphone.org
