Bacula-users

Re: [Bacula-users] Simplified pools

2010-04-06 06:01:35
Subject: Re: [Bacula-users] Simplified pools
From: Kevin Keane <subscription AT kkeane DOT com>
To: bacula-users <bacula-users AT lists.sourceforge DOT net>
Date: Tue, 6 Apr 2010 03:00:28 -0700
I second this idea. Maybe you could turn it into a feature request (see the Web 
site for instructions on how to do that).

Your idea would solve very nicely solve one really ugly problem: when manually 
running a backup job, the job may end up in the wrong pool - even if you 
actually remembered to select the correct one. For instance, let's say that the 
most recent Differential job failed. You decide to re-run the job manually. 
Bacula is smart enough to upgrade the job from Incremental to Differential 
automatically, but it is not smart enough to move the job from the Incremental 
to the Differential pool.

I would NOT recommend the AddLevelSuffix directive - that is too inflexible, as 
well as unnecessary. You can simply include ${Level} in your LabelFormat 
directive. Note that if you include a variable in the label format, Bacula will 
no longer automatically append the volume ID.

  LabelFormat="System${Level}-${NumVols}"

> -----Original Message-----
> From: Craig Ringer [mailto:craig AT postnewspapers.com DOT au]
> Sent: Monday, April 05, 2010 11:37 PM
> To: bacula-users
> Subject: [Bacula-users] Simplified pools
> 
> Hi
> 
> I'm sure many people using disk-based storage find that, like me, they
> have three pools defined for almost every job or at least class of job,
> like this:
> 
> Pool {
>   Name = "SystemFullPool"
>   Storage = "SystemStorage"
>   Pool Type = Backup
>   Recycle = yes
>   AutoPrune = yes
>   Volume Retention = 2 months
>   Volume Use Duration = 1 day
>   Recycle Oldest Volume = yes
>   LabelFormat = "SystemFull-"
> }
> Pool {
>   Name = "SystemDiffPool"
>   Storage = "SystemStorage"
>   Pool Type = Backup
>   Recycle = yes
>   AutoPrune = yes
>   Volume Retention = 2 weeks
>   Volume Use Duration = 1 day
>   Recycle Oldest Volume = yes
>   LabelFormat = "SystemDiff-"
> }
> Pool {
>   Name = "SystemIncrPool"
>   Storage = "SystemStorage"
>   Pool Type = Backup
>   Recycle = yes
>   AutoPrune = yes
>   Volume Retention = 1 week
>   Volume Use Duration = 1 day
>   Recycle Oldest Volume = yes
>   LabelFormat = "SystemIncr-"
> }
> 
> 
> where they're all pretty repetitive except for the retention periods
> and
> volume names. I'm wondering if it'd be worth thinking about extending
> the director's pool config with a shorthand to allow easier
> configuration of full/diff/incr pool sets. Here, the Incremental{},
> Differential{} and Full{} sections inherit the defaults defined by
> their
> container, so you only have to define the overrides for different job
> levels.
> 
> Pool {
>   Name = "SystemPool"
>   Storage = "File_System"
>   Pool Type = Backup
>   Recycle = yes
>   AutoPrune = yes
>   Volume Use Duration = 1 day
>   Recycle Oldest Volume = yes
>   AddLevelSuffix = yes             # NEW DIRECTIVE
>   LabelFormat = "System-"
>   Incremental {
>     Volume Retention = 1 week
>   }
>   Differential {
>     Volume Retention = 2 weeks
>   }
>   Full {
>     Volume Retention = 2 months
>   }
> }
> 
> 
> Does this look like a reasonable way to simplify configuration of
> retention periods for jobs? It'd basically be a configuraton that
> logically expanded into three pools with mostly-common config.
> 
> 
> This would be particularly useful if jobs could be pointed at
> "SystemPool" for their pool, and would auto-select the pool to use
> based
> on job level by adding a name suffix. In particular, if the job was
> promoted due to an earlier failed job it'd pick the right pool for its
> new post-promotion level, so a job that started off as incremental and
> was promoted to full would use SystemPoolFull instead of
> SystemPoolIncremental.
> 
> --
> 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

------------------------------------------------------------------------------
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