[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Remaining dual changer problems
On Wednesday 04 June 2008 20:11:22 Bob Hetzel wrote:
> Kern Sibbald wrote:
> > I am considering disabling the "Prefer Mounted Volumes = no" because it
> > is the feature that creates a tremendous amount of extra work in Bacula.
> > Rather than use that feature (which currently does not work or leads to
> > failures), I recommend that to simultaneously write multiple volumes use
> > multiple pools.
> It mostly seems to work for me with my two drive autochanger, although I
> think I've seen the race condition you posted about a couple of times in
> the last month.
> The pluses I see to keeping the prefer mounted volumes option...
> - The autochanger I use is quite inexpensive on the used market and
> expandable to 6 drives. (As are many others as soon as they go off
> warrantee). Not having to reconfigure lots of bacula clients (which
> would also cause it to re-run fulls) when I added a 2nd drive was great.
> I presume I wouldn't have to reconfigure clients/add a pool with most
> backup systems but I've not used any of the big ones personally. Within
> the next year I'll probably be expanding to 3 drives. It would also be
> nice not to have to change too much if I have a drive failure and need
> to temporarily run with fewer drives.
> - In theory, if there's a problem with one backup running way slow the
> queued backups should all be handled properly by other drives. Also, if
> a drive dies on a weekend the rest of the weekend's backups should still
> run albeit they'll take longer to complete.
> - Restores would also be more complicated since after the transition
> you'd have to figure out which pool was used in the more recent backup.
> Somebody will surely correct me if I'm wrong, but I believe most
> commercial backup software can properly deal with two or more drives
> operating out of the same pool, so eliminating this ability will
> eliminate one of the features bacula has which compares well to
> commercial software.
It has never been that I didn't want the feature, but more that if something
is badly broken, it probably benefits everyone to disable it until it can be
In any case, the question is moot at this point since I found a way to correct
the worst cases (and hopefully all cases) that caused jobs to fail, and so
for the moment, there is no need to remove the feature. It still has a number
of inefficient drive load/unloads, but most of those can be corrected in
Hopefully version 2.4.0, which I will release tomorrow will correct the
failures that you have been seeing.
Thanks for the comments ...
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.