> > I've had similar thoughts (though not to this extent until now) and would love > to see this, it would greatly simplify management and design of systems like > mine and some of the ones I have deployed for customers which have to use > offsite pools with differing retentions and do not want local backups based on > them, while still allowing the new features to work well like virtual fulls > and not requiring a lot of duplication which can lead to errors. > > Feature request time (Yes I realize this is a rather complicated one, and > would be a while off)? >
Well actually I don't think it would be that complicated. The changes required are: . Config file parsing - bacula does this very nicely so not much more than a few lines of code . Catalog schema changes - easy, but given the invasive nature of such things we'd need to be sure that it was done once and done right . Catalog queries - still pretty easy - just a few more where clauses to select only the volumes in the pools that we are interested in . UI changes - anywhere the user is prompted to configure a job, they'd also need to be able to configure the 'Source' parameter too. I have never looked at this side of Bacula but I suspect that Kern has made it pretty easy to extend Probably a bit more stuff too, and possibly I've missed something important. I think Kern is away on holiday still but I'm sure he'll have a few opinions on it when he gets back :) James ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
