Amanda-Users

Re: Backup plan needs advice.

2003-06-25 01:50:41
Subject: Re: Backup plan needs advice.
From: "Bao Ho" <bao AT gibbons DOT com>
To: <amanda-users AT amanda DOT org>
Date: Tue, 24 Jun 2003 22:43:34 -0700
This is getting longer and longer. So, I am going to reply to both Jon's and
Gene's emails in this one email.

-----Original Message-----
From: Jon LaBadie <jon AT jgcomp DOT com>
To: Amanda Users (E-mail) <amanda-users AT amanda DOT org>
Date: Tuesday, June 24, 2003 2:57 PM
Subject: Re: Backup plan needs advice.


>On Tue, Jun 24, 2003 at 02:25:20PM -0700, bao wrote:
>>
>> Jon LaBadie wrote:
>>
>> >    strategy "string"
>> >
>> > ...
>> >         incronly
>> >              Only do incremental dumps.  `amadmin force' should
>> >              be  used  to tell Amanda that a full dump has been
>> >              performed off-line, so that it resets to level  1.
>> >              It is similar to skip-full, but with incronly full
>> >              dumps may be scheduled  manually.   Unfortunately,
>> >              it  appears  that Amanda will perform full backups
>> >              with this configuration, which is probably a bug.
>> >
>> >
>> >Also, another dumptype option entry was this paragraph:
>> >
>> >    skip-full "boolean"
>> >         Default:  no.  If true and planner has scheduled a full
>> >         backup,  these  disks will be skipped, and full backups
>> >         should be run off-line on these days.  It was  reported
>> >         that Amanda only schedules level 1 incrementals in this
>> >         configuration; this is probably a bug.
>> >
>> >
>> >
>> As pointed out. The two paragraphs above have "a bug". I prefer not to
>> mess with those options. :)
>
>Well, they say "probably".  Maybe someone was saying this program/feature
>works this way.  Probably not only way it could have been designed
>and maybe not the best choice for the design -- thus a "bug".
>Example, according to the man page for standard unix sort command
>has been the line "silently truncates lines longer than xxxx bytes".
>It could be called a "bug".  But in design and implementation,
>not a defect in coding.
>
>
>Plus, the comments may be a holdover from early releases never updated.
>There are comments a few years back suggesting the "bug" was fixed.
>
>
>BTW you could also consider having your "full config" dump to real tape
>or to a separate set of "file tapes".  Then you could run your daily
>config as a normal amanda config doing a mixture of full and incrementals
>each day.  If you run the full dump to real tape and the clerical person
>forgets the tape, it can collect on the holding disk for later amflush.
>Otherwise you will have to develop your own procedures for moving the
>dumps and the indexes and the ... to tape and later, if needed, you own
>procedures for recovering them and the indexes and ... from the tape
>for am{recover|restore}.
>
As I have two configs and two sets of "tapes" now, but they behave as just
one continuous set of tapes.
If I do as Jon said, dump the full to a real tape, and the inc to a set of
"tapes", then the full to tape and
the full of the daily config probably will not be consistent, as they will
have to be run at different times.

I think someone had given his/her instructions of how to copy the backup
image and the index some while back
(maybe Gene) to tape. I will have to dig more into my collection of mail
from this group to look for it.

I am still leaving it to run with my original two configs and waiting to see
what will happen in the next few days
as the new cycle begins. If it doesn't work out, I will look into what Jon
suggested, one config.

I'm still facing the problem of verifing if the next first incremental will
follow the next full, or the full from the previous
week. Please give me any suggestions you can think of to accomplish this.

Gene, diskspace is not a problem to us. Our data consists of only around 20
GB. We have _plenty_ plenty of hard disk
space (it's very cheap nowadays). Our tape is 20 GB native, expanding to 40
GB with compression.

It's been a very helpful and fun discussion. Many thanks to both Jon and
Gene.
I hope there will be follow-ups.

Cheers.

>--
>Jon H. LaBadie                  jon AT jgcomp DOT com
> JG Computing
> 4455 Province Line Road        (609) 252-0159
> Princeton, NJ  08540-4322      (609) 683-7220 (fax)
>


<Prev in Thread] Current Thread [Next in Thread>