Le Thursday 15 October 2009 15:50:24 Ralf Gross, vous avez écrit :
> Graham Keeling schrieb:
> > On Fri, Oct 09, 2009 at 09:39:55PM +0200, Kern Sibbald wrote:
> > > On Wednesday 07 October 2009 11:02:23 Graham Keeling wrote:
> > > > Item  n: Run bscan on a remote storage daemon from within bconsole.
> > > >   Date:  07 October 2009
> > > >   Origin: Graham Keeling <gra...@equiinet.com>
> > > >   Status: Proposing
> > > >
> > > >   What:  The ability to be able to run bscan on a remote storage
> > > > daemon from within bconsole in order to populate your catalog.
> > > >
> > > >   Why:   Currently, it seems you have to:
> > > >          a) log in to a console on the remote machine
> > > >          b) figure out where the storage daemon config file is
> > > >          c) figure out the storage device from the config file
> > > >          d) figure out the catalog IP address
> > > >          e) figure out the catalog port
> > > >          f) open the port on the catalog firewall
> > > >          g) configure the catalog database to accept connections from
> > > > the remote host
> > > >          h) build a 'bscan' command from (b)-(e) above and run it
> > > >          It would be much nicer to be able to type something like
> > > > this into bconsole:
> > > >          *bscan storage=<storage> device=<device> volume=<volume>
> > > >          or something like:
> > > >          *bscan storage=<storage> all
> > > >          It seems to me that the scan could also do a better job than
> > > > the external bscan program currently does. It would possibly be able
> > > > to deduce some extra details, such as the catalog StorageId for the
> > > > volumes.
> > > >
> > > >   Notes:
> > >
> > > I have added this to the projects file, but with the following
> > > reservations:
> > >
> > >   Notes: (Kern). If you need to do a bscan, you have done something
> > > wrong, so this functionality should not need to be integrated into the
> > > the Storage daemon.  However, I am not opposed to someone implementing
> > > this feature providing that all the code is in a shared object (or dll)
> > > and does not add significantly to the size of the Storage daemon. In
> > > addition, the code should be written in a way such that the same source
> > > code is used in both the bscan program and the Storage daemon to avoid
> > > adding a lot of new code that must be maintained by the project.
> >
> > If bscan is available from bconsole, why would you ever want to run it as
> > a separate, more difficult to use, stand-alone program?
>
> You can use bscan as stand-alone program without installing and
> configure the sd. In a desaster recovery situation this might be
> helpfull.
>
> Ralf
>

For sure, to use bconsole, you need the director, the catalog, the storage 
daemon, a working network connection, etc...

Not so easy when everything go down.

Bye

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to