Re: restoring from vtapes on client machine
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..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 9efefbff3f Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: < 200 FEATURES 9efefbff3f 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 "\n GNUTAR\n /etc\n BSDTCP\n FAST\n YES\n YES\n AMANDA\n\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 n
Re: restoring from vtapes on client machine
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 9efefbff3f Wed Nov 2 14:01:10 2016: thd-0x55d0b8434400: amindexd: < 200 FEATURES 9efefbff3f 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 "\n GNUTAR\n /etc\n BSDTCP\n FAST\n YES\n YES\n AMANDA\n\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 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
Re: restoring from vtapes on client machine
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 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
Re: restoring from vtapes on client machine
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 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 >
Re: restoring from vtapes on client machine
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
restoring from vtapes on client machine
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
