> 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. > [snip] > 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.
Seems reasonable to me. I expect migration to be much more prevalent once it's actually available, so doing it right seems to be a worthy goal. > 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 > ...). If that's the price to be paid to have working migration sooner, so be it. From what I've observed in my configuration, tape volumes tend to have relatively low numbers of jobs on them (lots of big dumps), so that probably won't cause bad things to happen for me, although once I can really take advantage of disk to tape migration, the disk volumes are the potential killers for this approach. Actually, it's probably good to find out if there are stress limits to the job initiator code. As things scale up, we'll need to know that anyway, and this will be one way to really exercise that code. The rate limiter is probably a worthwhile idea -- it would prevent a known way to shoot yourself in the foot, especially if migration takes the place of the current spooling code (which strikes me as a very good change in the default install). > 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. GPL it. Not worth the extra trouble. -- db _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
