Amanda-Users

Re: Backup plan needs advice.

2003-06-24 17:18:31
Subject: Re: Backup plan needs advice.
From: bao <bao AT gibbons DOT com>
To: gene.heskett AT verizon DOT net
Date: Tue, 24 Jun 2003 14:14:59 -0700
Sorry I should have answered your other questions in the same email. But I just...saw them :)

Gene Heskett wrote:

On Tuesday 24 June 2003 12:38, bao wrote:
Hello,

After a very long and hard time struggling with Amanda, I figured
out that it's the Athlon bug, and have
switched to an Intel. Now it works.

The Athlon Bug? Sorry, please elucidate on this subject, its entirely new to me as I have been running amanda on an Athlon DX1600 for 2 years with no problems I didn't create. Likewise for around 3 years on a K6-II and then a K6-III.


However, I am still confused of
some things regarding the backup
plan, and hope someone will help me answer them.

I would like to back up everyday, in incremental, and a weekly full
backup once a week, on a specified
day. Let the full be on Monday, and the incrementals be on the rest
of the week. I now have to configs:

I believe the word is two?

1. Weekly: has dumpcycle=0, runspercycle=1, tapecycle=1,
strategy=noinc, index=yes, and record=no
2. Daily:  has dumpcycle=7, runspercycle=6, tapecycle=6,
strategy=nofull, , index=yes, record=yes

The Weekly full will call amadmin to set to run level 0 before it
runs.

Q1: If I want the incrementals of a week to follow from that week's
full, how do I set the record??
(Mon : level 0, Tues-Sun : level 1 - backing up any changes from the
most recent Monday)

Q2. The Weekly full backup will be transferred to tape with a cycle
of 8 tapes, then rotate. What do
I need to copy to tape beside the backup image?? index ?? log ??
debug files ??

Thank you all,

Me, gets up on shaky old soapbox.

While amanda can be forced to do it that way, thats not how amanda was designed to run.
I guess, _whispering_, that my boss is too cheap to get a commercial product that suits
his needs. Everyone has been asking me, "Why not let Amanda do it her way?".
My answer is: "My boss says, 'Why not let it work MY way??' "
I give up. ;)

Whats wrong with letting amanda do it her way?

Letting Amanda do it her way will scatter the full backup out to many tapes (I believe). And yes, we want a bulky full backup each week, then many small incremantals during the weekdays. We don't mind about inefficient usage of tape. The weekly will stay on disk, and also go to tape. BTW, that weekly copy will be erased as the tapes rotate. The incrementals
stay on disk for quick recovery from disk instead of from slow tape.
The weekly stays on disk for the same purpose.


The result is the same in that you'll have a good backup strategy. Doing it amanda's way will result in similar amounts of data being backed up up each night because amanda will adjust the schedule over many runs trying to do just that.

Doing it your way will get you one huge backup you'll have to babysit if you don't have a changer, and very little tape useage during the week, but the tapes will still be used. Doing it amanda's way you can use a much smaller tape, and use about 90% of it every night.
One reason for doing it this way is: If the full runs on a holiday when no one is in, it is left on the disk and we have six full days to flush it to tape by hand any time we
want, by any way we like.

We have our secretary as the tape changer :)
She has very little thing to do, I believe.

Somehow, that seems to be the more efficient method of the two.

I'm a home user, backing up just two machines, with a total drive capacity of about 170Gb, but only maybe 65Gb in the disklist, with a dumpcycle=7, runspercycle=7, tapecycle=28, runtapes=1, and doing it to 4Gb uncompressed DDS2 tapes.

To demo how this works, from last nights email:
-------
These dumps were to tape DailySet1-02.
The next tape Amanda expects to use is: DailySet1-03.


STATISTICS:
                         Total       Full      Daily
                       --------   --------   --------
Estimate Time (hrs:min)    0:19
Run Time (hrs:min)         2:54
Dump Time (hrs:min)        0:29       0:05       0:24
Output Size (meg)        3551.3     3168.6      382.7
Original Size (meg)      4025.1     3168.6      856.5
Avg Compressed Size (%) 38.2 -- 38.2 (level:#disks ...)
Filesystems Dumped           44          6         38   (1:35 2:3)
Avg Dump Rate (k/s)      2055.8    10628.0      267.8

Tape Time (hrs:min)        2:34       2:17       0:17
Tape Size (meg)          3551.3     3168.6      382.7
Tape Used (%) 96.6 86.2 10.4 (level:#disks ...)
Filesystems Taped            44          6         38   (1:35 2:3)
Avg Tp Write Rate (k/s)   393.8      393.9      392.7

USAGE BY TAPE:
 Label              Time      Size      %    Nb
 DailySet1-02       2:34    3551.3   96.6    44
------------
Thats not the whole email from amanda of course, but it shows several things.

First, last nights run apparently covered mostly level 0 DLE's that aren't compressed or can't be compressed. When the opposite is true, I have seen the Original size line display figures above 10Gb. From the June 3rd run for instance:

Output Size (meg)        3560.0     3416.8      143.1
Original Size (meg)     10003.3     9746.4      257.0

Second, that amanda used what it thought was 96.6% of the tapes capacity, which I have reduced slightly in the tapetype in order to save room for about 100 megs of stuff I append to the end of the tape after amanda is done.

Third, that those DLE's which are set to be compressed, compressed to 38.2% of their original size. It will vary some, but thats typical, and it beats the socks off of useing hardware compression. Those DLE's I don't compress cannot be compressed by the hardware compressor either, and may in fact grow some.

Me, falls off collapsing soapbox, skins elbow. ;-)