[Rear-users] Hi to the ReaR community

Schlomo Schapiro schlomo at schapiro.org
Wed Jan 25 09:03:57 CET 2012


On 25 January 2012 00:24, Dag Wieers <dag at wieers.com> wrote:

> On Tue, 24 Jan 2012, Schlomo Schapiro wrote:
> > On 24 January 2012 15:40, Jeroen Hoekx <jeroen.hoekx at hamok.be> wrote:
> >
> >> Rear
> >> did have PRE_RECOVERY_SCRIPT and POST_* on the other hand...
> >
> > I see no reason why not to have PRE_BACKUP_SCRIPT and POST_BACKUP_SCRIPT
> as
> > long as they are similarly implemented as the other PRE/POST scripts....
> >
> > Just submit a patch.
> The question here is what are the various requirements, not for just one
> use-case, but other use-cases as well. I can imagine that we do not just
> want the ability to load some commands before and after the backup, but we
> may want to run something before Rear starts one of the other workflows.
> That's why a hook-mechanism could eventually be as simple to configure,
> but fullfilling more complex scenarios for those people that need it.

I would like to go from single-need use cases to complex hook system by
need. As the needs grow we will learn what to do. (Agile and little

> And I know one could add a script somewhere in the workflow to basicly do
> anything one desires, but we're discussing here a mechanism to be used on
> a per-system basis, so something driven by /etc and not by
> /usr/share/rear and a (default) package, right ?

What prevents you from plugging extra scripts into ReaR on individual
hosts? ReaR is meant to be open and modular, so why not make use of this?

> My concern here is that if we introduce something now for the time being,
> we will have to maintain compatibility at a later stage, while if we think
> it through now, we may never need anything else, ever. (Wishful thinking
> on my part ;-))

I won't be afraid of imcompatible changes if they happen in a major
release, IMHO that is one reason to bump the major release number.

I think that if somebody needs pre/post backup scripts let them submit the
patch for it and then we see again.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pikachu.3ti.be/pipermail/rear-users/attachments/20120125/733ad097/attachment.html 

More information about the rear-users mailing list