Thanks for the comments. I've decided to use a single Job record, and I'm switching the manual license to GNU FDL.
On Thursday 01 June 2006 16:32, Erich Prinz wrote: > On May 27, 2006, at 3:31 AM, Kern Sibbald wrote: > > Hello, > > > > I've been running two Bacula issues over in my head for awhile now, > > and > > though I have worked out solutions, I thought I would should throw > > them > > out for your consideration and input: > > > > 1. To make migration (and later copy) work correctly, after a > > migration > > job has run (moved data from one pool to another), it is inserted > > in the > > catalog with the time and date of the original job. If I didn't do > > this, a > > restore would not be possible since the restore is based on job > > level and > > the time the job ran. > > > > However, to do automatic migration it is necessary to know when the > > job > > *really* ran so that it can be moved to another pool after a specified > > period, if the user configures this feature. So, additional > > information > > must be kept in the catalog. For the moment, this info is kept in a > > separate table. However, I am not very happy with this for performance > > reasons -- most all SQL commands will either need to be modified or > > have a > > second command that checks if this information is available. > > > > My solution (not yet implemented) is to eliminate the extra table > > and add > > the necessary data (several time values and possibly several integer > > values) to the Job table. Even though this information is only > > needed in > > migration and copy jobs, since there are not normally millions of > > Jobs, I > > prefer this to the additional complexity and the performance hit of a > > separate table. > > > > Comments? > > First a qualifier: I'm only a dabbler in database work - > > When the migration occurs, you're essentially making a copy of the > existing pool and labeling it for archival purposes. It seems to me > then, this data simply has additional characteristics. Clark Kent, > mild mannered news reporter --> Superman.. still the same guy, just > different costume and hair doo. So, why raise the complexity value by > adding a relational table when it's easier to create a new record > with added attributes? > > > 2. When doing a migration of a Volume Bacula must start one Job for > > each > > Job that is backed up on a Volume. Now, if you have 10,000 Jobs on a > > Volume, this could be a huge flood of jobs all started at the same > > time, > > which would be rather nasty and probably cause something to break. > > Obviously long term, we will need to find some solution to this (i.e. > > start one job that makes all the necessary Job entries in the catalog > > while copying all the data). Probably for the moment, I am just > > going to > > let Bacula fire off all the jobs and see what happens since there is > > really no good mechanism to wait (I could wait until the number of > > running/waiting jobs drops below a certain level before starting > > more jobs > > ...). For those of you who are using Tivoli or NetWorker, please > > remember > > that Bacula is job based, which means that each Job must be moved > > or at > > least the catalog entry of each Job must be properly updated. There > > is no > > other way of pulling data from a Volume (especially because Job > > data can > > spill over from a previous Volume or spill over to another Volume > > after > > the one being Migrated ...). > > > > Comments? > > You lost me at 10,000 Jobs. > > > 3. Currently the manual is licensed under a somewhat restrictive > > license > > that does not permit commercial reproduction of the manual without > > explicit authorization. This means that the manual does not mean the > > definition of Free Software. My idea in keeping the license > > commercially > > restricted was so that someone could possibly publish the manual > > (or use > > it as the basis of something to be published) and that a part of the > > revenues would revert to the project. > > > > However, I am now convinced that there is little chance that > > someone would > > want to publish the manual without working with us and that it is > > better > > to change the license to GPL version 2. There are, of course, all > > sorts > > of other open source licenses, but given that the source is GPL v2, > > this > > is the logical license for the manual as well. > > > > Comments? > > Another caveat: I know little about the licensing mechanisms. This is > hypothetical. > > If this can happen: Worst case scenario - someone publishes w/o > working with you and benefits financially leaving you and all the > developers high and dry. Are you and the rest of the community okay > with that happening? > > What would the fallout be? > > What risk is there to the project? > > Is there perhaps a benefit to the project? > > ---------------------------------------------------------------- > > Bacula is in my mind an excellent option to the commercially > available software on the market today. I plan to use Bacula in > future deployments for client sites as opposed to utilizing Veritas/ > Symantec or CA. The value/pricing proposition is quickly diminishing > with the improvements in Bacula and the bare metal recovery tools in > the open source community. > > Hope these musings will generate a little more commentary on your post. > > Erich > > > Best regards, Kern > > > > PS: Important, the change to GPL v2 would apply to the manuals now in > > translation. > > > > > > _______________________________________________ > > Bacula-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/bacula-devel -- Best regards, Kern ("> /\ V_V _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
