Backup Central

I know this is likely a dumb question, but it was my understanding
that the storage daemon was independent of the SQL database, but I
have been unable to figure out a way to build additional storage
daemons on other machines without including a build of mySQL or
SQLite. Is there something I'm doing wrong? Does the Storage
Daemon require SQL? If I build the Storage Daemon using SQLite(since
it's easier to build that way), will it pose a problem that I'm
running mySQL for my actual catalog?

On Friday 16 March 2007 15:19, Richard Adams wrote:
I know this is likely a dumb question, but it was my understanding
that the storage daemon was independent of the SQL database, but I
have been unable to figure out a way to build additional storage
daemons on other machines without including a build of mySQL or
SQLite. Is there something I'm doing wrong? Does the Storage
Daemon require SQL? If I build the Storage Daemon using SQLite(since
it's easier to build that way), will it pose a problem that I'm
running mySQL for my actual catalog?


The SD does not "currently" need/use the DB (this will probably chang).
However, some of the other tools that are built with the SD do need the DB,
therefore the dependence. If you want ONLY the SD, for the current time, you
can build it with any DB and it will work.

Attachments: novosirj.vcf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kern Sibbald wrote:
The SD does not "currently" need/use the DB (this will probably chang).
However, some of the other tools that are built with the SD do need the DB,
therefore the dependence. If you want ONLY the SD, for the current time, you
can build it with any DB and it will work.

Out of curiosity, what -- down the line -- would the -sd require a
database for? Config info?

- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |novosirj < at > um... - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF/zuwmb+gadEcsb4RAjmMAKCpMfyOY7WzanE5VFWE7/LkORAj9ACeNVTk
s5smJGwV7RkSTpnHs9QtmDg=
=BvU1
-----END PGP SIGNATURE-----

Hi,

Ryan Novosielski wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kern Sibbald wrote:
The SD does not "currently" need/use the DB (this will probably chang).
However, some of the other tools that are built with the SD do need the DB,
therefore the dependence. If you want ONLY the SD, for the current time, you
can build it with any DB and it will work.

Out of curiosity, what -- down the line -- would the -sd require a
database for? Config info?


I personally guessed it was for the direct updating/storing of attributes -
currently these are 'routed' thru the director aren't they?

There are probably other reasons tho.

Cheers,

Troy Daniels.

On Tuesday 20 March 2007 02:41, Ryan Novosielski wrote:
Kern Sibbald wrote:
The SD does not "currently" need/use the DB (this will probably chang).
However, some of the other tools that are built with the SD do need the
DB,
therefore the dependence. If you want ONLY the SD, for the current time,
you
can build it with any DB and it will work.

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 ...

Attachments: Message as HTML

Out of curiosity, what -- down the line -- would the -sd require a
database for? Config info?
=20
Config info in the database -- never. Only people who have never done a =
bare=20
metal recovery would think of such an implementation .
=20
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?)

-- Jorj

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 ...

Attachments: Message as HTML

Can you explain what you mean by "one of the lite mechanisms"?

SQLite or SQLite3. I don't believe they have any remote access directly.

I see no need to have each Storage daemon have its own database.

The only reason I mention it is because of the non-remote-access
database methods.

-- Jorj

On Tuesday 20 March 2007 13:42, Jorj Bauer wrote:
Can you explain what you mean by "one of the lite mechanisms"?

SQLite or SQLite3.

OK, I understand.

I don't believe they have any remote access directly.

No, they are compiled in (or can run as a shared library).


I see no need to have each Storage daemon have its own database.

The only reason I mention it is because of the non-remote-access
database methods.

OK, in any case, it is up to the user to decide. We provide the basic
configuration possibilities -- you choose.