Amanda-Users

Re: How testing a new backup system in parrallel with the old one ?

2005-09-05 09:58:12
Subject: Re: How testing a new backup system in parrallel with the old one ?
From: rangzen <lipare AT gmail DOT com>
To: amanda-users AT amanda DOT org
Date: Mon, 5 Sep 2005 15:36:25 +0200
Ok, it takes long time to configure this f**** changer ...

I tried your solution but with this lines in disklist
mars /u1/mars /u1 comp-user-tar
mars mars_u2 /u2 comp-user-tar

i have an error :
"/usr/local/etc/amanda/Set/disklist", line 4: undefined dumptype `/U1'
"/usr/local/etc/amanda/Set/disklist", line 5: undefined dumptype `/U2'

Is there a compilation option or the disklist is standard ?
It seems than it didn't take care of the name ...

2005/8/25, Jon LaBadie <jon AT jgcomp DOT com>:
> On Thu, Aug 25, 2005 at 05:17:50PM +0200, rangzen wrote:
> > Hello,
> >
> > i use amanda with a single DAT, now, i have a new automatic charger of
> > 8 DAT, i want test it and run both system during one month to be sure
> > of not loosing something.
> > Is it possible ?
> > How can i configure this ?
> >
> > I found "Can I backup separate disks of the same host in different
> > configurations?" at
> > http://amanda.sourceforge.net/fom-serve/cache/31.html but i want
> > backup the SAME disks with different configurations.
> >
> > I'm affraid than amanda mix some internal file about what it backuped
> > before or not ...
> 
> It is a very valid concern.  I've been thinking about it and can't give
> a solid answer, but maybe some pointers.
> 
> Any answer depends in part on whether you use gnutar or some version of
> dump to do your backups.  Dump traditionally has used a file in /etc
> called "dumpdates" to track when it did various levels of backups.
> Amanda has followed the same concept for gnutar backups by using a
> file in /etc called "amandates".
> 
> If you are using a dump program amanda may not be able to control what
> goes into /etc/dumpdates.  Thus there is potential for conflict between
> two configs backing up the same filesystem.  Solaris' ufsdump does have
> an option to specify what the entry in /etc/dumpdates should be called
> but I don't know if that is common to 'all' dumps or if amanda uses it.
> Your only solution in that case is to use the "record no" setting for
> one config telling amanda not to update the /etc/dumpdate records.  That
> will limit you to level 0's I believe for that config I believe.
> 
> If instead you are using gnutar, and thus /etc/amandates, then there is
> a way to avoid conflicts.  This technique should also work if the ufsdump
> option I mention above is common amongst dump programs AND amanda uses it.
> 
> A tiny section of my /etc/amandates file:
> 
>         / 0 1104304406
>         / 1 1104821711
>         /w 0 1104908114
>         /w 1 1104821681
>         /w/Packages 0 1066888427
>         /w/Packages 1 1065851620
>         StaticFS-1 0 1104821741
>         StaticFS-1 1 1058421785
>         StaticFS-2 0 1104908231
>         alpha-dumps 0 1101885483
>         alpha-home 0 1101885469
> 
> Note most entries are directory paths, but the last several are not.
> That is the key.  In your disklist file you can name your entries
> distinct from the path.  The definition of a disklist entry is:
> 
>     host name [device] dumptype [spindle [interface]]
> 
> If all your disklist entry contains is a path, it is considered both
> the device (path) and the entry name.  So in your new config use a
> meaningful name for each of your disklist entries.  Then as far as
> I can recall all info will be recorded for the entry name, not for
> the directory path.
> 
> HTH
> 
> --
> 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)
> 


-- 
liberté - partage - respect
freedom - share - respect