[Bacula-devel] Notification: Database format change to be committed to the SVN

[Kern S. <ke...@si...>]

Hello,

This is to warn those of you who regularly update your version from the SVN 
that in the next few days (probably tonigh), we will be applying a patch to 
the source code in the development versions of the SVN that will change the 
format of the database.

If do not update your source code, this does not concern you.

If you run the nightly regression tests, in general, it will all be automatic 
and we will monitor any possible failures.

If you want to update the source code, you will need to know that as of 
version 2.5.40 you will need to upgrade any database you have.  It is a 
rather significant update and you should be careful to backup your old 
database.  The upgrade for those of you using 2.5.x must be done manually, 
but we will supply the scripts and the ReleaseNotes will describe what needs 
to be done.  Once upgraded you cannot easily go back to the prior Bacula 
version, unless you restore an old database.

Once we are sure the new code is stable, we will release a new beta version of 
2.5.x ...

This new database format is what will be used in version 3.0.

Best regards,

Kern

PS: Here is a preview of the Release Notes notification (not yet released)...


       Release Notes for Bacula 2.5.40

  Bacula code: Total files = 522 Total lines = 203,305 (*.h *.c *.in)

This Director and Storage daemon must be upgraded at the same time,
but they should be compatible with all 2.4.x File daemons, unless you
use some of the new features that affect the FD.  In other words, you should
not have to upgrade all your File daemons when you upgrade. There is
no database upgrade needed from version 2.4.x.  However, the next
BETA release will require a database upgrade.

================== Warning !!!!!! ==========================

New Catalog format in version 2.5.40
------------------------------------

This BETA release of Bacula uses a new catalog format. We provide a set of
scripts that permit to convert a 2.4.x (version 10) catalog to 2.5.x (version
11). If you are using already a 2.5 version, you need to drop the JobHistory
table before upgrading your catalog (if you are using the new "long term
statistics" module, you can upgrade this table the same way we do with 
the Job table, see upgrade_<database>_table script).

The upgrade operation will convert the FileId index field of the File table
from 32 bits to 64 bits.  This operation will take TIME and will *temporarily* 
DOUBLE THE SIZE of your catalog.Depending on your catalog backend, you
won't be able to run jobs during this period.  For example, a 3 million files
catalog will take 2 mins to upgrade on a normal machine.  Don't forget to
backup it before executing the script.


...