Re: questions regarding incremental backup sizes
On Wednesday 15 November 2006 10:16, René Kanters wrote: >Hi Gene, > >Sorry about not hitting reply-all. I will from now on! > >So are there instructions regarding the best way to set up amanda to >do backups to a disk as opposed to tape? >I found the sample for using the test environment with virtual tapes >at http://wiki.zmanda.com/index.php/Test_environment_with_virtual_tapes > >I took out the holdingdisk part of that amanda.conf since I assumed >that since I am writing directly (and only) to a disk, that would not >be needed, but your comment suggests that that may not be the proper >way to think about it. > >By the way, where can I look at the mailing list archives to try to >find my answers there? > >Cheers, >René Humm, not sure. I'm pretty sure there is an archive though, look around on www.amanda.org. I finally had to put my own local mbox on a diet, so I only go back about 3 years & thats only for stuff marked important in kmail. kmail begins to get pretty sluggish if the corpus of email it has to handle goes above the 100,000 mark. Obviously this is not the only list I'm on. :-) WRT the holding disk, I believe its use will reduce fragmentation of the main vtapes partition considerably. With roughly 160GB of that disk being erased and re-written every 3 weeks, the fragmentation is staying under 5% or so, and if my boot partition is any indicator, without the holding disk's use I suspect it would be in the 50% range after the nearly 2 years I've been running that way. As to whether or not this is a desirable factor, it may not be since the number of recoveries is quite small and finding the data will take several times longer than recovering it once its found. So at the end of the day it may well be a shrug. BTW, I use some wrapper scripts I wrote that are available at the zmanda site, which make sure that each (v)tape contains its own uptodate index data as well as the amanda configuration that made it. Called Genes-Amanda-Helpers or some such. They give me more piece of mind because each (v)tape doesn't have to fwd reference the next one in order to have (hopefully, I've been bit by file locks) complete indexes. Backwards references for partials work as usual of course when using the recovery tools. [...] -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: questions regarding incremental backup sizes
Hi Gene, Sorry about not hitting reply-all. I will from now on! So are there instructions regarding the best way to set up amanda to do backups to a disk as opposed to tape? I found the sample for using the test environment with virtual tapes at http://wiki.zmanda.com/index.php/Test_environment_with_virtual_tapes I took out the holdingdisk part of that amanda.conf since I assumed that since I am writing directly (and only) to a disk, that would not be needed, but your comment suggests that that may not be the proper way to think about it. By the way, where can I look at the mailing list archives to try to find my answers there? Cheers, René On Nov 15, 2006, at 8:09 AM, Gene Heskett wrote: On Wednesday 15 November 2006 07:50, René Kanters wrote: I've added the list back, please use 'reply all' when replying to any mailing list. That way, the list archives can be searched with a very high probability of finding an answer to the problem you have because someone else already had it and most likely solved it. Which is true for both problems you have asked about so far. :-) Hi Gene, Thanks, that was indeed it. I was wondering whether you know why I get in my amdump.1 a lot of find diskspace: not enough diskspace. Left with 1952 K driver: find_diskspace: time 0.138: want 1952 K and now that my incremental ones are working I get for an increment backup the similar message driver: find_diskspace: time 0.142: want 64 K find diskspace: not enough diskspace. Left with 64 K while my test tapes are 5MB and only backing up a set of files that is 2MB big. By default, the holding disk area is 100% reserved for incrementals. To use it and its highly recommended to save shoe-shining wear and tear on the drive, you should change the keyword Reserved in your amanda.conf to allow it to be used for fulls too. I use 30% here. This 'holding disk' is a buffer area/directory on one of your hard drives that is used as a scratchpad area, where files being compressed are built up until that particular disklist entry is completed, at which point it is all written to the tape at the tape drives (or the interfaces) full speed. Without such a holding disk area setup and in use, any backup that involves compression will be written as the compressor spits it out, so the drive will be stopped and started many times, trying to recue back to where it wrote the last data each time. This wastes considerable time and multiplies the wear on the drive by quite a bit. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: questions regarding incremental backup sizes
On Wednesday 15 November 2006 07:50, René Kanters wrote: I've added the list back, please use 'reply all' when replying to any mailing list. That way, the list archives can be searched with a very high probability of finding an answer to the problem you have because someone else already had it and most likely solved it. Which is true for both problems you have asked about so far. :-) >Hi Gene, > >Thanks, that was indeed it. > >I was wondering whether you know why I get in my amdump.1 a lot of > >find diskspace: not enough diskspace. Left with 1952 K >driver: find_diskspace: time 0.138: want 1952 K > >and now that my incremental ones are working I get for an increment >backup the similar message > >driver: find_diskspace: time 0.142: want 64 K >find diskspace: not enough diskspace. Left with 64 K > >while my test tapes are 5MB and only backing up a set of files that >is 2MB big. By default, the holding disk area is 100% reserved for incrementals. To use it and its highly recommended to save shoe-shining wear and tear on the drive, you should change the keyword Reserved in your amanda.conf to allow it to be used for fulls too. I use 30% here. This 'holding disk' is a buffer area/directory on one of your hard drives that is used as a scratchpad area, where files being compressed are built up until that particular disklist entry is completed, at which point it is all written to the tape at the tape drives (or the interfaces) full speed. Without such a holding disk area setup and in use, any backup that involves compression will be written as the compressor spits it out, so the drive will be stopped and started many times, trying to recue back to where it wrote the last data each time. This wastes considerable time and multiplies the wear on the drive by quite a bit. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: questions regarding incremental backup sizes
On Monday 13 November 2006 08:50, René Kanters wrote: >Hi, > >On my backup with dump/runs/tape cycle settings of /4/4/5, I get for >every backup done that the size of the dump is the same size as the >full backup. When I check the disk files (since I doing backups only >to disk) I do indeed see that all the slots have the same sized >backup in them. > >My amadmin's disklist output is: >[EMAIL PROTECTED] amanda]$ amadmin test disklist >line 1: > host werner.richmond.edu: > interface default > disk /home/rene: > program "GNUTAR" > priority 1 > dumpcycle 4 > maxdumps 1 > maxpromoteday 1 > bumpsize 10240 > bumpdays 2 > bumpmult 1.50 > strategy STANDARD > estimate CLIENT > compress CLIENT FAST > comprate 0.50 0.50 > encrypt NONE > auth BSD > kencrypt NO > amandad_path X > client_username X > ssh_keys X > holdingdisk AUTO > record NO you aren't recording, so I believe amanda hasn't any idea of backup history. > index YES > fallback_splitsize 10Mb > skip-incr NO > skip-full NO > spindle -1 > >and my amdump.1 is as attached. > >Just in case this has anything to do with it, my gtar version is >1.13.25. > >Thanks, >René -- Cheers, Gene
Re: questions regarding incremental backup sizes
On Mon, Nov 13, 2006 at 08:50:42AM -0500, Ren Kanters wrote: > Hi, > > On my backup with dump/runs/tape cycle settings of /4/4/5, I get for > every backup done that the size of the dump is the same size as the > full backup. When I check the disk files (since I doing backups only > to disk) I do indeed see that all the slots have the same sized > backup in them. > > My amadmin's disklist output is: > [EMAIL PROTECTED] amanda]$ amadmin test disklist > line 1: > host werner.richmond.edu: > interface default > disk /home/rene: > program "GNUTAR" > priority 1 > dumpcycle 4 > maxdumps 1 > maxpromoteday 1 > bumpsize 10240 > bumpdays 2 > bumpmult 1.50 > strategy STANDARD > estimate CLIENT > compress CLIENT FAST > comprate 0.50 0.50 > encrypt NONE > auth BSD > kencrypt NO > amandad_path X > client_username X > ssh_keys X > holdingdisk AUTO > record NO It doesn't record when it last did a full backup so it seems like it must always do the initial level 0 each run. > index YES > fallback_splitsize 10Mb > skip-incr NO > skip-full NO > spindle -1 > > and my amdump.1 is as attached. > > Just in case this has anything to do with it, my gtar version is > 1.13.25. > > Thanks, > Ren? > >>> End of included message <<< -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
