On Tuesday 20 March 2007 12:51, Jorj Bauer wrote: > > > Out of curiosity, what -- down the line -- would the -sd require a > > > database for? Config info? > > > > Config info in the database -- never. Only people who have never done a bare > > metal recovery would think of such an implementation :-). > > > > bscan built into the SD. However, I *might* do that through the Director ... > > I'd much rather see it done through the Director. Otherwise we'd have to > have remote access to the database, which (for us) would mean > SSL-encrypted MySQL, which would increase overhead on the already busy > database substantially. > > And how would remote access to one of the lite mechanisms work? (Or > would each storage node have its own database?)
Can you explain what you mean by "one of the lite mechanisms"? I see no need to have each Storage daemon have its own database. The current philosophy will continue to apply no matter what we implement -- that is it is principally the Director that uses (and writes) the database. I can see the need to integrate Volume scanning into the Bacula daemons rather than only through a separate program (bscan), but have not yet fully thought out the project nor begun it -- it is something for much later ... ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
