On Tuesday 19 June 2007 15:31, mark.bergman < at > up... wrote:
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.
Yes, finally. I've been wanting to fix this for some time now.
=> 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?
Yes.
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)?
There are a number of ways to proceed:
1. Do exactly as you have suggested.
2. Upgrade the bacula-fd on all your production machines so something more
recent, while keeping the Dir and SD the same. It should work.
3. Keep your old production environment totally unchanged, and on your
production client machines, install a second copy of the FD in a different
location with different port numbers, different working directories, PID
directories (all directories different) ... and different conf files to talk
to the new Dir and SD.
4. A combination of item 1 (e.g Win32 machines) and item 3.
Item 3 is complete separation from your production system (providing you don't
make any installation/configuration errors). Item 1 is the simplest, but
then you are not testing the latest FDs.
I usually use ports 8101, 8102, and 8103 on regression testing, so I can run
regression tests on my servers with no interference.
Thanks,
Mark
=>
=> Best regards,
=>
=> Kern
=>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-devel mailing list
Bacula-devel < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-devel
