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.
>
Since I am buried in emails, I am probably reading this out of context, and
will attempt to find the start of the thread a bit later today. So I
apologize in advance if I misunderstand your request.
Please note that when discussing this subject, it is important to distinguish
between multiple Devices within a given Storage daemon, and multiple Storage
daemons (different binary files). The director directives currently used can
easily lead to confusion of these two different concepts.
My first point is that at the current time, Bacula does not support multiple
storage daemons for a single Job. It will happily write jobs to different
storage daemons, but has no current way of doing a restore from multiple
storage daemons.
In fact, it was only in 2.2.x that we introduced the ability for the Director
to switch drives within a single Storage daemon during *restore*, and though
this code seems to work, I would hesitate to say that it is currently
officially supported. Note, once a jobs starts *writing* on a given drive,
the current Bacula cannot switch drives later (we have a design project to
fix this).
Now, if the problem you are reporting has to do with multiple or different
devices within a single Storage daemon, then it falls under the new 2.2.x
code, which should work.
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.
Best regards,
Kern
------------------------------------------------------------------------------
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-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
