Hi,

well, as Andrew asked for my advice specifically ;-)

Andrew Paterson wrote:

Hi Danie,
        I'm upgrading bacula on Solaris so no RPM's.
I install the source (from the tar file) do a ./configure etc to build it.

Actually, that's the way I do things as well... although I could use rpms, I still prefer controlling an upgrade of such an important software manually.


Of course, I don't care for package dependencies etc. because the bacula server here does nothing else, so it's unlikely I break things and even if I did reinstalling it would be done easily... after all, I do have backups - and the catalog on another server.

But that's another story!

I probably can't help you much because I'm trying to be VERY careful since
I'm trying to upgrade a live network set-up.

Quite understandable.

Anyway what I am doing in *fanatically* simple steps is:

Still, especially considering you want to keep things simple: (I cut some of your steps!)

3. Install the new version of bacula (in my case via make install)
you would I presume install from rpms.

Well, I tend to cp only the files I actually need, but admittedly, I tend to forget the tools like bls et al. :-)


Anyway, by doing things manually I avoid accidentially overwriting stuff I modified - happend with mtx-changer.

I sincerely hope that the rpm would leave your existing catalog alone (a pretty good assumption).

I does, to my knowledge.

4. rename the new /etc/bacula to /etc/bacula_1.36.3 d.o. for the new binaries 
in /sbin
(e.g. bacula-fd becomes bacula-fd_1.36.3)

5. Tediously making symbolic links to the current bacula in order for my 
existing setup
to continue working:
ln -s /etc/bacula_1.34.6 /etc/bacula
cd /sbin
ln -s bacula-dir bacula-dir_1.34.6
...
ad nauseum.

You mentioned the copying of the configuration files.
And yes, you can simply copy them, a valid 1.36 configuration file should work on all subversions.


I use unmodified configuration files since 1.34.6... and even if they don't work, you find out at the first startup.

Now, we have two parallel bacula configs - if you want to finish this bit write 
a little
script to remove the existing symlinks and make new ones pointing at either
1.34.6 or 1.36.3 so that you can switch neatly & quickly.

Another way to be able to revert easily would be to install bacula into it's own directory per version, like /usr/local/bacula/1.36.3/ and subdirs.


Or tar everything of a bacula installation and put the archive to CD-R... once you've got the list of files to store and the command to put them on CD in a script it's easy enough... and restoring would be something as simple as 'tar xPf /mnt/cdrom/bacula'.

6. I then at some point stop bacula (/etc/init.d/bacula stop) on all affected systems.

This should only be necessary when baculas protocols change - to my knowledge, this can be expected at 1.38 (to be released when Kern thinks its ready) or some of the 1.37 versions.


There is some added functionality in 1.36 above 1.34, but still the daemons can communicate, and they work correctly, but stuff like a monitor console doesn't work. So, you should not lose functionality.

In other words: You can deploy an upgrade one computer at a time and don't have to do them all at once.

On the server....
7. do a database dump :

Always useful, but your last catalog backup should be enough :-)

8. Upgrade the database schema:

This should not be necessary, as the database schema is unchanged. Of course, I may be wrong here, so you should read the release notes - in them, you will find the database changes.


I guess I'm now committed (no going back) :(

No. You still have your catalog backup, even *if* a schema change happened.

V----------------Can someone confirm that I need to do this--------------V
9. reload the database:

No, that should not be necessary, and in fact might revert your database to the old version or do nothing at all.


^----------------Can someone confirm that I need to do that--------------^

11. say a prayer!

I never found this necessary, but I'm not a religios person.

12. fire up bacula - /etc/init.d/bacula start
check that everything is running. particularly on the server.

Good idea - and don't forget to restart the client's FDs and possible remote SDs - use the status command to see their version information.


14. Don't blame me :) - this is a case of the blind leading the blind!

Sure... nobody wants to be the one to blame...

I believe that to undo the upgrade I need to:
o stop bacula
o remake my symlinks to point at 1.34.6
o DELETE the database
... not between 1.64.x versions.
There is, by the way, a special table called "Version" in the catalog... so, it is possible to find out if a catalog upgrade is necessary, and the director can avoid damaging a catalog of the wrong version.


o recreate the database using the 1.34.6 creation script.
... see above.
o reload the database dump
o restart (the old) bacula

Right, basically.

I assume no responsibility whatsoever for anything in this (dumb) procedure,
If I've missed something please let me know.

Not really... in fact, I think you made things more complicated than necessary.


Arno, have you got any advice here?

Was that enough? ;-)

Arno

Just my 10cents

Andrew R Paterson
Systems Engineer
DS Ltd




-----Original Message-----
From: Danie Theron [mailto:[EMAIL PROTECTED]
Sent: 17 May 2005 10:02AM
To: Andrew Paterson
Cc: Bacula-Users (E-mail)
Subject: Re: [Bacula-users] Upgrading from 1.34.6 to 1.36.3



Andrew Paterson wrote:


Hi,
        I am considering upgrading from 1.34.6 to 1.36.3 and am (double!) 
checking the required DB updates.
It appears that the Database schema follows its own versioning independent of 
the bacula source code
(seems sensible).
I conclude that I am running a Version 7 database schema (select * from 
Version;).
Bacula 1.36.3 requires me to upgrade to a Version 8 database schema.

What I am a little uncertain about is as follows:

There are two scripts for upgrading the schema from V7 to V8:
updatedb/update_mysql_tables_7_to_8
and
src/cats/update_mysql_tables

These scripts are similar, except that the one in src/cats has been "built" by 
configure and points to where my DB utils
(mysql-4.0.21) reside and will therefore execute successfully - I would need to 
fix paths in the updatedb script.

In addition, the src/cats script does not verify that the current DB version is 
V7 before continuing whereas the updatedb script does (i.e. the src/cats 
version just assumes this to be the case - rerunning it would I assume just 
result in a load of harmless sql errors).

Most significantly, the src/cats script creates a new table (CDImages) whereas 
the updateeb script does not.

I conclude that for my upgrade (1.34.6->1.36.3) (Mysql database V7->V8) I only 
need to run the src/cats/update_mysql_tables script. The script in updatedb being 
redundant in this case.

Can some kind soul who has been through this upgrade already verify this for me?

Andrew R Paterson
Systems Engineer
DS Ltd






Hi Andrew ,

I have also posted questions about upgrading to 1.36.3 , no answers yet. Did you install bacula from the rpms (which I did) or from the .tar package?

I would really like to upgrade (having some restore issues with my current version 1.36.2) , and I DON'T want to muck up my current installation. Could you possibly (if you already have) explain to me how you went about upgrading.

Thanks in advance!

D


------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users

-- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de


------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to