Re: restore not finding all incremental levels (SOLVED)
-In response to your message- --received from Jon LaBadie-- On Thu, Apr 19, 2007 at 06:50:44PM -0700, Paul Yeatman wrote: -In response to your message- --received from Jean-Louis Martineau-- Paul Yeatman wrote: So, as I continue to look at the problem, I haven't seen before that an amflush is require for the directories on holding disk to be included in a recovery yet . . . this kinda of seems to be the case now (that is as much a question as it is a statement). I see in the amindexd.###.debug log that it is trying to gzip -dc ... files in the amanda index directory for the disk being restored yet these files don't exist. For instance, the log says this is being executed /bin/gzip -dc '/etc/amanda/cass/index/cass246/_/20070331_6.gz' 2/dev/null | sort '/etc/amanda/cass/index/cass246/_/20070331_6' yet /etc/amanda/cass/index/cass246/_/20070331_6.gz does not exist; It is instead on the holding disk. Does it not exist because I have never run amflush? I swear I've performed tens of recoveries that included files on the holding disk that were (obviously) never amflushed. I'm so confused! amanda will never remove the compressed index files (.gz) while the dump are still on tape or holding disk. You said that you removed some dump from holding disk to debug your previous problem, if you ran amdump while dump was missing, amanda has removed the index file. Ah, I get it! I have another Amanda server to check with and do indeed see that all backups on the holding disk have an associated .gz file in the index directory. I CLEARLY need to change this yet, until now on this server, I have been filling a holding disk, leaving those backups there, and then changing my amanda.conf to point to a new [blank] holding disk. I always figured that in the event of a needed restore, I could change my amanda.conf to point to ALL holding disks. There was a reason I was doing this that I won't bore everyone with now. So now I see that, when changing to a new (empty) holding disk, all my previous, compressed, index files where flushed upon the next amdump run! Yikes!!! This is bad!! The good news is that the data is still there!!! But, boy, sure takes away the power of amrecover! I had no idea the consequence of this! I hope you have a backup of your index files. I suppose in a way I do but, given the current state of things, it seems it would be impossible to figure out what needs to be restored to correctly repopulate my index directory. I will hope for the time being that no restores will be needed until I create stable holding disks and repeat full backups of everything. In the meantime, should a restore be necessary, I will resort to an 'amadmin ... info' of the disk in conjuction with sequential hand-run amrestore's. Shouldn't be too major a job as you are only talking about restoring a single directory tree, the index directory tree. As the dumps are on disk, once you figure an an appropriate command line, you may even be able to automate it with a small shell script/loop. Be aware that you can specify multiple holding disks in your config. And as one of the holding disk parameters is use, you could even specify an appropriate use value for your old holding disk that makes it seem full. Then no more dumps will be added there but the old dumps will still be available for recovery. Thanks again for this! I am aware I can specify multiple holding disks and will do this from now on. I'm surprised that it has been as difficult as it has to make the disks appear full to AMANDA, however. I am using directories on the same RAID disk as holding disks and thus first tried specifying a negative Gigabyte value that was larger than the amount of space available on the RAID disk, for example I specified use -250 Gb when there is roughly 240 Gb available. Strangely, the next backup still used all directories on this disk. As my understanding of specifying use 0 Mb means use all space available, the best I've been able to come with is use 1 Mb which seems to be the smallest amount of space I can specify. This of course means, not very much, but some data is undesirably written into all holding disks (directories) every backup. I feel like I'm not quite understanding how this is supposed to work. When trying various use values, for instance, I don't quite understand what amcheck is trying to tell me. If I set use -250 Gb on one of the holding disks, for instance, amcheck tells me WARNING: holding disk /backup/vtc1/cass: only 238115672 KB free (4032823296 KB requested) The roughly 240 G free is correct but 4 Tb requested??? How does this relate to use -250 Gb? Don't get it! Paul -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ
Re: restore not finding all incremental levels (SOLVED)
-In response to your message- --received from Jean-Louis Martineau-- Paul Yeatman wrote: So, as I continue to look at the problem, I haven't seen before that an amflush is require for the directories on holding disk to be included in a recovery yet . . . this kinda of seems to be the case now (that is as much a question as it is a statement). I see in the amindexd.###.debug log that it is trying to gzip -dc ... files in the amanda index directory for the disk being restored yet these files don't exist. For instance, the log says this is being executed /bin/gzip -dc '/etc/amanda/cass/index/cass246/_/20070331_6.gz' 2/dev/null | sort '/etc/amanda/cass/index/cass246/_/20070331_6' yet /etc/amanda/cass/index/cass246/_/20070331_6.gz does not exist; It is instead on the holding disk. Does it not exist because I have never run amflush? I swear I've performed tens of recoveries that included files on the holding disk that were (obviously) never amflushed. I'm so confused! amanda will never remove the compressed index files (.gz) while the dump are still on tape or holding disk. You said that you removed some dump from holding disk to debug your previous problem, if you ran amdump while dump was missing, amanda has removed the index file. Ah, I get it! I have another Amanda server to check with and do indeed see that all backups on the holding disk have an associated .gz file in the index directory. I CLEARLY need to change this yet, until now on this server, I have been filling a holding disk, leaving those backups there, and then changing my amanda.conf to point to a new [blank] holding disk. I always figured that in the event of a needed restore, I could change my amanda.conf to point to ALL holding disks. There was a reason I was doing this that I won't bore everyone with now. So now I see that, when changing to a new (empty) holding disk, all my previous, compressed, index files where flushed upon the next amdump run! Yikes!!! This is bad!! The good news is that the data is still there!!! But, boy, sure takes away the power of amrecover! I had no idea the consequence of this! I hope you have a backup of your index files. I suppose in a way I do but, given the current state of things, it seems it would be impossible to figure out what needs to be restored to correctly repopulate my index directory. I will hope for the time being that no restores will be needed until I create stable holding disks and repeat full backups of everything. In the meantime, should a restore be necessary, I will resort to an 'amadmin ... info' of the disk in conjuction with sequential hand-run amrestore's. Thanks Jon and Jean-Louis! Paul Jean-Louis -- Paul Yeatman (858) 534-9896[EMAIL PROTECTED] == ==Proudly brought to you by Mutt== ==
Re: restore not finding all incremental levels (SOLVED)
On Thu, Apr 19, 2007 at 06:50:44PM -0700, Paul Yeatman wrote: -In response to your message- --received from Jean-Louis Martineau-- Paul Yeatman wrote: So, as I continue to look at the problem, I haven't seen before that an amflush is require for the directories on holding disk to be included in a recovery yet . . . this kinda of seems to be the case now (that is as much a question as it is a statement). I see in the amindexd.###.debug log that it is trying to gzip -dc ... files in the amanda index directory for the disk being restored yet these files don't exist. For instance, the log says this is being executed /bin/gzip -dc '/etc/amanda/cass/index/cass246/_/20070331_6.gz' 2/dev/null | sort '/etc/amanda/cass/index/cass246/_/20070331_6' yet /etc/amanda/cass/index/cass246/_/20070331_6.gz does not exist; It is instead on the holding disk. Does it not exist because I have never run amflush? I swear I've performed tens of recoveries that included files on the holding disk that were (obviously) never amflushed. I'm so confused! amanda will never remove the compressed index files (.gz) while the dump are still on tape or holding disk. You said that you removed some dump from holding disk to debug your previous problem, if you ran amdump while dump was missing, amanda has removed the index file. Ah, I get it! I have another Amanda server to check with and do indeed see that all backups on the holding disk have an associated .gz file in the index directory. I CLEARLY need to change this yet, until now on this server, I have been filling a holding disk, leaving those backups there, and then changing my amanda.conf to point to a new [blank] holding disk. I always figured that in the event of a needed restore, I could change my amanda.conf to point to ALL holding disks. There was a reason I was doing this that I won't bore everyone with now. So now I see that, when changing to a new (empty) holding disk, all my previous, compressed, index files where flushed upon the next amdump run! Yikes!!! This is bad!! The good news is that the data is still there!!! But, boy, sure takes away the power of amrecover! I had no idea the consequence of this! I hope you have a backup of your index files. I suppose in a way I do but, given the current state of things, it seems it would be impossible to figure out what needs to be restored to correctly repopulate my index directory. I will hope for the time being that no restores will be needed until I create stable holding disks and repeat full backups of everything. In the meantime, should a restore be necessary, I will resort to an 'amadmin ... info' of the disk in conjuction with sequential hand-run amrestore's. Shouldn't be too major a job as you are only talking about restoring a single directory tree, the index directory tree. As the dumps are on disk, once you figure an an appropriate command line, you may even be able to automate it with a small shell script/loop. Be aware that you can specify multiple holding disks in your config. And as one of the holding disk parameters is use, you could even specify an appropriate use value for your old holding disk that makes it seem full. Then no more dumps will be added there but the old dumps will still be available for recovery. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
