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 le=
t
>>> 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 syst=
em
being journaled to create a valid journal before journal based backup w=
ill
work.
If the Journal Service is stopped all journals are deleted and obviousl=
y
will no longer valid when the service is restarted so a full incrementa=
l
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 ex=
ists
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 delet=
e
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 ---------------------------
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=
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 obj=
ects
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 perfor=
m a
Journal backup on this particular client, so I DISABLED the service. O=
n
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 s=
till
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 o=
nly
eliminate the multiple sessions timing out or increase the performance =
of
my
backup?
Also, if anyone can explain this message it would be greatly appreciate=
d?
"psFsMonitorThread(tid 1044): Object 'C:\WINNT\Temp\TMP5.tmp' was delet=
ed
after notification."
Thanks,
Demetrius Malbrough
UNIX/TSM Administrator
=
|
