Hello David,
On Monday 03 October 2005 21:20, David Boyes wrote:
> I scoped the problem as two major projects:
>
> 1) implementation of "copy pools" -- where files written to a pool were
> automatically also written to up to 3 additional pools using the same
> volume selection criteria as exist now (essentially getting the SD to act
> as a FD to more than one FDs to ensure synchronous updates, or creating a
> SD-mux function to split the FD data stream to N SDs).
In a certain sense this is already implemented in 1.37. 1.37 permits a job to
start a second job in a way that makes the second job duplicate the "since"
date/time. This effectively allows making identical copies (except for files
that change during the backup).
>
> 2) implementation of pool to pool migration as discussed on the list
> previously.
Pool to Pool, or direct writing by the SD to several devices within one Job
both require a few more changes to the SD. All the basic data structures
exist so that the SD can have multiple I/O packets open, but as of 1.37, the
SD only has a single I/O packet per job. In older versions of Bacula, there
were only DEVICE stuructures, one per physical device. Now, there are DCR
(device control records) that sit "above" the DEVICE structure. There can be
multiple DCRs that use the same DEVICE in 1.37 -- this is no problem.
However, the next generalization, and most of the code is in, is to allow a
job to have multiple DCRs. The job must be taught to open multiple devices
(and thus create multiple DCRs), and then either read from one DCR and write
to another (copy), and/or write to multiple DCRs.
>
> I think there is approximately 1-2 solid months of coding involved in each
> project -- neither are trivial to do. To get that coded is going to take a
> few contributions.
The only part of this implementation that I have not worked out in my head is
how to deal with the catalog. If there are two identical backups of a Job on
two different Volumes, the Director is not currently aware of it. There
needs to be some way of flagging two copies as being identical, then using
only one of those copies for any given restore. Also, there needs to be a
bit more work in implementing some better user interface for "archiving" i.e.
taking Volumes (possible identical copies) out of the Volume pool, and then
later re-introducing them.
By the end of the week, I will send an email that specifies how I believe we
should deal with the wishlist and projects for the next release. That will
permit us during November to come up with a list of project, give them a
priority, and hopefully find contributors ...
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
