ADSM-L

***The JOURNALED BACKUP saga continues...***

2015-10-04 17:13:40
Subject: ***The JOURNALED BACKUP saga continues...***
From: Pete Tanenhaus [mailto:tanenhau AT US.IBM DOT COM]
To: ADSM-L AT VM.MARIST DOT EDU
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 ---------------------------
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 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