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? 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? 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? Best regards, Kern PS: Important, the change to GPL v2 would apply to the manuals now in translation. Best regards, Kern _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
