Amanda-Users

Re: [RFE] - Footer file on tape

2006-08-20 17:33:28
Subject: Re: [RFE] - Footer file on tape
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Sun, 20 Aug 2006 16:11:43 -0400
On Sunday 20 August 2006 15:11, Geert Uytterhoeven wrote:
>On Sun, 20 Aug 2006, Jon LaBadie wrote:
>> On Sun, Aug 20, 2006 at 01:28:29PM +0100, Chris Lee wrote:
>> > I was wondering if anyone thought it would be a good idea for Amanda
>> > to write a footer file to tape after completing a dump providing a
>> > record of the tapes needed to produce a full restore to the state the
>> > system was in when this tape was written.
>> > I don't use amanda in a way that this would be very useful to me, it
>> > is only for home backups and I have a dumpcycle of 2 so I just need
>> > the last 3 tapes and I am sure to have all I need. However I was
>> > thinking in situations where longer dumpcycles and lots of DLEs are
>> > common it could help with restores if you lose Amanda and her data.
>> > The footer file would just be a list of the tapes from the last level
>> > 0 to now for each DLE.
>> >
>> > For example a file formatted like this, so anyone can read it without
>> > Amanda's help:
>> > /home/bob { //Tapes needed for this DLE
>> > DailySet3 0 Thursday  17/08/2006
>> > DailySet4 1 Friday    18/08/2006
>> > DailySet5 2 Monday    21/08/2006
>> > }
>> > /home/anne { //Tapes Needed for this DLE
>> > DailySet5 0 Monday    21/08/2006
>> > }
>> > etc.
>> >
>> > Restore Set { //list of all tapes needed for all DLEs
>> > DailySet3 Thursday  17/08/2006
>> > DailySet4 Friday    18/08/2006
>> > DailySet5 Monday    21/08/2006
>> > }
>>
>> Interesting idea.  A 32KB trailer file is, I believe, already added
>> to the last tape used in a dump.  I'm not sure I like the idea of
>> adding this data, either as a last file before the trailer, or as
>> part of the trailer.  In a large installation it could get quite
>> large and could result in an extra tape being used if the last
>> DLE nearly filled the tape.
>
>IIRC, Gene has a script to add this info.
>
>Gr{oetje,eeting}s,
>
>      Geert
>
Yes I do Geert, but again, to restrict it to a one tape per run situation 
requires that you lie to amanda via the tapetype size define, and how much 
you may need to trim from the amtapetype derived size can only be 
determined by experimentation.  With my current lashup, a 100 megabyte 
cushion leaves room enough for the 2 tarballs, one of the whole $config 
tree that generated the data during this run (sub 100k), and the $indices 
for the complete tapecycle of tapes including this run so its current with 
the other contents, and thats in the 90 meg territory at the moment.

Whereas I'm running vtapes, the only real limit is the free space on the 
hard drive partition being used for them, and I tend to trim the amanda 
parameters for 85 to 95% utilization of the partition, either by adjusting 
the dumpcycle or the tapesize.  And a rather dust-cloud generating bout of 
house cleaning in my usr/src tree from time to time. :)

Anyone who's interested in those scripts, yell and I'll fwd a tarball of 
the whole tree they were developed in, but be aware that I don't claim to 
be a *real* bash script coder and some who are better qualified may roll 
their eyes in wonder.  OTOH, they've been running here for at least 2 
years and have given me an enhanced feeling of backup dependability.

Humm, that means I'd better write a README since there isn't one (yet)

>--
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert AT linux-m68k DOT org
>
>In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that. -- Linus Torvalds

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.

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