On Jul 25, 2014, at 3:15 PM, Gene Heskett <[email protected]> wrote:

> On Friday 25 July 2014 15:26:00 Debra S Baddorf did opine
> And Gene did reply:
>> I just create two DLEs
>> 
>> mynode  /         backuptype
>> mynode  /boot  backuptype
>> 
>> Then   amdump  myconfig           (  or  amdump  myconfig  mynode  )
>> will get both of them.    Is this not an option for you?
> 
> That would completely hose amanda's ability to spread the levels of the 
> backups out over the cycle in its attempt to make full use of the backup 
> media available.

Huh?  As I see it,  it *allows*  amanda to spread the levels around to different
days.    BUT it is true that “mynode”  may not have both pieces done at level 0
on the same day.
> 
> I could do it, yes, but that is not what amanda is all about.

I thought it was EXACTLY what amanda was all about.
> 
> It would not be a huge problem with vtapes, but for those using individual 
> tapes, that would never fly unless you allowed amanda to use a virtually 
> unlimited number of tapes when it is doing a level 0 backup.

I do use real tapes, not vtapes.   But “doing a level 0 backup” as you put it
implies you are trying to do them all on one day - which isn’t what Amanda is
about.   I have 30 or so nodes, each with 3-8 DLEs.  The level 0s get spread all
around the week  (doing backups each day, with level-0 once per week at 
minimum).  

   When I want to archive a set of tapes containing ALL the level 0s,  then 
I do a separate config that says “all 0”  and yes,  THAT takes more tapes.
But I don’t run it every day.  I do that once a month.

>  I am 
> currently set for about 30Gb per vtape, and it will very occasionally use 
> a few megs of the 2nd vtape.  I'd have to let it use 9 or more of the 30 
> formatted with just 4 entries. 2 on this machine, and the / entries on my 
> pair of cnc boxes.  That backup would also take quite a few more hours to 
> complete, currently in the 1:25 range.

Of course it would take longer to complete —  right now it is skipping
the part that is in  /boot   so it takes much less time.  :)

BUT  forgive me if I’ve missed your point!   Perhaps we have differing
philosophies of how to use amanda.

Deb





> l
> Thanks Deb.
> 
>> Deb Baddorf
>> Fermilab
>> 
>> On Jul 25, 2014, at 1:45 PM, Gene Heskett <[email protected]> wrote:
>>> Greetings;
>>> 
>>> It turns out some of my backups for this machine will not be usable,
>>> particularly for a bare metal recovery on a new drive, due to a miss-
>>> understanding of the --one-filesystem option by tar-1.27, and 1.27.1
>>> does not fix it.
>>> 
>>> The problem is that this system is currently installed with two
>>> partitions, 3 actually if you count swap space.
>>> 
>>> They are /boot, and /
>>> 
>>> So tar refuses to back up a softlink that points to a directory/file 
>>> that is in a different dir than the current disklist entry points
>>> to, EVEN THOUGH IT IS IN FACT on the same filesystem.
>>> 
>>> The config I've been using for a decade and change uses that option
>>> command.  Will removing it (--one-filesystem) from my config fix this
>>> missing links in the backup problem?  Or will that result in its
>>> making a duplicate backup file of what is at the end of that
>>> softlink?
>>> 
>>> IMNSHO, when tar encounters such a link, instead of making a backup
>>> of that file at the end of the link, it should backup the contents
>>> of the links text so that an amrecovery will re-create the link
>>> file.
>>> 
>>> It is not doing that either, so how do, or can, I force tar to do
>>> that and result in a fully usable backup?
>>> 
>>> This does not seem to me to be a violation of the one filesystem
>>> command, making sense ONLY if the link is to a different partition,
>>> which could be a different filesystem, which this present situation
>>> is most certainly not.  Different directory yes, different
>>> filesystem, no.
>>> 
>>> Thanks.
>>> 
>>> Cheers, Gene Heskett
> 
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS


Reply via email to