On Tuesday 19 June 2007 15:31, [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/bacula-devel > ------------------------------------------------------------------------- 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-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
