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