Berend Dekens wrote:
> Perhaps I'm asking something stupid but is there a reason that bacula
> stores loads of info in a database (pretty much everything), except for
> its own configuration?
In short, simplicity.
The first half is keeping it simple to configure Bacula, both in terms of
writing the config files out and parsing them. The nice, simple flat text
files are easy to edit with any decent text editor out there, and Bacula has
some good utility routines that make it relatively easy to add support for new
options. If the config were to be moved into a database, editing the
configuration without a custom app written explicitly for editing the Bacula
configuration database would be much more difficult. Likewise, representing
and parsing the kind of hierarchical data with lots of different key/value
pairs is actually a pain in the rear by comparison.
The second half is when stuff blows up. In particular, think of the scenario
where for some reason, the catalog and all backups of it have been completely
blown away, and all you have is a brand new server and a box of tapes. In
such a scenario, it's entirely possible to rebuild the config files from
scratch, and then fill up the catalog data with bscan. This would again be
much more complex if you had to generate the configuration completely in the
database.
--
Frank Sweetser fs at wpi.edu | For every problem, there is a solution that
WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken
GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
