In the message dated: Tue, 19 Jun 2007 09:06:03 +0200,
The pithy ruminations from Kern Sibbald on
<[Bacula-users] SVN warning> were:
=> Hello,
=>
[SNIP!]
=>
=> The upside is that once I finish "tuning" the code, the SD should make much
=> more efficient re-use of drives than it previously did, and the proper
=> structures now exist to easily implement drive switching during a job.
=>
Very appealing.
=> Bottom line, I encourage as much testing as possible, because at this point,
=> that is what is needed, and I have thoroughly tested the code with lots of
=> regression testing, but be aware that the SD may be less stable than
=> previously (unfortunately the regression tests don't cover *everything*).
I've got a working, stable, production installation of bacula, which I cannot
break (too badly) in testing. However, I've also got access to a second
tape autochanger, attached to a different server than our production backup
machine. This will eventually become our new backup server.
In order to both configure our new bacula installation, and test new releases
of bacula, can I use a single instance of the bacula-fd (v. 1.38.11) on each
client, and the new bacula-sd and bacula-dir in parallel with the existing
production bacula-sd and bacula-dir? Will that be a meaningful test
environment for the new release, or will the version mis-match override any intrinsic
issues in the bacula-2.x code, rendering bug reports meaningless?
Aside from configuring the clients to accept connections from an alternative
bacula-dir, and ensuring that the schedules don't conflict, do you have any
suggestions for setting up this kind of environment (ie., each bacula-fd client
will connect with two different bacula-dir/bacula-sd servers)?
Thanks,
Mark
=>
=> Best regards,
=>
=> Kern
=>
