Bacula-users

Re: [Bacula-users] Simplified pools

2010-04-07 00:58:43
Subject: Re: [Bacula-users] Simplified pools
From: Craig Ringer <craig AT postnewspapers.com DOT au>
To: Phil Stracchino <alaric AT metrocast DOT net>
Date: Wed, 07 Apr 2010 12:54:01 +0800
Phil Stracchino wrote:
> On 04/06/10 17:28, Kevin Keane wrote:
>>> From: Phil Stracchino [mailto:alaric AT metrocast DOT net]
>>>
>>> Actually, this is a problem which has largely been fixed in
>>> Bacula-3 and later, by changing the way overrides work.
>> Really? I see this problem in bacula 3.0.3 all the time. Maybe I need
>> to change something in my configuration to take advantage of this new
>> feature. How is it supposed to work?
> 
> The old Schedule-based overrides are still *supported* in 3.0.3, for
> backward compatibility, but are deprecated - precisely because of the
> problem you note - in favor of the following example syntax:
> 
> 
> Schedule {
>   Name = "Monthly Rotation"
>   Run = Full 1st mon at 03:30
>   Run = Differential 2nd-5th mon at 03:30
>   Run = Incremental tue-sun at 03:30
> }
> 
> JobDefs {
>   Name = Backup
>   Type = Backup
>   Level = Full
>   Pool = Full-Tape
>   Full Backup Pool = Full-Tape
>   Differential Backup Pool = Diff-Disk
>   Incremental Backup Pool = Incr-Disk
>   Schedule = "Monthly Rotation"
>   [...]
> }
> 
> 
> The change was made because, basically, it proved extremely difficult to
> avoid the pool mismatch problem using the schedule-based override code.

Yeah, that works ... when you only need to control pools based on job level.

My problem is that sometimes I need to control other job attibutes, such
as spooling, by job level.

The mechanism just needs to be generalised a little, so your above
example becomes:


JobDefs {
  Name = Backup
  Type = Backup
  Level = Full
  Full {
    Pool = Full-Tape
  }
  Differential {
    Pool = Diff-Disk
  }
  Incremental {
    Pool = Incr-Disk
  }
  Schedule = "Monthly Rotation"
  [...]
}

... or something like that, so other things may be overridden based on
level.

>  Putting pool overrides in the job definition allows the job to select
> its own pool, which means that in case of level promotion, it
> automatically just Does The Right Thing.

OK, good to know. I was actually using this mechamism before, but
thought it selected the pool *before* making the promotion decision. In
any case I had to switch to schedule-based overrides due to another
issue with retention periods and manual backups that I'll mention once
I've written it up properly.

--
Craig Ringer

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users