On Wednesday 09 October 2002 22:39, [EMAIL PROTECTED] wrote: >> "dumpcycle 4 weeks" >> >> This is a very long time for amanda to go thru the system making >> sure she has one full backup of everything in your disklist. >> Most run this at 1 week, or 7 days, although a business user may >> want that to be a bit shorter just so there is less to play >> catchup with in the event you are forced to recover from the >> last full backup. A weeks worth of business transactions to have >> to repeat is drudgery that sexytaries have been known to quit >> over. > >Well I put 4 weeks because it was preposed that we do a full >backup once a month. The amount of data that I am dealing is 2.1TB
Whats that 2.1 TB of data worth? Is it business related, or home, like a collection of music that could be recovered from the cd's if its lost? I'm not sure if anyone here would recommend only a monthly full cycle in any event just because its so many more tapes to access to bring everything up to date again when disaster strikes. >If I understand you creectly if I shorten it to something like >1 week then it will be eaiser forme to do a restore. Were there > other benefits as well to shortning this options? > >> "runspercycle 4 weeks" >> >> If amanda takes the weeks arguement as it takes it in terms of >> dumpcycle, this is a total of 28 runs in one of your very >> elongated dumpcycles, intimating that it will be run every nite. >> Nothing wrong with the every night run, most of us do it. Most >> situations would seem to want something in the line of 7 and 7 >> for the above pair of variables. You may have to stretch it out >> to make it fit on the tapes, but given amanda's ability to try >> to equalize the amount of data taped each night once she gets >> into the rythm of things, you probably could take the size of >> the data after compression, divide that by runspercycle, and by >> adjusting runspercycle and dumpcycle so it uses about 3/4ths of >> a tape per run. > >If I choose 7 then your right I am going to have to strech it >out but I am not sure how to do this. With the size of data >that I am dealing with this will seem terribly complicated. >I take if I go this way then I am going to have to play with >the bumpsize. While that may be usefull (I've not done the math as I don't know the capacity of your drive and how many tapes its robot can hold) its not something I'd adjust until a schedule has been worked out by amanda. Amanda isn't designed to do a full on day x,and partials in between times. Amanda is designed to equalize the tape useage from run to run, doing a full on this disklist entry while doing a partial on that entry. She will advance fulls to even out this tape useage, so any one tape will have a mixture of fulls and partials on it. What dumpcycle and runspercycle does is tell her how many days she has to schedule a full of everything in the disklist. With both of those at 4 weeks, thats 28 runs to spread it out over. But with tapecycle set for only 25 tapes, it is out of tapes before a full on everything has been done, and will not knowingly overwrite an unduplicated full from an earlier run. > >> "tapecycle 25 tapes" >> >> Here you have insufficient tapes for the elongated dumpcycle >> chosen as it would take a minimum of 28 tapes to satisfy the >> runspercycle above. Amanda therefore has no tape she can use >> for the next backup unless you label at least 3 new tapes and >> increment the tapecycle to match. > >I am curious why you say 28 instead of 25. I think you added >three because of the option I have runtapes. runtapes is yet another variable that didn't enter into what I wrote previously. I got the 28 from 4 weeks times 7 days. Note that if allowed to use more than one tape per run, this means in your case, 3 x 4 x 7 tapes or 84 tapes just for 1 full cycle. > Also another >question what exactly do you mean by increment the tape cycle. In order for amanda to have enough tapes to do one full dumpcycle of backups. Most prefer to have at least 2 full dumpcycles of fulls on hand. >> 25 tapes is normally enough, but I'd shorten both the dumpcycle >> and runspercycle until it both fits on the tape, and you have at >> least 2 full dumpcycles worth of full backups on hand at any one >> time. I haven't run into this, so I have no idea if amanda will >> reuse the oldest tape if you do nothing more than reduce the >> dumpcycle and runspercycle to match the tapecycle. Its worth a >> try just for effects. :-) > >Could you be a little more specific as to the benefit of this :) Yes, the ability to have on hand at least 1 full backup of everything in your disklist. >> Not having any idea of how much data you have to cover, what I >> would do is to reduce the dumpcycle and runspercycle in unison, >> first to 14 days each, and let amanda play catchup with that for >> one dumpcycle or maybe two. Watching the tape usage report >> amanda mails you, then reduce it one or 2 each cycle until she >> is using about 3/4ths of a tape every night. With only a 46 gig >> drive here, part of which is an rsync'd mirror of my gateway >> machine, I'm only averageing about 50% usage per nightly run on >> DDS2 tapes. At 4g rated capacity, its about 2gigs that actualy >> gets written to tape after compression. And its all covered at >> least once a week. > >I am dealing will a little bit over 2.1tb of data. What do you > mean play catch up with that for one dumpcycle or maybe two. When amanda has worked out a schedule that supposedly fits both the amount of data, and the time in runs available to achieve this, then it has to go thru a short period of re-adjustment when the dumpcycle and runspercycle are re-adjusted. To aid amanda in getting started, its common to add just a few more entries to the disklist each day until the system is fully described. Doing it that way helps to keep amanda from trying to do a full of the whole thing in one swell foop, making the startup and initial schedule easier and smoother to do. With 2.1 TB all in one gulp, it will pretty much use up a good sized robots library on the initial run, and then sit around advancing fulls that aren't due to be done till the tape useage per run has been more or less equalized. > Forgive me lack of sleep but the Sentence starting with Watching > the tape usage is confusing. Your scenerio states you have a > 46gig drive and that your full backups is about 2gigs in capcity > is that accurate. Can you possibly give me a scenrio of my case. Without knowing the capacity of your library, I'd be whistling in the dark. What I'm trying to do is to point you in the right direction to understand how to get a working system characterized for your situation. Once you get the hang of it, it will be obvious to you what needs to be adjusted next. For instance, no one entry in the disklist should be more than about 45% of a tape, and if runtapes at 3 is the norm, I'd shoot for even less as this will reduce the wasted tape when amanda has to move to the next tape and restart the failed dump of that disklist entry on a fresh tape. However I don't think I'd try to hit the 10% of a tape mark since that would no doubt result in a huge disklist. OTOH, I'm not aware of a limit to the number of entries in the disklist. Mine is 37 lines, but this is a small home system. By "breaking up" the disklist, I'm refering to such as my /usr partition, which is entered as /usr/bin, /usr/etc, /usr/local, etc until all the subdirs are included, each on its own line, but all specified as being on the same spindle to reduce the pounding of the seek mechanism somewhat as amanda won't try to access two different data streams on the same drive simultainously if this is specified in the disklist. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.17% setiathome rank, not too shabby for a WV hillbilly
