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 clo
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 <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
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 <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
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
Re: virtual tape size (take #3)
Well, something strange is going on and I no longer think it has anything to do with amanda. Here is a segment of the report from amanda from my latest backup: DAILY01 0:0416776767k 100.0 9 9 DAILY02 0:0416777056k 100.0 0 1 So amanda definately thinks it's writing 16Gb to each virtual tape even though the du command says the virtual tape slot has 25Gb: $ du -sh /vtapes/DailySet1/slot1 25G /vtapes/DailySet1/slot1 However, if I copy slot1 to another computer via scp, scp reports that it transfered 16Gb of data. And du on the other computer says 16Gb. The virtual tapes are on a remote file system mounted via NFS. So either writing to an NFS volume expands a file by 50% or (more likely) the du command does not correctly report file sizes on NFS mounted file systems. Anyway, I think that this whole time, the problem was the du command or maybe NFS and not amanda. On 10/25/13 13:19, Jean-Louis Martineau wrote: Hi John, It always works for me. I found a bug, it randomly (not that random) take the value of the tapetype length or the device max-volume-usage property. In my case, it always use the value of the tapetype length, in your case it always take the value of the device max-volume-usage property. Sine your max-volume-usage is 0, it have no limit. Can you retry by setting the tapetype length and the device max-volume-usage property to the same value (max-volume-usage is in bytes). The attached path fix the bug. Jean-Louis On 10/25/2013 12:49 PM, John G. Heim wrote: But that same man page also says, that for the vfs device, This device supports the ENFORCE_MAX_VOLUME_USAGE property. Default value is true. Furthermore, the man page says that if ENFORCE_MAX_VOLUME_USAGE is false, the volumes expand without limit. But that's not what is happening. They are consistently expanding to 150% of the tape length parameter. Like I said, I even predicted that if I set the tape length parameter to 16386 megabypes, it would end up writing 25G to each volume. That was based on the fact that when I set it to 25600 megabypes, it wrote 38G to each volume. That same man page also says, Device properties specified outside of any device definition apply to all devices. Maybe I'll try setting MAX_VOLUME_USAGE and ENFORCE_MAX_VOLUME_USAGE in my amanda.conf and see what happens. I will bet that setting ENFORCE_MAX_VOLUME_USAGE to true will have no effect. One thing that does strike me as odd is that I'm not seeing other questions of this nature while searching the list archives. Maybe it is something weird abut my set up. I'm running debian wheezy and whatever amanda is in debian wheezy. The machine was running debian squeeze last week. Amanda exhibited the same behaviour in squeeze as it is doing in wheezy. I finally upgraded from squeeze to wheezy partly because of this problem. But maybe some misconfiguration got dragged along. But how would the vfs device have gotten misconfigured. I sure didn't do that. On 10/25/13 10:02, Jean-Louis Martineau wrote: man amanda-devices MAX_VOLUME_USAGE (read-write) On devices that support it, this property will limit the total amount of data written to a volume; attempts to write beyond this point will cause the device to simulate out of space. Zero means no limit. The tapetype parameter length sets this property. ENFORCE_MAX_VOLUME_USAGE (read-write) If this property is false, limit set by MAX_VOLUME_USAGE property (and thus the tapetype LENGTH parameter) will not be verified while writing to device, allowing the volume to expand without limit. If this property is true, then MAX_VOLUME_USAGE will be enforced, limiting the total size of the volume. This property is not available on all devices; see below. Set the ENFORCE_MAX_VOLUME_USAGE The tapetype length is use in the estimate phase, so it must be the same as the MAX_VOLUME_USAGE. Jean-Louis On 10/25/2013 09:50 AM, John G. Heim wrote: Last week I asked a few questions about virtual tape size. Well, I wouldn't say I resolved them but I think I have one clue. One of the things I asked about is the meaning of the length parameter for a tape definition. I had set it to 25G for my virtual tapes but amanda was writing 38G to each vtape. This was going to be a problem because I have a quota on my virtual tape file system of 2Tb and I had therefore calculated that I could create 80 25Gb tapes. Here is what the amanda.conf man page has to say about the tape length parameter: length int Default: 2000 kbytes. How much data will fit on a tape, expressed in kbytes. Note that this value is only used by Amanda to schedule which backupswill be run. Once the backups start, Amanda will continue to write to a tape until it gets an error, regardless of what value is entered for length (but see
Re: virtual tape size (take #3)
How do I apply the patch? I installed amanda from the package in debian wheezy. On 10/30/13 09:07, Jean-Louis Martineau wrote: On 10/30/2013 09:32 AM, John G. Heim wrote: Did you mean to tell me to set max_volume_usage or max-volume-usage? I don't see any docs on max-volume-usage (with dashes). But I do find docs on max_volume_usage (with underscores). On the other hand, this does not seem to work: device-property max_volume_usage 26214400 $man amanda-devices PROPERTIES Both the property name and the property value are always quoted. Property names, like Amanda configuration parameters, are not case-sensitive, and - (dash) and _ (underscore) may be used interchangeably. max-volume-usage, max_volume_usage and MAX-VOLUME_USAGE are the same property name. That appears to have no effect. Amanda still wrote 38G to my virtual tapes. Try to apply the patch I sent, it is just three lines to change in the Changer.pm file. If it doesn't works, post the complete output of 'amadmin CONF config' and the complete taper debug file. Jean-Louis On 10/25/13 13:19, Jean-Louis Martineau wrote: Hi John, It always works for me. I found a bug, it randomly (not that random) take the value of the tapetype length or the device max-volume-usage property. In my case, it always use the value of the tapetype length, in your case it always take the value of the device max-volume-usage property. Sine your max-volume-usage is 0, it have no limit. Can you retry by setting the tapetype length and the device max-volume-usage property to the same value (max-volume-usage is in bytes). The attached path fix the bug. Jean-Louis On 10/25/2013 12:49 PM, John G. Heim wrote: But that same man page also says, that for the vfs device, This device supports the ENFORCE_MAX_VOLUME_USAGE property. Default value is true. Furthermore, the man page says that if ENFORCE_MAX_VOLUME_USAGE is false, the volumes expand without limit. But that's not what is happening. They are consistently expanding to 150% of the tape length parameter. Like I said, I even predicted that if I set the tape length parameter to 16386 megabypes, it would end up writing 25G to each volume. That was based on the fact that when I set it to 25600 megabypes, it wrote 38G to each volume. That same man page also says, Device properties specified outside of any device definition apply to all devices. Maybe I'll try setting MAX_VOLUME_USAGE and ENFORCE_MAX_VOLUME_USAGE in my amanda.conf and see what happens. I will bet that setting ENFORCE_MAX_VOLUME_USAGE to true will have no effect. One thing that does strike me as odd is that I'm not seeing other questions of this nature while searching the list archives. Maybe it is something weird abut my set up. I'm running debian wheezy and whatever amanda is in debian wheezy. The machine was running debian squeeze last week. Amanda exhibited the same behaviour in squeeze as it is doing in wheezy. I finally upgraded from squeeze to wheezy partly because of this problem. But maybe some misconfiguration got dragged along. But how would the vfs device have gotten misconfigured. I sure didn't do that. On 10/25/13 10:02, Jean-Louis Martineau wrote: man amanda-devices MAX_VOLUME_USAGE (read-write) On devices that support it, this property will limit the total amount of data written to a volume; attempts to write beyond this point will cause the device to simulate out of space. Zero means no limit. The tapetype parameter length sets this property. ENFORCE_MAX_VOLUME_USAGE (read-write) If this property is false, limit set by MAX_VOLUME_USAGE property (and thus the tapetype LENGTH parameter) will not be verified while writing to device, allowing the volume to expand without limit. If this property is true, then MAX_VOLUME_USAGE will be enforced, limiting the total size of the volume. This property is not available on all devices; see below. Set the ENFORCE_MAX_VOLUME_USAGE The tapetype length is use in the estimate phase, so it must be the same as the MAX_VOLUME_USAGE. Jean-Louis On 10/25/2013 09:50 AM, John G. Heim wrote: Last week I asked a few questions about virtual tape size. Well, I wouldn't say I resolved them but I think I have one clue. One of the things I asked about is the meaning of the length parameter for a tape definition. I had set it to 25G for my virtual tapes but amanda was writing 38G to each vtape. This was going to be a problem because I have a quota on my virtual tape file system of 2Tb and I had therefore calculated that I could create 80 25Gb tapes. Here is what the amanda.conf man page has to say about the tape length parameter: length int Default: 2000 kbytes. How much data will fit on a tape, expressed in kbytes. Note that this value is only used by Amanda to schedule which backupswill
Re: virtual tape size (take #3)
For the record ... 1. Cd to the amanda installation root directory. On debian 7 (wheezy) that is /usr/lib/amanda. 2. Install the patch with the patch command: # patch -p1 fix-max-volume-usage.diff On 10/30/13 09:59, Jean-Louis Martineau wrote: On 10/30/2013 10:44 AM, John G. Heim wrote: How do I apply the patch? I installed amanda from the package in debian wheezy. Use the patch command, or a simple text editor (vi). Look at the patch file, Edit the Changer.pm file, replace the line that start with a '-' by the line that start with a '+' Read the documentation for the diff and patch utilities. Jean-Louis On 10/30/13 09:07, Jean-Louis Martineau wrote: On 10/30/2013 09:32 AM, John G. Heim wrote: Did you mean to tell me to set max_volume_usage or max-volume-usage? I don't see any docs on max-volume-usage (with dashes). But I do find docs on max_volume_usage (with underscores). On the other hand, this does not seem to work: device-property max_volume_usage 26214400 $man amanda-devices PROPERTIES Both the property name and the property value are always quoted. Property names, like Amanda configuration parameters, are not case-sensitive, and - (dash) and _ (underscore) may be used interchangeably. max-volume-usage, max_volume_usage and MAX-VOLUME_USAGE are the same property name. That appears to have no effect. Amanda still wrote 38G to my virtual tapes. Try to apply the patch I sent, it is just three lines to change in the Changer.pm file. If it doesn't works, post the complete output of 'amadmin CONF config' and the complete taper debug file. Jean-Louis On 10/25/13 13:19, Jean-Louis Martineau wrote: Hi John, It always works for me. I found a bug, it randomly (not that random) take the value of the tapetype length or the device max-volume-usage property. In my case, it always use the value of the tapetype length, in your case it always take the value of the device max-volume-usage property. Sine your max-volume-usage is 0, it have no limit. Can you retry by setting the tapetype length and the device max-volume-usage property to the same value (max-volume-usage is in bytes). The attached path fix the bug. Jean-Louis On 10/25/2013 12:49 PM, John G. Heim wrote: But that same man page also says, that for the vfs device, This device supports the ENFORCE_MAX_VOLUME_USAGE property. Default value is true. Furthermore, the man page says that if ENFORCE_MAX_VOLUME_USAGE is false, the volumes expand without limit. But that's not what is happening. They are consistently expanding to 150% of the tape length parameter. Like I said, I even predicted that if I set the tape length parameter to 16386 megabypes, it would end up writing 25G to each volume. That was based on the fact that when I set it to 25600 megabypes, it wrote 38G to each volume. That same man page also says, Device properties specified outside of any device definition apply to all devices. Maybe I'll try setting MAX_VOLUME_USAGE and ENFORCE_MAX_VOLUME_USAGE in my amanda.conf and see what happens. I will bet that setting ENFORCE_MAX_VOLUME_USAGE to true will have no effect. One thing that does strike me as odd is that I'm not seeing other questions of this nature while searching the list archives. Maybe it is something weird abut my set up. I'm running debian wheezy and whatever amanda is in debian wheezy. The machine was running debian squeeze last week. Amanda exhibited the same behaviour in squeeze as it is doing in wheezy. I finally upgraded from squeeze to wheezy partly because of this problem. But maybe some misconfiguration got dragged along. But how would the vfs device have gotten misconfigured. I sure didn't do that. On 10/25/13 10:02, Jean-Louis Martineau wrote: man amanda-devices MAX_VOLUME_USAGE (read-write) On devices that support it, this property will limit the total amount of data written to a volume; attempts to write beyond this point will cause the device to simulate out of space. Zero means no limit. The tapetype parameter length sets this property. ENFORCE_MAX_VOLUME_USAGE (read-write) If this property is false, limit set by MAX_VOLUME_USAGE property (and thus the tapetype LENGTH parameter) will not be verified while writing to device, allowing the volume to expand without limit. If this property is true, then MAX_VOLUME_USAGE will be enforced, limiting the total size of the volume. This property is not available on all devices; see below. Set the ENFORCE_MAX_VOLUME_USAGE The tapetype length is use in the estimate phase, so it must be the same as the MAX_VOLUME_USAGE. Jean-Louis On 10/25/2013 09:50 AM, John G. Heim wrote: Last week I asked a few questions about virtual tape size. Well, I wouldn't say I resolved them but I think I have one clue. One of the things I asked about
virtual tape size (take #3)
Last week I asked a few questions about virtual tape size. Well, I wouldn't say I resolved them but I think I have one clue. One of the things I asked about is the meaning of the length parameter for a tape definition. I had set it to 25G for my virtual tapes but amanda was writing 38G to each vtape. This was going to be a problem because I have a quota on my virtual tape file system of 2Tb and I had therefore calculated that I could create 80 25Gb tapes. Here is what the amanda.conf man page has to say about the tape length parameter: length int Default: 2000 kbytes. How much data will fit on a tape, expressed in kbytes. Note that this value is only used by Amanda to schedule which backupswill be run. Once the backups start, Amanda will continue to write to a tape until it gets an error, regardless of what value is entered for length (but see amanda-devices(7) for exceptions). The device for virtual tapes is vfs-disk or something like that. But I couldn't find anything in the docs for how it determines how much to write to a vtape. If it keeps writing until it got an error, in my case, it would write over 2Tb until it hit the hard quota on the filesystem. So that couldn't be. Then it occured to me that 25 * 150% = 38G. . Coincidence? I recreated the vtapes with a size of 16Gb. Now amanda is writing 25Gb to each tape. My first backup wrote to 11 tapes. Slots 1-10 have 25Gb on them with 19G on the last. The amount of stuff on tapes 1-10 is not exactly the same on each tape but it's a little over 24G each. IMO, this borders on a bug. The wiki strongly implies that you can take your disk file system size and divide by the number of tapes to get the tape size. While the amanda developers aren't responsibe for the wiki being misleading, it is natural to assume the length parameter for a virtual tape is the actual size of the tape. I'm not the only one who made that assumption, so did whoever wrote the wiki entry on virtual tapes. Anyway, I'd still like to know how amanda determines when to stop writing to a vtape. I can put comments in my amanda.conf to say that the tape length is set to 16G so amanda writes 24G to 25G to each tape. But that's hardly an ideal solution. -- --- John G. Heim, 608-263-4189, jh...@math.wisc.edu
virtual tape size
I am trying to replace a physical tape changer with a virtual tape changer on NFS mounted hard disk. I started with the virtual tape configuration on the amanda wiki at http://wiki.zmanda.com/index.php/How_To:Set_Up_Virtual_Tapes. The example tapetype definition on the wiki has a tape size of just 3Gb. But the real tapes I'm using have a capacity of 100Gb uncompressed and 500Gb compressed. That is such a huge disparity that I am uncertain as to how to proceed. I have a quota of 2Tb on the remote file system. My data is about 1.2Tb total. I want to keep about 2 weeks of incremental data and and I get about 20Gb of changes daily. So I think the 2Tb quota is about right but I am uncertain as to how to define the tapes. I googled for questions about amanda virtual tape size and I saw a message from someone who set it at over 100Gb. Someone else responded that it was kind of large but it should work. So I tried setting mine at 80. and configured 25 virtual tapes. That's 20Tb of space. But inspite of going 10x over my quota, I've run out of tapes. I'm guessing that 80Gb is too small. But it seems odd that the example on the wiki would define a tape size of 3Gb. 300Gb seems more realistic unless I am missing something. -- --- John G. Heim, 608-263-4189, jh...@math.wisc.edu
virtual tapes on nfs mounted file system
I want to create virtual taps on an nfs mounted disk. The tricky part is that the disk I'm mounting belongs to another department and they are not going to want to create a user for me to use to write to the disk. I mount the disk like this: mount -t nfs nfs1.example.com:/bigdisk /bigdisk If I create a directory on /bigdisk, it is owned by nobody:root. # mkdir /bigdisk/vtapes/DailySet1/slot01 # ls -l /bigdisk/vtapes/DailySet1/ total 2 drwxr-xr-x 2 nobody root 0 Oct 1 14:49 slot01 Any suggestions as to how to make it possible for the amanda user to write to these virtual tapes? Can I run amanda as nobody? Is there some other trick I can use?
recreating lost changer.conf
I lost my changer.conf file via a hard disk failure. I didn't realize /etc/amanda/DailySet1/changer.conf was a symlink to /var/lib/amanda/DailySet1/changer.conf. So when I restored /etc/amanda/DailySet1 from backup, all I get was a broken symlink. I Does this look right? # cat /etc/amanda/DailySet1/changer.conf firstslot=1 lastslot=15 havereader=1 # mtx -f /dev/nst0 inquiry Product Type: Tape Drive Vendor ID: 'SONY' Product ID: 'SDX-900V' Revision: '0107' Attached Changer API: No # mtx -f /dev/changer inquiry Product Type: Medium Changer Vendor ID: 'SPECTRA ' Product ID: '215 ' Revision: '2204' Attached Changer API: No #mtx -f /dev/changer status Storage Changer /dev/changer:1 Drives, 15 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 11 Loaded):VolumeTag = B53519 Storage Element 1:Full :VolumeTag=B53517 Storage Element 2:Full :VolumeTag=B53509 Storage Element 3:Full :VolumeTag=B53510 Storage Element 4:Full :VolumeTag=B53511 Storage Element 5:Full :VolumeTag=B53512 Storage Element 6:Full :VolumeTag=B53513 Storage Element 7:Full :VolumeTag=B53514 Storage Element 8:Full :VolumeTag=B53515 Storage Element 9:Full :VolumeTag=B53516 Storage Element 10:Full :VolumeTag=B53518 Storage Element 11:Empty Storage Element 12:Full :VolumeTag=B53521 Storage Element 13:Full :VolumeTag=B53522 Storage Element 14:Full :VolumeTag=B53508 Storage Element 15:Full :VolumeTag=B53520
best amanda tutorial/quickstart ?
Any recommendations for the best amanda tutorial or quick start guide? -- John G. Heim jh...@math.wisc.edu 3-4189 http://www.math.wisc.edu/~jheim/
