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 K6-III@500mhz 320M
Athlon1600XP@1400mhz 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.
|
