Hello Kern,

I'm very interest to implement this, as I told before, this is essential for
the backup plans that I'm implementing. I'm not so sure that I'll be capable
to finish thou.

My next steps will be:

1. Contact my local "open source community" to see if I have others
volunteers.
2. Make the initial code using the design you proposed.
3. Send to this list the patch for comments.

Any additional suggestions are welcome.

Thanks.

2011/8/29 Kern Sibbald <k...@sibbald.com>

>  Hello,
>
> I have long ago worked out the basic design of Job migration between
> different SDs,
> but I haven't written it down, because no one has volunteered to do the
> project, so
> I have been planning to do it myself (if I have to do it, it will be as a
> Bacula Enterprise
> feature obviously).  The design is basically:
>
> 1. Ensure Dir understands that two SDs are involved (possible need for
> additional directives).
>
> 2. Dir initiates connection with each of the SD's, one of which is the
> Reading SD  (rSD) and one of which is the Writing SD (wSD).
>
> 3. Dir transmits the coordinates of the wSD to the rSD as
> well as the necessary security token.
>
> 4. The rSD connects to the wSD as if it were a FD and uses
> the FD protocol (or possibly a simplified version) to transmit
> the data from the rSD to the wSD.  Note, the wSD doesn't
> need to know that the rSD is an SD -- it can simply think
> it is an FD.
>
> The rest of the backup proceeds as a normal back.
>
> Is there someone who is interested to implement the project?
>
> Best regards,
>
> Kern
>
>
> On 08/29/2011 09:57 AM, Radosław Korzeniewski wrote:
>
> Hello,
>
> My thoughts about it below:
>
> 2011/8/25 Allan Garcia <allan.gar...@gmail.com>
>
>> (...)
>>  MY INITIAL BRAINSTORM
>>
>>  1. the dird have to contact the origin *sd* and command the migration
>> (like it's done now)
>> 2. the origin *sd* detects if the destination *sd* it's himself or the
>> other *sd*
>>
>
> I think Director should communicate origin SD that destination is remote
> device on the other SD and supply required connection info.
>
>
>>  3. if the origin *sd* detects other destination, it respond informing
>> that to the dird
>>
>  4. the dird have to handle the origin *sd* response informing the
>> destination *sd*
>>
>
> If you change #2, that above steps won't be required.
>
>
>>  5. the dird commands the destination *sd* to wait the origin *sd*
>> connection
>> 6. the dird commands waits the destination *sd* to confirm
>> 7. the dird commands origin *sd* to send data to destination *sd*
>> 8. when it's done the job are marked as sucess, otherwise fail.
>>
>>  Waiting for any comments...
>>
>>
> You have to design a protocol used for SD to SD communication including
> TLS/SSL encryption layer.
>
> Best regards
>
> --
> Radosław Korzeniewski
> rados...@korzeniewski.net
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>
>
>
> _______________________________________________
> Bacula-devel mailing 
> listBacula-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bacula-devel
>
>
>


-- 
Allan Garcia
allan.gar...@gmail.com
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to