On Tuesday 29 November 2005 16:15, David Boyes wrote:
> > > 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 don't think there is any choice, since it is probably not advisable to move
just a piece of a job to another device. In addition, it would be really
hairy trying to update the JobMedia block pointers if you started moving
stuff in the middle of the job. It really needs to move a whole job at a
time.
A Volume migration (for me in the current Bacula context) is simply:
1. What jobs are stored on the Volume
2. Loop over jobs, doing a job migration.
>
> > > 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.
I'll mull this over. In any case, I'm more interesting in Migration at the
moment rather than Copy or Archive, so we have plenty of time to work out the
terminology.
>
> -- db
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
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_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
