> Hello Blake, > > Before you spend a lot of time making patches, please read the Developers > guide, then be sure you have agreement in principle on the feature design. > That avoids disappointment on both sides (mine and yours). > > Here are a few points that are contrary to what you write: > > The Copy job is intended to be used for offsite backups, and in addition, > there are fields in the Media record that allow you to indicate that the > volume is not available as well as the Location table that can be used to > keep track of where the volumes are. The design is there even if at the > moment it is not a mature feature.
The issue with this is it requires there to be an original job that is not treated that way, which hamstrings the use unless I am missing something about the design of Copy jobs. AFAIK a copy job is just that, a copy, which is good when you need a copy, but only when you want a copy. I need an full backup offsite each week, but I certainly don't want to waste the space / time of a full backup on site each week, or have the smaller backup levels depend on a short lived full. > Most of the control for offsite storage is via external programs such as bweb. Again this hamstrings control away from Bacula native automation etc when it is unnecessary. James' idea of source pools accomplishes everything quite well, and is fairly elegant, without requiring external scripts to manage it, and the restores can be done natively quite easily as well, on the concept of pool, rather than job allowance. My only real remaining issue with that design was that I don't like having to use schedules as the overrides. I am beginning to get to the point where I would rather have the functional position of Job be changed to something like a backup set, and have jobs something that can be run against a backup set, so that configuration can be done in the individual job types rather than trying to overload a single job object for multiple uses. Still trying to shoot down that idea myself before I suggested it though, as it becomes somewhat of a config sprawl, and inheritance complicated. Right now I've accomplished what I needed by having the job name / file set get changed once the vfull is completed using an external script, though it would be nice if this was unnecessary. > > Version 3.0.1 and later do not require different pools for migration, > copy, > and virtual full jobs. It seems to work quite well, but since this is new > as > of 3.0.1, whether or not there are problems remains to be seen. > > Best regards, > > Kern > ------------------------------------------------------------------------------ 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
