Bacula-users

Re: [Bacula-users] Ignore fileset changes

2011-08-24 07:54:45
Subject: Re: [Bacula-users] Ignore fileset changes
From: Eric Pratt <eric.pratt AT etouchpoint DOT com>
To: Olle Romo <olleromo AT gmail DOT com>
Date: Wed, 24 Aug 2011 04:51:54 -0700
On Wed, Aug 24, 2011 at 1:50 AM, Olle Romo <olleromo AT gmail DOT com> wrote:
>
> On Aug 23, 2011, at 8:43 AM, Adrian Reyer wrote:
>
>> On Tue, Aug 23, 2011 at 01:38:23AM +0200, Olle Romo wrote:
>>> What I mean is that if I have a drive removed, run the job then
>>> attach
>>> the drive and run the job again, Bacula will do a full backup of the
>>> drive even if it previously had done an incremental backup on the
>>> same
>>> drive. Ideally I want it to just continue the incremental backup.
>>
>> Use 2 filesets and 2 jobs. One like you have now, but exclude the
>> removable drive, The other only has the removable dribe and you only
>> run it when the drive is there, e.g. checked by a pre-script.
>>
>> Regards,
>>       Adrian
>
> That will be the way to go. Problem is I have quite a few drives that
> come and go in different combinations. I still wish I could control
> that particular behavior.
>
> Thanks for the tip :)
>
> Best,
> Olle

You can.  As Adrian says you should be able to use a
ClientRunBeforeJob directive.  This will tell the client to run a
script which should be a shell script that checks for the presence of
a drive.  If it does not detect the drive, exit with exit code 1 and
the job will not run.  If it does detect the drive, exit with exit
code 0 and the backup job will run.  I missed the previous portion of
this thread, but I'm assuming this is a Linux client that is mounting
a drive.  If that's the case, then you're still functionally getting
an incremental but because the directory was empty last time (when the
drive was not mounted) but now has the entire drive's contents in it.
The incremental job is dutifully backing up all changed data from the
last incremental which happens to be all of the data on the drive now
that Bacula can see it.  Merely detecting the drive with a
ClientRunBeforeJob script will solve that problem entirely.

If you have many drives you interchange in this way, I would recommend
making your script take an argument so you only have to maintain a
single script that can check any drive you want as dictated by the
job.

If you do this I don't see why you would need 2 filesets and 2 jobs.
It should work just fine with one of each unless that is addressing
something I missed from previous emails.

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users