Re: ***The JOURNALED BACKUP saga continues...***
>>> This is a definitely a client-centric view! From my server-centric view >>> I think the primary benefit is the elimination of the server processing to >>> generate and download the whole activeset metadata. To some extent this is true but the point I was trying to make was that building the local list of objects by scanning the entire local filesystem has proven to be a much bigger performance bottleneck than building the list of server objects. This is especially true with very large filesystems because the scan processing becomes progressively slower (maybe not quite exponential) with larger (number of objects) and more complex (deeply nested dir structure) filesystems. The basic difference between traditional incremental backup and journal based backup is that traditional incremental must build three lists of objects: a local list obtained by scanning the local filesystem, a server list of active objects obtained over the network, and a candidate list of objects to be updated, backed up, or expired which is derived by comparing the local and server lists. Journal Based Backup obtains objects to backup or expire (update currently isn't supported) by querying a local change journal database which is maintained by real-time monitoring of filesystem change activity. Journal Based Backup eliminates scanning the local filesystem, querying the server, comparing local and server objects, and is much less memory intensive (not only are the local and server lists eliminated, but the candidate list is as well because journal entries are processed individually, i.e the entire journal doesn't have to be stored in memory). The disadvantage of Jbb is that it is not as comprehensive as traditional incremental in that in can not enforce nor detect changes in many policy attributes such as copy frequency, binding to a different management class, etc. So you can draw your own conclusions as to what types of environments it is beneficial in ... 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/11/2002 11:38 AM --- Bill Colwell <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 01/10/2002 03:47:55 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: ***The JOURNALED BACKUP saga continues...*** In <[EMAIL PROTECTED]>, on 01/10/02 at 03:47 PM, Pete Tanenhaus <[EMAIL PROTECTED]> said: >Answers/Comments to questions.. >The primary performance benefit over normal incremental backup is >eliminating >scanning the entire local file system. This is a definitely a client-centric view! From my server-centric view I think the primary benefit is the elimiation of the server processing to generate and download the whole activeset metadata. I am planning to roll out 4.2.1.15 clients on new xp machines, implementing both journalling and subfile backups at the same time, and to upgrade 500+ win2k machines to this level. These are all desktop machines, not the kind of machines so far described as the ideal candidates for journalling, but I am focusing on the server savings. (My server is tsm 4.2.1.7 on os/390 2.10). -- -- Bill Colwell C. S. Draper Lab Cambridge, Ma. [EMAIL PROTECTED] --
Re: ***The JOURNALED BACKUP saga continues...***
Answers and comments to questions . >>> When will ver 5.1 Journal Sevice be out? Tentative GA for 5.1 client is beginning of second quarter of this year. There is a formal beta program, if you are interested contact me offline and I will provide you with details. >>> Does it require ver 5.1 of TSM Server as well or does it work with 4.2.1? I don't believe so. >>> How do I disable logging to jbberror.log? On some servers it gets very big Unfortunately you can't but as previously stated the erroneous message logging to the jbb and ntevent logs should be fixed in version 5.1. Hope this helps 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/11/2002 11:29 AM --- Niklas Lundstrom <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 01/11/2002 03:57:09 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by:"ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] cc: Subject:Re: ***The JOURNALED BACKUP saga continues...*** Hello Pete When will ver 5.1 Journal Sevice be out? Does it require ver 5.1 of TSM Server as well or does it work with 4.2.1? How do I disable logging to jbberror.log? On some servers it gets very big Regards Niklas Lundström Föreningssparbanken IT -Original Message- From: Pete Tanenhaus [mailto:[EMAIL PROTECTED]] Sent: den 10 januari 2002 21:19 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 dele
Re: ***The JOURNALED BACKUP saga continues...***
Hello Pete When will ver 5.1 Journal Sevice be out? Does it require ver 5.1 of TSM Server as well or does it work with 4.2.1? How do I disable logging to jbberror.log? On some servers it gets very big Regards Niklas Lundström Föreningssparbanken IT -Original Message- From: Pete Tanenhaus [mailto:[EMAIL PROTECTED]] Sent: den 10 januari 2002 21:19 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
Re: ***The JOURNALED BACKUP saga continues...***
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
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 possibl
Re: ***The JOURNALED BACKUP saga continues...***
In <[EMAIL PROTECTED]>, on 01/10/02 at 03:47 PM, Pete Tanenhaus <[EMAIL PROTECTED]> said: >Answers/Comments to questions.. >The primary performance benefit over normal incremental backup is >eliminating >scanning the entire local file system. This is a definitely a client-centric view! From my server-centric view I think the primary benefit is the elimiation of the server processing to generate and download the whole activeset metadata. I am planning to roll out 4.2.1.15 clients on new xp machines, implementing both journalling and subfile backups at the same time, and to upgrade 500+ win2k machines to this level. These are all desktop machines, not the kind of machines so far described as the ideal candidates for journalling, but I am focusing on the server savings. (My server is tsm 4.2.1.7 on os/390 2.10). -- -- Bill Colwell C. S. Draper Lab Cambridge, Ma. [EMAIL PROTECTED] --
***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.
Re: ***The JOURNALED BACKUP saga continues...***
Minor point: Pete and I both work in the same group; it is just our sig
information that differs. :-)
It would help to know which TSM server version you are using, and what
your tsmjbbd.ini file looks like. Note that journal-based backups require
a 4.2.0 (or higher) TSM server as well, so if you are running at 4.1 or
less, then that explains why the journal backups aren't working.
About the IDLETIMEOUT question: if it is simply the producer session
timing out, I wouldn't bother increasing IDLETIMEOUT. If it is idle for an
hour at a time, then whatever time is taken to re-establish the session is
neglible. Note that IDLETIMEOUT messages are not necessarily indicative of
problems, and this sounds like just such a case.
Where are you seeing the "psFsMonitorThread" message? As far as I know,
this should only appear if you have tracing enabled. Trace messages are
intended for use by IBM service and development, so they are not
documented.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"Malbrough, Demetrius" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
01/10/2002 10:22
Please respond to "ADSM: Dist Stor Manager"
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 * Processed73,500 files *
21:33:00 ANS1898I * Processed74,000 files *
21:34:06 ANS1898I * Processed74,500 files *
21:35:24 ANS1898I * Processed75,000 files *
21:36:28 ANS1898I * Processed75,500 files *
21:37:33 ANS1898I * Processed76,000 files *
21:38:41 ANS1898I * Processed76,500 files *
21:39:48 ANS1898I * Processed77,000 files *
21:40:57 ANS1898I * Processed77,500 files *
21:42:21 ANS1898I * Processed78,000 files *
21:43:45 ANS1898I * Processed78,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?
"psFsMonitorTh
***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 * Processed73,500 files * 21:33:00 ANS1898I * Processed74,000 files * 21:34:06 ANS1898I * Processed74,500 files * 21:35:24 ANS1898I * Processed75,000 files * 21:36:28 ANS1898I * Processed75,500 files * 21:37:33 ANS1898I * Processed76,000 files * 21:38:41 ANS1898I * Processed76,500 files * 21:39:48 ANS1898I * Processed77,000 files * 21:40:57 ANS1898I * Processed77,500 files * 21:42:21 ANS1898I * Processed78,000 files * 21:43:45 ANS1898I * Processed78,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
