On Thursday 24 July 2003 10:56, Yogish wrote: >Hi >I was successfully able to perform a backup yesterday,thanks all of > your help. I have a couple of doubts (trivial I'm sure). 1.How can > I restore just a few files from a complete backup, for testing. 2. > I want to do I complete backup,once a week and the incremental > backup the remaining days,however when I try to backup data for the > first time on tape, should I specify to amanda to do full backup or > it will only do it. 3. Can I get a good documentation for Amanda? > Please help if you can >Regards >Yogish
I'll let someone else discuss the recovery techniques, so I'll just address #2 above. There are also a few links to some pretty good help that others will no doubt post. Generally speaking, you will 'get along' with amanda a lot better if you let amanda do it her way. The primary difference in how amanda works vs the rest of the world is that amanda can adjust the backup schedueling with a target of using the same amount of tape per run, prefereably nearly all of it. That means that amanda will do some fulls, and some incrementals every run. This is why you set such things as dumpcycle to be the amount of time that amanda has in order to do a full backup of everything in your disklist. Set for 7 days, or 1 week, then amanda will attempt to get a full of everything in that 7 days. Then you have to tell amanda how many runs she has in that 7 days because some people don't run it on the weekends, so if you don't, then 'runspercycle 5' Then amanda needs to know how many tapes she can use at one time, this is 'runtapes' and is normally set to one unless you have both a changer so amanda can advance to the next tape, and enough tapes available. Then finally, one needs to have at least enough tapes in the pool to allow at least (for good practices anyway) 2 full runspercycle*runtapes*2 tapes, prefereably even a few more. This is called 'tapecycle'. When first starting up amanda, only expose in the disklist, one tapes worth of entries per run, this because amanda must do a full before she can do an incremental, and by starting amanda up with a starter schedule, amanda will get into 'balance' with the tape useage per run a couple of dumpcycles faster. Trying to make amanda do a full on friday night, and incrementals the rest of the week can be done, but not only wastes tapes by doing wildly differing sizes of backups depending on the run, and labeling the tapes for the day of the week you will find will be an exersize in futility. The tape useage will be out of step with the tape labels in 2 weeks or less, for any one of a hundred reasons. I'm just a home user, running dirt cheap DDS2 tapes in a 4 tape changer so I have: dumpcycle 7 days runspercycle 7 runtapes 1 tapecycle 28 This is adequate to cover around 33Gb of real data on 2 machines, with 40 some entries in the disklist, and using 90 or more percent of a 4 Gb DDS2 tape (hardware compression is off, software is on for selected disklist entries) each night. You will probably have more data, probably much more, so the tape drive and tape capacity would be scaled up accordingly. Since its an axiom of the business that tape speeds go up pretty much in step with the capacity, then the actual times to do these backups remains fairly consistent. With my old slow DDS2 setup, its about a 2.5 hour run each night. I mentioned hardware compression being turned off, and recommend that it be off for several reasons. 1. with it on, amanda's count of bytes fed to the drive is meaningless because the drive is modifying that invisibly to amanda. This means that to prevent hitting the EOT of the tape, you have to reduce the size of the tape in its tapetype by some fudge factor you can only guess. 2. With hardware off, and software being used on those DLE's that can be compressed (a directory full of .bz2;s, .gz's, and rpm's will not further compress and may even grow some) can be compressed better than the hardware can do, sometimes much better, so you use the tapetype sizeing for the native tape size. Amanda then knows how big the tape is, and can stuff it to the brim. The tradeoff of course is the cpu horsepower to do the compression. However this becomes a never mind when you can offload the compression to the client machine because then several compressors can be running in parallel, and the network bandwidth is reduced by the resultant smaller files being shipped back to the server. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
