[Bacula-devel] [Fwd: Expanding the Job database table entry + manual license]

[Kern S. <ke...@si...>]

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