> 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:tanenhau AT US.IBM DOT COM]
> Sent: Thursday, January 10, 2002 2:19 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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: 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
> 01/10/2002 03:03 PM ---------------------------
>
> "Malbrough, Demetrius" <DMalbrough AT TTIINC DOT COM>@VM.MARIST.EDU> on
01/10/2002
> 12:22:13 PM
>
> 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: ***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
|
