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
>
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
