This log message (Journal reset at client's request) means that the backup client has requested the journal
daemon to reset (invalidate) a journal because it has determined that the journal "lacks integrity" for one of
several reasons.
I have written a section for the TSM 5.3 Client Problem Determination Guide which (among other things)
documents reasons why this may happen.
Hopefully the attached text file will help explain this and other common jbb problems and issues.
If this doesn't answer your questions please post to the forum again or email me directly.
Pete Tanenhaus, Tivoli Storage Manager Client Development
-- Forwarded by Pete Tanenhaus/San Jose/IBM on 01/22/2005 08:27 AM ---
Please respond to "ADSM: Dist Stor Manager"
Sent by: "ADSM: Dist Stor Manager"
To: ADSM-L@VM.MARIST.EDU
cc:
Subject: Client v5.3 and Journaling
Good Evening -
We have implemented journaling on our active/active MS cluster. We used
version 5.3 as this version was developed to support it. Our TSM server is
Solaris 8 running 5.2.4. This is a 4 node cluster with a total of 12 virtual
nodes spread across the 4 nodes.
However, sometimes the journal works and sometimes we receive the following
message in the beginning of a backup and then of course, it does the normal
incremental. We do see in the event viewer where the backup gets done, it
says it validated and marked the journal for that drive and that it will use
it on the next backup. However, when the next backup starts, sometimes we
receive the following and thus, the cycle starts again. However, on dates
like the 15th through the 19th, we were fine. The 14th was the same as the
below.
I do have an open ticket it, but I figured I would throw this out there to
see if anyone has any insight.
01/20/2005 20:29:11 jnlDbCntrl(): Restarting journal for fs 'T:' per client
request.
01/20/2005 21:00:18 jnlDbCntrl(): Restarting journal for fs 'V:' per client
request.
01/20/2005 22:30:11 jnlDbCntrl(): Restarting journal for fs 'Z:' per client
request.
01/21/2005 00:03:21 jnlDbCntrl(): Restarting journal for fs 'X:' per client
request.
01/21/2005 05:50:31 jnlDbCntrl(): Restarting journal for fs 'X:\MOUNTVOL11'
per client request.
01/21/2005 09:31:16 jnlDbCntrl(): Restarting journal for fs 'Z:\MOUNTVOL9'
per client request.
01/21/2005 18:11:53 jnlDbCntrl(): Restarting journal for fs 'T:' per client
request.
01/21/2005 18:11:57 jnlDbCntrl(): Restarting journal for fs 'X:' per client
request.
01/21/2005 18:11:59 jnlDbCntrl(): Restarting journal for fs 'Z:' per client
request.
01/21/2005 18:11:59 jnlDbCntrl(): Restarting journal for fs 'V:' per client
request.
Any help will be appreciated.
Thanks!
-- Terry
Journal Based Backup Problem Determination
I.Determining if a backup will be journal based
II. Client and Journal Daemon Traceflags
III. Running the journal daemon in the foreground
IV. Journal Database Viewing Utility
I. Determining if a backup will be journal based
The following conditions must be met in order for a backup to be
journal based:
- The journal daemon must be configured to journal the file system
being backed up.
- The journal for the file system being backed up must be in the
valid state.
- The TSM node and server the backup is using must match the node and server
which the journal is valid for.
The journal daemon is configured to journal a file system by adding the
file system to the list of journaled file system in the journal daemon
configuration file tsmjbbd.ini as follows:
[JournaledFileSystemSettings]
;
; List of journaled filesystems
;
JournaledFileSystems=c:
In order for a journal to be valid a full incremental backup must be
performed on the corresponding file system while the file system is
actively being journaled.
This full incremental backup must set the "Last Backup Completed" date on
the TSM server filespace in order for the journal to be set to valid.
The "Last Backup Completed" date may be viewed by issuing the "Query Filespace"
server command.
After the journal is set to the valid state, subsequent backups
by the same TSM node to the same TSM server will be journal based.
If a backup uses a different TSM node and/or server, the backup will be
non-journal
based but the journal will remain valid the original node and server,
and backups to the original node and server will be journal based.
The following message is written to the Windows Application Eventlog when a
journal
is initially set to valid:
Journal set to valid for fs 'H:' and will be used for
backup by node GSHLAGER3 to server GSHLAGER2_SERVER1.
The Journal Database Viewing Utility may also be us
