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" <[email protected]>
Sent by: "ADSM: Dist Stor Manager" <[email protected]>
To: [email protected]
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 used to determine the current
state of a journal.
If a valid journal is restarted backups will be non-journal based until the
journal is revalidated.
The following message is written to the Windows Application Eventlog
when a journal is restarted:
Journal database 'c:\tsmjournal\tsmH__.jdb' for fs 'H:'
has been deleted and reset to the invalid state.
Specific messages detailing the specific cause of the journal
restart are also rewritten to both the eventlog and the
journal errorlog (jbberror.log).
Reasons for restarting a valid journal are:
1. Error conditions in the journal daemon
- buffer overflow errors caused by excessive change activity
on the journal file system being monitored for changes
- journal database access errors (disk full errors, etc.)
2. Request by a backup client
Clients will issue a journal restart request when it is determined that
a journal file system lacks integrity for one of the following reasons:
- the server filespace no longer exists
- the server filespace was deleted after the last backup
- the node policy set was updated after the last backup
- the Last Backup Completed or Last Backup Started dates
aren't valid (not set).
II. Client and Journal Daemon Traceflags
Trace Settings for the Journal Daemon
Trace settings for the journal daemon are specified in the journal daemon
configuration file tsmjbbd.ini as follows:
[JournalSettings]
TraceFlags=all_jbb
;
; the following two settings allow tracefile segmentation
;
TraceMax=100
TraceSegMax=1
tracefile=tracefiles\trace.out
Journal Daemon specific trace settings
JBBCOMM - listening thread
JBBDAEMON - process manager
JBBFILEMON - file system monitor
JBBDBACCESS - database controller thread
JBBDBINFO - low level database access
JBBNPCOMM - named pipe communications
JBBSERVICE - windows platform specific service tracing
JBBVERBINFO - detailed verb information
ALL_JBB - aggregate traceflag, includes all of the above
Trace Settings for the B/A client specified in dsm.opt:
JOURNAL - journal based backup tracing
III. Running the journal daemon in the foreground
For diagnostic and testing purposes it is sometimes useful to run
the journal daemon in the foreground as opposed to running it as a
Windows service.
The journal daemon may be started from a Windows command prompt as
follows:
tsmjbbd.exe i
IV. Journal Database Viewing Utility
The Journal Database Viewing Utility provides the following
information:
- the current state of a journal
- the file system tracked by the journal
- the journal activation timestamp
- the journal validation timestamp
- maximum supported journal size
- node and server the journal is valid for
- the number of entries currently in the journal
This utility also allows searching, inserting, or deleting specific
entries in a journal database.
The syntax of this utility is :
dbviewb <fully qualified journal database basefile name>
dbviewb <fully qualified journal database basefile name> <i>
Example 1:
D:\tsm530c\debug\bin\winnt_unicode>dbviewb c:\tsmjournal\tsmh__.jdb
Tivoli Storage Manager
Journal Database Viewing Utility
Version 5, Release 3, Level 0.0.f
Last Update: Oct 11 2004
Querying Journal DB ...
Journal Database Information:
Database File c:\tsmjournal\tsmh__.jdb
Database File Disk Size 81 KB (83754 Bytes)
Journal File Syst em H:
Journal Activation Date Mon Oct 11 11:49:05 2004
Journal Validation Date Tue Oct 12 16:41:11 2004
Maximum Journal Size 8191 PB (9223372036854775807 Bytes)
Journal Type Change Journal
Journal State Valid
Valid for Server GSHLAGER2_SERVER1
Valid for Node GSHLAGER3
Number of DB Entries 22
D:\tsm530c\debug\bin\winnt_unicode>
Example 2:
D:\tsm530c\debug\bin\winnt_unicode>dbviewb c:\tsmjournal\tsmh__.jdb i
Tivoli Storage Manager
Journal Database Viewing Utility
Version 5, Release 3, Level 0.0.f
Last Update: Oct 11 2004
Querying Journal DB ...
Journal Database Information:
Database File c:\tsmjournal\tsmh__.jdb
Database File Disk Size 81 KB (83754 Bytes)
Journal File Syst em H:
Journal Activation Date Mon Oct 11 11:49:05 2004
Journal Validation Date Tue Oct 12 16:41:11 2004
Maximum Journal Size 8191 PB (9223372036854775807 Bytes)
Journal Type Change Journal
Journal State Valid
Valid for Server GSHLAGER2_SERVER1
Valid for Node GSHLAGER3
Number of DB Entries 22
Enter request on a single line, in the following format:
Req-Type [Entry-key]
Req-type may be one of the following:
Del Delete a row from the database. The fully-qualified
case sensitive file name is required.
Find Find the entry whose key is the argument
List Print all the entries to stdout. No arguments
are required.
Quit
Please enter your request: find H:\dbview.example\Dir3Depth1\F2.txt
Located Journal Database Record:
-----------------------------------------
Object Name : H:\dbview.example\Dir3Depth1\F2.txt
Action : Modify
Object Type : File
Inserted : Thu Oct 14 10:15:28 2004
Object Time : Thu Oct 14 14:15:28 2004
Hit Count : -2110169276
-----------------------------------------
Please enter your request: quit
=
