<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Bacula Configuration</title>
	<atom:link href="http://dan.langille.org/2010/02/09/bacula-configuration/feed/" rel="self" type="application/rss+xml" />
	<link>http://dan.langille.org/2010/02/09/bacula-configuration/</link>
	<description>He has another more popular diary.  This one is more general.</description>
	<pubDate>Tue, 07 Feb 2012 23:24:38 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Steve</title>
		<link>http://dan.langille.org/2010/02/09/bacula-configuration/#comment-475</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Sat, 05 Feb 2011 15:39:58 +0000</pubDate>
		<guid isPermaLink="false">http://dan.langille.org/?p=262#comment-475</guid>
		<description>Well, one sentence with a few dashes and semi-colons, but agreed, a bit long.

For me, most large-scale systems are run from databases, for monitoring and most other backup systems, even lighter weight like BackupExec, and presumably Galaxy and Veritas.  In this case, all these main files are on the Bacula director, and still seems a tad absurd we can store all the results in a DB, but not the configuration/control.  Seems backwards, as many systems are the other way around; DB with complex configs but poor result management, logs, etc.

Regarding your example of local configs, yes, somewhat similar, but everyone works hard to avoid that, drive from templates, puppet, etc. and validate with databases if they can.  To purposely build a centralized system with no DB just strikes me as very challenging, very prone to error, hard to verify/crosscheck, update, etc.

But, that's the way it is - do you or anyone know of anyone who worked on generating these files from a master DB for central Bacula control, verification, etc. ?</description>
		<content:encoded><![CDATA[<p>Well, one sentence with a few dashes and semi-colons, but agreed, a bit long.</p>
<p>For me, most large-scale systems are run from databases, for monitoring and most other backup systems, even lighter weight like BackupExec, and presumably Galaxy and Veritas.  In this case, all these main files are on the Bacula director, and still seems a tad absurd we can store all the results in a DB, but not the configuration/control.  Seems backwards, as many systems are the other way around; DB with complex configs but poor result management, logs, etc.</p>
<p>Regarding your example of local configs, yes, somewhat similar, but everyone works hard to avoid that, drive from templates, puppet, etc. and validate with databases if they can.  To purposely build a centralized system with no DB just strikes me as very challenging, very prone to error, hard to verify/crosscheck, update, etc.</p>
<p>But, that&#8217;s the way it is - do you or anyone know of anyone who worked on generating these files from a master DB for central Bacula control, verification, etc. ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan</title>
		<link>http://dan.langille.org/2010/02/09/bacula-configuration/#comment-468</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Sat, 11 Dec 2010 13:27:32 +0000</pubDate>
		<guid isPermaLink="false">http://dan.langille.org/?p=262#comment-468</guid>
		<description>Wow!  Steve, did you notice that first paragraph of yours is all one sentence?  It took me a while to follow it.

The bacula text files are no different than other text files you have on the systems in question.  Anyone that has hundreds/thousands of systems already has this issue and presumably a way to deal with it.  Bacula is there for backups.  That is what it is designed for.

The issue of managing configuration files is best left to other solutions, such as, in your example, puppet.</description>
		<content:encoded><![CDATA[<p>Wow!  Steve, did you notice that first paragraph of yours is all one sentence?  It took me a while to follow it.</p>
<p>The bacula text files are no different than other text files you have on the systems in question.  Anyone that has hundreds/thousands of systems already has this issue and presumably a way to deal with it.  Bacula is there for backups.  That is what it is designed for.</p>
<p>The issue of managing configuration files is best left to other solutions, such as, in your example, puppet.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://dan.langille.org/2010/02/09/bacula-configuration/#comment-467</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Sat, 11 Dec 2010 10:39:04 +0000</pubDate>
		<guid isPermaLink="false">http://dan.langille.org/?p=262#comment-467</guid>
		<description>While I agree text files are very useful and easy to deal with in small systems, they do not scale or work well with larger, more dynamic systems - we are building a Bacula system for 250-1000+ hosts where we add/delete/change hosts, filesets, etc. daily, or even hourly using by staff globally - not having a DB-based system will eventually kill us, so we are looking at how to build it ourselves in 2011; given our size we have to standardize everything so the actual changes we allow are modest and templated so this should not be that hard to automate and cross-check, but would be nice as a real included toolset.  

In addition, given our rate of config change, we constantly have to validate the backups vs. the host configs, file locations (for example adding vhosts on servers and making sure their content gets backed up), so again having the config in a DB helps cross-check all that, validating against our monitoring and host config / provisioning systems, etc.  Text files spread across many servers makes this painful (1 director and backup, but eventually dozens of global storage directors).

Probably use a PHP front-end and the DB, then Puppet or related to spread config files in real time or at least hourly to all the systems.

Not to mention all the fun of PKI management for all this at large scale, both for TLS and data encryption.  Plus our automated recovery testing system that recovers each key host each month to a test system to validate accuracy and that we got consistent non-corrupt DBs, etc.  All globally, on 1000+ hosts.  Fun, fun.</description>
		<content:encoded><![CDATA[<p>While I agree text files are very useful and easy to deal with in small systems, they do not scale or work well with larger, more dynamic systems - we are building a Bacula system for 250-1000+ hosts where we add/delete/change hosts, filesets, etc. daily, or even hourly using by staff globally - not having a DB-based system will eventually kill us, so we are looking at how to build it ourselves in 2011; given our size we have to standardize everything so the actual changes we allow are modest and templated so this should not be that hard to automate and cross-check, but would be nice as a real included toolset.  </p>
<p>In addition, given our rate of config change, we constantly have to validate the backups vs. the host configs, file locations (for example adding vhosts on servers and making sure their content gets backed up), so again having the config in a DB helps cross-check all that, validating against our monitoring and host config / provisioning systems, etc.  Text files spread across many servers makes this painful (1 director and backup, but eventually dozens of global storage directors).</p>
<p>Probably use a PHP front-end and the DB, then Puppet or related to spread config files in real time or at least hourly to all the systems.</p>
<p>Not to mention all the fun of PKI management for all this at large scale, both for TLS and data encryption.  Plus our automated recovery testing system that recovers each key host each month to a test system to validate accuracy and that we got consistent non-corrupt DBs, etc.  All globally, on 1000+ hosts.  Fun, fun.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

