Re: [Bacula-users] Simplified pools
-Original Message- From: Phil Stracchino [mailto:ala...@metrocast.net] Sent: Tuesday, April 06, 2010 3:05 PM To: bacula-users@lists.sourceforge.net Subject: Re: [Bacula-users] Simplified pools On 04/06/10 17:28, Kevin Keane wrote: From: Phil Stracchino [mailto:ala...@metrocast.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: You know, I feel stupid. I immediately went to implement this mechanism - and then realized that I had actually done it already and forgotten about it! I had gotten confused by the run command in bconsole that still lists the default pool, instead of the one that would actually be used. At least that explains why I couldn't find a volume the other day where I thought I had forgotten to update the pool before running a manual backup. Thanks for that information! -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
On 04/07/10 00:42, Craig Ringer wrote:
Phil Stracchino wrote:
I can confirm that it still works in 5.x as well. I use this for disk
volumes:
Label Format =
FULL-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
(with alterations for Differential and Incremental pools, of course.)
If it's not going to be removed and replaced with something 10x as
complicated, perhaps it should be un-deprecated?
As far as I know, there are no plans at this time to actually remove
that functionality. I'm not really clear on why it was deprecated.
Oh well, I'll use it if it still works. It's not like I can't port the
config over to whatever is required later if it is ever dropped. Thanks
for the tip.
I'm troubled by the approach taken with Bacula of it's possible with
some scripting, so why should Bacula make it simple and easy to do this
common task. Then again, perhaps I'm just trying to do things the wrong
way and what I see as simple and common, like concurrent backups to a
sd, isn't.
Part of what's going on is that Bacula has explored several different
routes for scriptable automation so as to provide the maximum possible
flexibility, but so far each of them has been found to have drawbacks.
(The principal drawback in the case of Python being, in my admittedly
inexpert opinion, that Python is something of a niche language, much
less widely known and used than - for example - Perl. While I know
people who swear by Python, I also know plenty who swear *at* it, not
least for its use of whitespace to define lexical scope.) While
different solutions have been explored at different times, generally the
original basic functionality that may be limited but works has not been
removed unless it's actively broken or causing things to break. (I'm
actually surprised that schedule-based overrides have not been removed,
given the Pool problems already discussed.)
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org
Renaissance Man, Unix ronin, Perl hacker, Free Stater
It's not the years, it's the mileage.
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
On 04/07/10 00:54, Craig Ringer wrote:
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.
This is a good suggestion, I think. I'd go ahead and write it up and
submit it. :)
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org
Renaissance Man, Unix ronin, Perl hacker, Free Stater
It's not the years, it's the mileage.
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
On 7/04/2010 8:26 PM, Phil Stracchino wrote: Oh well, I'll use it if it still works. It's not like I can't port the config over to whatever is required later if it is ever dropped. Thanks for the tip. I'm troubled by the approach taken with Bacula of it's possible with some scripting, so why should Bacula make it simple and easy to do this common task. Then again, perhaps I'm just trying to do things the wrong way and what I see as simple and common, like concurrent backups to a sd, isn't. Part of what's going on is that Bacula has explored several different routes for scriptable automation so as to provide the maximum possible flexibility, but so far each of them has been found to have drawbacks. (The principal drawback in the case of Python being, in my admittedly inexpert opinion, that Python is something of a niche language, much less widely known and used than - for example - Perl. While I know people who swear by Python, I also know plenty who swear *at* it, not least for its use of whitespace to define lexical scope.) While I don't care the tiniest bit about the whitespace issue, I used to swear at Python very frequently because: - The dev team's answer to any embedding issues is you're doing it wrong. You should rewrite your whole application as a Python module and run it under the Python interpreter, not embed the Python interpreter in your app. You can imagine how appealing THAT idea is with, say, a large Qt-based C++ GUI application... - The Global Interpreter Lock (GIL). 'nuff said. I no longer maintain Scribus's embedded scripting support and my embedded Python headaches are gone, but I'd certainly never choose it again for any embedding project when I could pick Lua or a JavaScript library instead. ( OK, that's not strictly true, it's great if your app is single-threaded and always will be, not powered by an event loop, and you want scripting users to be able to do anything without any restriction or security policy. But that's kinda rare. ) While different solutions have been explored at different times, generally the original basic functionality that may be limited but works has not been removed unless it's actively broken or causing things to break. (I'm actually surprised that schedule-based overrides have not been removed, given the Pool problems already discussed.) I suspect there are other use cases not covered by the pool overrides. People may need schedule-based overrides that don't neatly correspond to job levels. IMHO before they could be removed there'd need to be a way to override anything, not just pool selection, by job level. Even then it's hard to say if people would need them for other things. I guess that's what on-startup deprecation warnings are for... -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
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:cr...@postnewspapers.com.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@lists.sourceforge.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
On Tue, Apr 06, 2010 at 02:36:38PM +0800, Craig Ringer wrote:
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:
You could use standard include (@) feature of bacula configuration
files, for example:
in /etc/bacula/pool-default-values.conf:
Storage = SystemStorage
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Use Duration = 1 day
Recycle Oldest Volume = yes
and in /etc/bacula/bacula-dir.conf:
Pool {
@/etc/bacula/pool-default-values.conf
Name = SystemFullPool
Volume Retention = 2 months
LabelFormat = SystemFull-
}
Pool {
@/etc/bacula/pool-default-values.conf
Name = SystemDiffPool
Volume Retention = 2 weeks
LabelFormat = SystemDiff-
}
Pool {
@/etc/bacula/pool-default-values.conf
Name = SystemIncrPool
Volume Retention = 1 week
LabelFormat = SystemIncr-
}
Much more readable and easier to maintain than original config:
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-
}
It is even more advanced than including single files, for example you
could use something like:
@|sh -c 'for f in /etc/bacula/clients.d/*.conf ; do echo @${f} ; done'
which would include all *.conf files in /etc/bacula/clients.d/
We use that to allow different admins to edit configurations only for
their clients...
Of course you can use any external command here; for example you
could call perl script using DBI which would generate all or part of
your config files from SQL database or for example from nagios
configuration files or whatever...
--
Matija Nalis
Odjel racunalno-informacijskih sustava i servisa
Hrvatska akademska i istrazivacka mreza - CARNet
Josipa Marohnica 5, 1 Zagreb
tel. +385 1 6661 616, fax. +385 1 6661 766
www.CARNet.hr
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
On 04/06/10 02:36, Craig Ringer wrote:
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.
Well, actually, no, it looks like a way of complicating pool definition,
not simplifying it. Because under this scheme, the pool syntax would
have to contain level-specific overrides for essentially every
adjustable parameter.
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org
Renaissance Man, Unix ronin, Perl hacker, Free Stater
It's not the years, it's the mileage.
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
On 04/06/10 06:00, Kevin Keane wrote: 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. Actually, this is a problem which has largely been fixed in Bacula-3 and later, by changing the way overrides work. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
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}
I thought variable-expansion in label formats were well and truly
deprecated in favour of the Python scripting support?
Officially, yes, I've been reading that it was deprecated, but it still works
in 3.0.3. And I hope it will continue to work. I'd HATE to have to learn Python
just to replace this simple little line. That would be painful (not that I mind
learning Python, but even as it is bacula requires more of my time and
attention than it should).
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
On 04/06/10 17:26, Kevin Keane wrote:
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}
I thought variable-expansion in label formats were well and truly
deprecated in favour of the Python scripting support?
Officially, yes, I've been reading that it was deprecated, but it
still works in 3.0.3. And I hope it will continue to work. I'd HATE
to have to learn Python just to replace this simple little line. That
would be painful (not that I mind learning Python, but even as it is
bacula requires more of my time and attention than it should).
I can confirm that it still works in 5.x as well. I use this for disk
volumes:
Label Format =
FULL-$Year${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}:${Minute:p/2/0/r}
(with alterations for Differential and Incremental pools, of course.)
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org
Renaissance Man, Unix ronin, Perl hacker, Free Stater
It's not the years, it's the mileage.
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
On 04/06/10 17:28, Kevin Keane wrote:
From: Phil Stracchino [mailto:ala...@metrocast.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.
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.
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org
Renaissance Man, Unix ronin, Perl hacker, Free Stater
It's not the years, it's the mileage.
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Simplified pools
Phil Stracchino wrote:
On 04/06/10 17:28, Kevin Keane wrote:
From: Phil Stracchino [mailto:ala...@metrocast.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
