Kevin Keane wrote:
> Hi,
> 
> First of all - I agree that the volume handling on disks is one of bacula's 
> two weakest points. Whether a dedicated disk-based SD would actually solve 
> anything is an open question in my mind, though, because most of the problems 
> come from the overall architecture, and that's largely baked into the 
> director.

While true, I suspect some workarounds are possible by giving the
director the extra clue "this is a disk-based volume" and "this sd is
backed by disk storage".

I'd like to stress at this point that Bacula has been a really excellent
tool, albeit one that's taken a lot of fiddling with to get to behave
well for my needs. I'm just looking at ideas for ways to make it a
really excellent, _fuss_ _free_, _easily_ _configured_ and  _friendly_
tool for disk-based backups.

> That said, it seems to me that you are making the problem more complicated 
> than necessary. I am using a single device on my SD.

That's not viable if your backup window is too short to allow all your
jobs to run serially. In my case I have several jobs that take four+
hours by themselves, and must not block other jobs. Concurrent access to
the sd is necessary to make bacula useful in my environment.

Some jobs are also just big to be realistic to spool. A full backup of
the ad archives is 400GB, for example. Concurrent writes are really
necessary to stop this multi-day job from knocking the rest of the
system flat.

> The key is to only allow one job per volume

... which I do, or in some cases set max volume use duration so that all
of a day's incrementals for a particular class of job go in one volume,
as they'll all expire at the same time anyway.

> and/or to limit the size of volumes. Add automatic labeling and
> auto-recycling and you are done. Pool settings should control when
> volumes expire. It's all documented reasonably well.

Of course - and I already do this. If I didn't, I'd have absolutely no
hope of keeping my backups under control.

The trouble is that different classes of job - and their corresponding
volumes - need *different* expiration periods.

I have:

$ grep ^Pool /etc/bacula/bacula-dir.conf  | wc -l
20

... pools currently configured to manage different retention periods and
to try to track storage use by class of backup.


BTW, in addition to concurrency another reason to use multiple devices
is if you want to protect one type of job from a volume-full issue
caused by another job filling up a volume, by putting it on a separate
logical volume mounted on a separate directory. That's a good enough
reason to actually declare a new Device, though.

I guess if disk-based Devices could be opened multiple times with
different volumes, there'd be no real need for the sd to auto-define
devices on demand.

> There are still a few things that don't work well with bacula. Concurrency is 
> one

It works, it's just unnecessarily painful to get working for disk storage.

> it should really be possible to open more than one file-based volume at the 
> same time.

On the same SD device? Yep, that's what I was suggesting would really,
really help.

> Also, if you need redundant and repetitive configurations, look at using a 
> script. Bacula-dir allows you to include not just regular files, but also the 
> output from a script.

While that's possible, sure, it's also really feckin' ugly. Common use
cases shouldn't (IMO) require scripting where the config system could
handle it with some extension.

The scripting capabilities are great for corner cases  and oddities
where the canned system will never be flexible enough. But is this such
a case, or is it actually a pretty basic configuration? I'd say the
latter, personally.

--
Craig Ringer

------------------------------------------------------------------------------
Download Intel® 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