Amanda-Users

Re: GNUTAR exclude lists not working in Windows or Linux

2005-06-03 09:08:05
Subject: Re: GNUTAR exclude lists not working in Windows or Linux
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Fri, 03 Jun 2005 08:56:27 -0400
On Friday 03 June 2005 06:23, Paul Bijnens wrote:
>Gene Heskett wrote:
>> On Thursday 02 June 2005 17:16, Paul Bijnens wrote:
>>>The documentation is correct:
>>>
>>>   exclude file "./some*thing"
>>>this excludes all the files matching name "some*thing"
>>>   exclude list "/some/file"
>>>/some/file on the client contains a list of patterns
>>>to be excluded
>>
>> I'd argue that point, I'm using 'file' to specify a file that
>> contains a list, and its working just fine.

See below, I'm full of it.  I'd given up making it work and found a 
workaround of sorts.  And had forgotten about it.  Memory, second 
thing to go you know. :)

>To settle the argument, we need some proof, and correct the bug in
>the documentation or correct the bug in your configuration.
>
>I would like to see the entries as you have them defined
>in the disklist, and the output of "amadmin TheConfig disklist"
>(the ultimate interpretation by amanda, after resolving all included
>types) e.g.:
>
>My disklist entry in the test configuration:
>
>amatest    /space/scratch/topdir   user-tar
>
>And then this command would give the ultimate configuration:
>
>$ amadmin test disklist amatest '^/space/scratch/topdir$'
>line 26:
>     host amatest:
>         interface default
>     disk /space/scratch/topdir:
>         program "GNUTAR"
>         exclude list "/var/opt/amanda/exclude.gtar"
>         priority 1
>         dumpcycle 0
>         maxdumps 1
>         maxpromoteday 10000
>         strategy STANDARD
>         compress NONE
>         auth BSD
>         kencrypt NO
>         holdingdisk YES
>         record NO
>         index YES
>         skip-incr NO
>         skip-full NO
>
>Where we can see that the dumptype user-tar somehow has an "exclude"
>defined.
>
>Moreover, when I specify "exclude file /non/existing/file", then
> amcheck does not complain. However with "exclude list
> /non/existing/file", amcheck complains about the non-existing file,
> just as expected.

Here, the file exists, and if I ran a diff against the two outputs of 
the above command, one when its says file, and one when it says list, 
the only diff would be to remove this line:
-exclude file "/amanda/excludes"
with:
+exclude list "/amanda/excludes"

Here is the output of that command for 'file' against coyote /bin:
line 109:
    host coyote:
        interface LOCAL
    disk /bin:
        program "GNUTAR"
        exclude file "/amanda/excludes"
        priority 0
        dumpcycle 5
        maxdumps 4
        maxpromoteday 10000
        bumpsize 10240
        bumpdays 1
        bumpmult 2.000000
        strategy STANDARD
        estimate CLIENT
        compress NONE
        auth BSD
        kencrypt NO
        holdingdisk YES
        record YES
        index YES
        skip-incr NO
        skip-full NO
and here is that same line after changing it to 'list':
line 109:
    host coyote:
        interface LOCAL
    disk /bin:
        program "GNUTAR"
        exclude list "/amanda/excludes"
        priority 0
        dumpcycle 5
        maxdumps 4
        maxpromoteday 10000
        bumpsize 10240
        bumpdays 1
        bumpmult 2.000000
        strategy STANDARD
        estimate CLIENT
        compress NONE
        auth BSD
        kencrypt NO
        holdingdisk YES
        record YES
        index YES
        skip-incr NO
        skip-full NO

Now, lets see if the files I wanted excluded are in the tarballs.

I am indeed wrong!

They are as the /usr/FC3 backup at the last level 0 is indeed 2.3 GB.  
So I am mistaken.  But, if indeed it works while using the word 
'list', then I should remove those 3 dirs from the disklist, and 
re-enable the entries for the individual files, one a day until all 
are enabled again.

An interesting observation here, since I was wrong.  The 'file' usage 
in that event would never have had a 'hit' because while the dumptype 
is specified, thats not the dumptype used to backup the directory 
that file lives in.  And when I started this little exercise this 
morning, that disklist entry didn't use a dumptype that had the 
exclude.

As a test for tonight, I've used a dumptype that specifies the 
excludes list, which will exclude the contents of that directory, but 
then specified just one of the files in that directory with an 
include directive.  So that one then looks like this:

line 195:
    host coyote:
        interface LOCAL
    disk /usr/dlds-misc/FC3/FC3-i386-rescuecd.iso:
        device /usr/dlds-misc/FC3
        program "GNUTAR"
        exclude list "/amanda/excludes"
        include file "./FC3-i386-rescuecd.iso"
        priority 0
        dumpcycle 5
        maxdumps 4
        maxpromoteday 10000
        bumpsize 10240
        bumpdays 1
        bumpmult 2.000000
        strategy STANDARD
        estimate CLIENT
        compress NONE
        auth BSD
        kencrypt NO
        holdingdisk YES
        record YES
        index YES
        skip-incr NO
        skip-full NO

Does this look kosher?

Actually, I should quit backing this FC3 stuff up, I'll probably never 
install it, I'll be jumping to FC4 when the final is out, its in 
test3 now I believe.  FC3 had, IMO, entirely too many teething pains 
& temper tantrums before it was sorted.  Any install that needs an 
additional gigabyte of updates pulled in by yum the minute its booted 
the first time wasn't "simmered" long enough to kill all the bugs 
IMO.  We'll see what happens when FC4 comes out shortly. 

Maybe I'll make this work as I originally intended it to do a year 
ago.  :-)

-- 
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)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.