Bacula-users

Re: [Bacula-users] About retention, and pruning.

2011-05-05 09:51:43
Subject: Re: [Bacula-users] About retention, and pruning.
From: Graham Keeling <graham AT equiinet DOT com>
To: bacula-users AT lists.sourceforge DOT net
Date: Thu, 5 May 2011 14:48:29 +0100
On Thu, May 05, 2011 at 12:12:10AM -0400, Dan Langille wrote:
> On May 4, 2011, at 3:26 AM, Graham Keeling wrote:
> 
> > On Fri, Apr 29, 2011 at 11:11:24AM +0200, Hugo Letemplier wrote:
> > > I think that a new feature that add dependency between various job
> > > levels for the next versions of bacula could be cool.
> > > The idea is to allow pruning only for volume/jobs that aren't needed
> > > by other ones whatever are the retention time.
...
> > > What do you think about such a feature ?
> > 
> > A while ago, I made a patch that does it. Nobody seemed to want it though.
> > http://www.adsm.org/lists/html/Bacula-users/2011-01/msg00308.html
> 
> 
> Just because you didn't find anyone that wanted it does not make it a bad
> idea.
> 
> Ideas are sometimes difficult to comprehend.  I didn't follow the above in a
> 30 second scanning....
> 
> If you think it's a good idea. Pursue it.  Give examples.  Describe the
> issues, in brief, and then in general.  Build a case that others can
> comprehend with minimal effort.

Thank you for the pep talk. :)

But I think that I have explained very well, in plain terms here:
http://www.adsm.org/lists/html/Bacula-users/2011-01/msg00308.html
"Bacula doesn't prevent backups that other backups depend on from being
purged."

> If you think it's a good idea, something will come of it.  But nothing will
> come of it if you don't persist.

Bacula is clearly not built to think that one backup depends directly on
another one. For example, there is no database field that says 'this backup
depends on this other backup'. This would have been one of the first fields
that I would have designed into it. Instead, it heavily relies on timestamps
and sort of scoops up everything that has a timestamp that matches.

I think that this may be down to its main authors having a 'tape mentality'
that I don't fully understand, since I have never worked with tapes.

Therefore, although I think that it would be a very good idea for bacula to
not purge a backup that another backup depends upon, I do not expect that this
patch will be adopted. And I do not expect bacula to gain this ability anytime
soon, since the concept seems so alien to it.
Making bacula do my concept of the 'right thing' would require a very radical
redesign. And perhaps my 'right thing' is different to many other people's
'right thing'.

Making the patch (which I have now attached to this email) felt as if I was
subverting some basic assumptions that I did not fully understand.

Furthermore, the patch makes its own assumptions:
a) you are using one Job per Volume
b) you are not using Job / File retentions (ie, you have set them very high)
and instead rely purely on Volume retentions. 
c) you are using mysql (it might work fine on postgres, but I haven't tried)

So, the patch is provided here on an 'as is' basis. If anybody likes it, or
wants to do something with it, or persist with it to get it into bacula, then
they can. :)

A note on the patch:
The main part starts in src/dird/autoprune.c with the call to
db_volume_has_dependents().


Final note:
I have actually gone very far down the path of 'very radical redesign' - see
http://burp.grke.net/ if you are interested.

Attachment: dependency.patch
Description: Text Data

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
<Prev in Thread] Current Thread [Next in Thread>