> > And these values apply to all volumes in the pool, right? > > Yes, which may encourage some users to create different Pools > for different Media Types.
Good. This is a productive direction..8-). > > Operationally, I think you'll be > > more concerned with the entire pool case, using the volume > occupancy > > information to select what volumes are eligible for migration. > > Well, Bacula is a bit brain-damaged, so for the moment, it is > not going to be able to use volume occupancy information to > select particular Volumes for migration. What I am talking > about for the moment is Job migration (see project #1 for > details). Now, if one arranges things right (Migration Time > for example), this might translate into Volume migration. OK. I can see how volume migration could be composed as a second-order process on top of job migration. Since you've given us a method to get to the internal representation of jobs in the Python interface, that will probably be the vector for experimenting with this. > If users want Volume migration, we could possibly come up > with such a project, but it is considerably more complex, and > not as useful, IMO, as Job migration (at least for a first > cut at migration) because Job migration implements 99.9% of > the code necessary for Copy, Archive, and Consolidation > (Virtual Full backups) at no extra cost. Fair enough. I was thinking specifically about the case of replacing the spooling code as the most obvious and immediate use of the volume migration component -- in that scenario, you want to empty whole volumes ASAP, so making that process efficient and fast (and quickly available) seems desirable. Let's see how it goes -- I suppose we could simulate the desired behavior with a Migration Time of zero for now. > For example, I could imagine that the current code would have > a Job Level of "Job" and what you want would be Job Level = "Volume". OK. As I discussed above, I can see volume-level migration as being decomposed into multiple job level moves. > > I think labeling it as a Backup job would be confusing. It's not > > really a backup; it's a migration job. > > Yes, except that I am planning to have the Migration job > function much like a backup. When anything is moved or > copied, a whole new set of database records need to be > written. I find it cleaner to attach them to the Migration > job, which just falls out of the code, rather than trying to > go back and delete part of the previous job data and patch > the new records in. > In fact, it would be *very* difficult to get it right. It's not the function or method I'm objecting to, it's the name -- maybe I didn't completely understand. No matter what it does internally, I think the Migration job should show up in user-visible space as a different type of job than a backup. Otherwise, I think you'll end up confusing people and making it harder to document. The fact that it does exactly the same thing internally as a backup is just for us programmer types...8-). > > > - An Archive feature can also be implement from this -- > it is simply > > > a Copy with no record being put in the catalog and the > output Volume > > > types being Archive rather than Backup. (Note, my concept of > > > Archive is that no record of them remains in the catalog > -- this may > > > be a subjet of discussion ...) > > > > I'd say that you absolutely *want* records of where you > archive stuff. > > You could add a COPY DATA command that would behave like > the MOVE DATA > > command I described above, and give it an option as to whether to > > record the copy in the database or not (default being yes). > There you > > probably want to allow either volume names or specifying individual > > job numbers to copy to the new volume. > > The Copy job will record detailed data locations and File > level information in the database. The Archive does not > record detailed data locations or File level information in > the database (except perhaps the Job record). Ah, so for cases like extracting all a user's data when he/she leaves a job. I think I'd call that a Extract rather than using the name Archive. To me, Archive implies that the data may need to be recalled some day and needs to stay under close management, for which you would need detailed records of file locations, and all the other goodies that go along with that. An Extract would be exactly that -- pull a copy of the data as is, no records expected, because the information is leaving the Bacula environment. Mechanically, I think the implementation would be very similar. For an Extract, I think you're correct in that you would probably only need the start/stop job records, and maybe a summary of the data pulled for auditing reasons. -- db ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
