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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
