I think you have a valid beef. I don't believe it's mentioned in the documentation other than in the 'README.1st' file that's on the FTP site.
----- Original Message ----- From: "Malbrough, Demetrius" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 10, 2002 1:29 PM Subject: Re: ***The JOURNALED BACKUP saga continues...*** > Thanks, Andy & Pete!!!! I overlooked the fact that the server also had to be > at > 4.2.1 as well as the client for the Journal Based Backup to work! Where is > this documented?? I am at 4.1.2.0 on my AIX 4.3.3.0 server. > > Thanks, > > Demetrius > > -----Original Message----- > From: Pete Tanenhaus [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 10, 2002 2:19 PM > To: [EMAIL PROTECTED] > Subject: ***The JOURNALED BACKUP saga continues...*** > > > Answers/Comments to questions...... > > >>> I have read all of the information about Journal Backups in the "Tivoli > >>> Storage Manager for Windows Using the Backup-Archive Client" Manual and > also > >>> the "4.2.1 READMe for NT" and it seems that there is more information > needed > >>> on the behavior of Journal-Based Backups! > > Agreed. I am working on developing a redbook with guidelines for > understanding > and deploying Journal Based Backup. > > >>> I have an NT 4.0 client with TSM 4.2.1.15 (I will soon be upgrading to > >>> 4.1.2.20) client installed which it processes approximately 290,000 > objects > >>> with about 2,200 (less than 1%) changing on a daily basis. > > >>> If the amount of daily change activity is less than 5% is it still > >>> beneficial to use Journal Backups? > > This is an ideal environment for Journal Based Backup. > > The primary performance benefit over normal incremental backup is > eliminating > scanning the entire local file system. > > >>> When I first upgraded to 4.2.1.15 from 4.1.2.0, I decided not to > perform a > >>> Journal backup on this particular client, so I DISABLED the service. > On > >>> Tuesday, I started the Journal Service so it could begin its journaling > >>> process and log any changed objects or its attributes in the journal > >>> database. The backup still took 9.5 hours to complete with the same > >>> behavior as without Journaling. So, I continued to let it run the next > night > >>> and it still took 9.5 hours as well. > >>> > >>> It seems as if the Journal Engine Service is not working properly! I > still > >>> see sessions terminating due to the extensive processing/querying that > the > >>> producer thread does while in an idlewait status. > > Keep in mind that a normal full incremental must be done on a file system > being > journaled to create a valid journal before journal based backup will work. > > If the Journal Service is stopped all journals are deleted and obviously > will > no longer valid when the service is restarted so a full incremental must be > performed (and completed) before journal based backup will work again. > > The version 5.1 journal service has a setting to override this behavior, > that > is to allow a journal to remain valid when the file system goes offline or > the > service is stopped and restarted. > > > >>> It seems as if the Journal Engine Service is not working properly! I > still > >>> see sessions terminating due to the extensive processing/querying that > the > >>> producer thread does while in an idlewait status. > > I think what is happening is that a full incremental is being forced > because the > journal was deleted when you stopped the service. > > Note that you can override journal based backup when a valid journal exists > by using > the -nojournal option in the backup client.. > > >>> Also, if anyone can explain this message it would be greatly > appreciated? > >>> > >>> "psFsMonitorThread(tid 1044): Object 'C:\WINNT\Temp\TMP5.tmp' was > deleted > >>> after notification." > > This message is erroneous and shouldn't be logged as an error (this is > fixed in the version > 5.1 journal service). > > Basically what it means is that a change notification was generated for an > object which was > deleted before journal service could process the notification. > > I mistakenly thought this to be an unusual type of error condition but it > turns out to happen > quite frequently when applications create and delete temporary files in a > very short time span. > > > > Hope this answers your questions ..... > > Pete Tanenhaus > Tivoli Storage Solutions Software Development > email: [EMAIL PROTECTED] > 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 > 01/10/2002 03:03 PM --------------------------- > > "Malbrough, Demetrius" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 01/10/2002 > 12:22:13 PM > > Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > cc: > Subject: ***The JOURNALED BACKUP saga continues...*** > > > > ****Any *SMers using NT Journal Backups**** > > **This question is posed to Tivoli Client Development [Andy Raibeck] or > Tivoli Storage Solutions Software Development [Pete Tanenhaus] if > possible!!!!** > -------------------------------------------------------------------------- -- > > ----------------------------------------------- > > I have read all of the information about Journal Backups in the "Tivoli > Storage Manager for Windows Using the Backup-Archive Client" Manual and > also > the "4.2.1 READMe for NT" and it seems that there is more information > needed > on the behavior of Journal-Based Backups! > > I have an NT 4.0 client with TSM 4.2.1.15 (I will soon be upgrading to > 4.1.2.20) client installed which it processes approximately 290,000 objects > with about 2,200 (less than 1%) changing on a daily basis. > > If the amount of daily change activity is less than 5% is it still > beneficial to use Journal Backups? > > When I first upgraded to 4.2.1.15 from 4.1.2.0, I decided not to perform a > Journal backup on this particular client, so I DISABLED the service. On > Tuesday, I started the Journal Service so it could begin its journaling > process and log any changed objects or its attributes in the journal > database. The backup still took 9.5 hours to complete with the same > behavior as without Journaling. So, I continued to let it run the next > night > and it still took 9.5 hours as well. > > It seems as if the Journal Engine Service is not working properly! I still > see sessions terminating due to the extensive processing/querying that the > producer thread does while in an idlewait status. > > An excerpt from the dsmsched.log-----> > > 21:32:08 ANS1898I ***** Processed 73,500 files ***** > 21:33:00 ANS1898I ***** Processed 74,000 files ***** > 21:34:06 ANS1898I ***** Processed 74,500 files ***** > 21:35:24 ANS1898I ***** Processed 75,000 files ***** > 21:36:28 ANS1898I ***** Processed 75,500 files ***** > 21:37:33 ANS1898I ***** Processed 76,000 files ***** > 21:38:41 ANS1898I ***** Processed 76,500 files ***** > 21:39:48 ANS1898I ***** Processed 77,000 files ***** > 21:40:57 ANS1898I ***** Processed 77,500 files ***** > 21:42:21 ANS1898I ***** Processed 78,000 files ***** > 21:43:45 ANS1898I ***** Processed 78,500 files ***** > > *************STILL PROCESSING UNTIL******************** > > 23:51:44 ANS1898I ***** Processed 151,500 files ***** > 00:02:09 ANS1898I ***** Processed 155,000 files ***** > 00:02:10 ANS1898I ***** Processed 156,500 files ***** > 00:02:17 ANS1898I ***** Processed 157,000 files ***** > 00:11:39 ANS1898I ***** Processed 162,000 files ***** > 00:12:58 ANS1898I ***** Processed 163,000 files ***** > 00:14:06 ANS1898I ***** Processed 163,500 files ***** > 00:16:54 ANS1898I ***** Processed 165,000 files ***** > 00:19:23 ANS1898I ***** Processed 165,500 files ***** > 00:19:25 ANS1898I ***** Processed 166,500 files ***** > 00:20:05 ANS1898I ***** Processed 167,000 files ***** > 00:20:31 ANS1898I ***** Processed 167,500 files ***** > > Between 21:32:08 and 00:20:31 (almost 3 hrs) is when I see multiple > sessions > terminating due to the idlewait time of 60 mins. > > Should I increase the IDLEWAIT time to 180 mins. (3 hrs) or will that only > eliminate the multiple sessions timing out or increase the performance of > my > backup? > > Also, if anyone can explain this message it would be greatly appreciated? > > "psFsMonitorThread(tid 1044): Object 'C:\WINNT\Temp\TMP5.tmp' was deleted > after notification." > > Thanks, > > Demetrius Malbrough > UNIX/TSM Administrator