There may be some confusion as to when journal based backup will be used
and when full progressive incremental
will be reverted to.

The backup client determines if journal based backup is possible and if it
isn't will revert to full incremental backup.

For jbb to be possible, the journal service must be running, and an active
and valid journal must be present for the
file system being backed up.

Having the journal service running is pretty much self explanatory (for
testing purposes in may be run in undocumented, unsupported
foreground mode by issuing  tsmjbbd i   from a command prompt ...).

An active journal means that the file system  is specified in the list of
journaled file systems in journal service configuration file (tsmjbbd.ini)
and is actively being journaled (application event log messages should
verify this).

There are several factors which determine if  a journal is valid.

First and foremost is that a full, progressive incremental backup of the
filesystem must have been completed while the file system
was actively being journaled.

Note that completed means that the last Last Backup Completion Date on the
server is set, and this will only happen when the entire
file system is backed up (dsmc incr c: will do it, dsmc incr c:\*.*
-subdir=y will not).

The Last Backup Completion Date may be viewed by doing a Query FileSpace
from the backup client or server.

Once a full incremental backup of the actively journaled file system is
completed, the journal for that file system will
be valid for the server which the original full backup was performed and
completed to, and journal based backup will
be invoked on subsequent backup operations to that server.

Conditions which will invalidate the journal and force a full incremental
backup to be performed:

1. Stopping and restarting the journal service or bringing the file system
offline by removing from the list of journaled file systems in the config
file.

Normally stopping and restarting the journal service (or bringing it
offline) automatically invalidates the journal but this
behavior may be overridden (as of release 5.1 of the journal service) by
specifying the  PreserveDbOnExit setting under
JournaledFileSystemSettings stanza of the journal service config file
(PreserveDbOnExit=1).

If this setting is specified the journal will remain valid and jbb can
continue when the journal comes back online.


2. Certain changes in policy information on the server

Changing policy information on the server such as the default management
class, etc. will invalidate the journal.


3. Backup up to a different server than the original backup was completed
to will force a full incremental backup to the new
    server but will not invalidate the journal for the old server.

    The journal must be brought offline (with PreserveDbOnExit off) and
back online, and a full backup performed and completed to the
    new server in order for the journal to be valid for the new server.


Hope this helps answer your questions and gets you up and running with
Journal Based Backup.


Pete Tanenhaus
Tivoli Storage Solutions Software Development
email: tanenhau AT us.ibm DOT com
tieline: 320.8778, external: 607.754.4213

"Those who refuse to challenge authority are condemned to conform to it"

---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on
10/29/2002 09:38 AM ---------------------------

"Gill, Geoffrey L." <GEOFFREY.L.GILL AT SAIC DOT COM>@VM.MARIST.EDU> on 
10/29/2002
09:23:01 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:    "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:    ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:    Journaling



Why, after turning on Journaling, is TSM now going to back up the whole
600GB "AGAIN"!

Geoff Gill
TSM Administrator
NT Systems Support Engineer
SAIC
E-Mail:    <mailto:gillg AT saic DOT com> gillg AT saic DOT com
Phone:  (858) 826-4062
 Pager:   (877) 905-7154