Amanda-Users

Re: suggestion for a disk-to-disk backup server

2007-06-26 03:47:17
Subject: Re: suggestion for a disk-to-disk backup server
From: Paul Bijnens <Paul.Bijnens AT xplanation DOT com>
To: Chris Hoogendyk <hoogendyk AT bio.umass DOT edu>
Date: Tue, 26 Jun 2007 09:29:52 +0200
On 2007-06-25 22:43, Chris Hoogendyk wrote:
> 
> Jon LaBadie wrote:
>> On Mon, Jun 25, 2007 at 12:43:50PM -0400, Chris Hoogendyk wrote:
>> ...
>>   
>>> then I created a dumptype that was the same as my regular dumps but with
>>>
>>> record no
>>> strategy incronly

Instead of making it a different configuration, and running into trouble
on which full to base an incrmeental, why don't you run an additional
amdump of the normal config in the weekend, but which has options to
override the config:

   amdump daily -o reserver=100,tapedev=/no/such/tape

With the option "tapedev /no/such/tape" we force Amanda to fall back
to degraded mode, making backup to holdingdisk only, and with the
"reserve 100", we avoid wasting holdingdisk space for full backups in
the degraded mode.

On monday morning, you can choose:
- flush the backup images to tape manually
- autoflush together with the normal backup of the next night

I'm not 100% certain, but I believe you may even erase (some of) the
holdingdisk files, without flushing. I think that Amanda will take into
account that the holdingdisk file disappeared, and schedule the same
incremental level again (or a level 0 if due).  Because there is no
equivalent to amrmtape for a holdingdisk file, and, there are at least
some things implemented that detect the loss of an holdingdisk file.
Would be nice if someone could confirm this.


>>>
>>> I thought this would work, because the incremental would be based on
>>> ufsdump, and it would know there had been a full, even though it was a
>>> different configuration.
>>>
>>> Apparently, I've got this wrong. I'll check through the documentation,
>>> but I thought someone on the list might have done something like this or
>>> know either that it can't be done or how to do it as well as why.
>>> (Possibly, amanda interprets incronly as "iff there has already been a
>>> full at some time under this configuration.")
>>>     
>> ufsdump might have been able to figure out from which date to do the
>> incremental, `IF' it had been asked to do an incremental.
>>
>> However, as this was a new config, amanda "knew" there had never been
>> a level 0 for this config.  And of course it must start from a level 0
>> to do the incrementals.  Even on a config meant to do incronly strategy
>> you must do an initial full dump.


-- 
Paul Bijnens, xplanation Technology Services        Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************