On Fri, Mar 06, 2009 at 11:16:21AM +0100, Kern Sibbald wrote:
> On Wednesday 04 March 2009 18:31:06 Graham Keeling wrote:
> > On Thu, Feb 26, 2009 at 02:23:04PM +0000, Graham Keeling wrote:
> > > One kludgy solution that I may have a go at trying is to make the
> > > director write out a separate .bsr file containing the correct set of
> > > volumes that it needs for each Storage, and then doing multiple "run
> > > job=" commands. This will set off multiple restores and you'd end up with
> > > multiple confirmation messages.
> > > It might all go horribly wrong if you're using plugins, mind.
> >
> > After trying to make the above work and not liking it very much, I realised
> > that there might be a better way.
> >
> > The way that a restore job works is that the director...
> > a) opens a connection to the storage daemon
> > b) opens a connection to the file daemon
> > c) sends the storage daemon address to the file daemon and waits for a
> > response (file daemon contacts the storage daemon)
> > d) sends the bootstrap file to the file daemon
> > e) sends the restore commands to the file daemon
> >     (file daemon sends the bootstrap file to the storage daemon and starts
> >     receiving data)
> > f) waits for the file daemon to finish
> > g) waits for the storage daemon to finish
> >
> > I think it's possible to change the process so that the director and file
> > daemons open connections to a series of storage daemons during one job, and
> > the file daemon sends each storage daemon the relevant segment of .bsr
> > file.
> >
> > The director could insert 'Storage =' lines into the .bsr file and the file
> > daemon could parse the individual chunks out to the storage daemons.
> >
> > I may have a go at making it do this.
> 
> If you are really talking about restoring a single job from multiple 
> different 
> storage daemons, then it seems to me that we should start from a Feature 
> Request, and either in that request or as an additional document write a 
> detailed technical document on how we plan to do this -- only after that is 
> thouroughly reviewed should we begin working on coding -- you may not know 
> it, because a some of these design details are done off line (often in 
> kernstodo), but this is how we do all major development projects.
> 
> Certainly the ability to work (both backup and restore) with multiple storage 
> daemons within a single job could be a very useful feature, but let's define 
> clearly the need and then design the implementation.

Yes, I am really talking about a single restore job from multiple storage
deamons.


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to