Journaling - What are the drawbacks?

droach

ADSM.ORG Senior Member
Joined
Jan 7, 2008
Messages
239
Reaction score
13
Points
0
Location
Cut and Shoot, Texas
I have one virtual Windows server with over 16 million files. Many more VM's with between 1-6 million files. These are application servers and most of their data is static.

I am considering enabling journaling to reduce the long dance that the TSM client is performing through the files. My question is, what should I look out for when enabling journaling? Can I just turn it on and forget it, or do I really need to do periodic incrementals with journaling turned off? Any suggestions for a best practices type configuration using journaling?

Thanks.
 
Journaling is good for systems with many, many files. In my case, I turned it on an forget it! When the journal database gets corrupted, TSM just rebuilds it and runs a full incremental one time.

I say, use it in conjunction with node based collocation for fast restores in real time or DR situation.
 
Moon-buddy, not sure what you mean about TSM rebuilding a corrupt journal db. I've had occasion where a backup wouldn't run, even manually, and was fine after I deleted the journal, but it's always required manual intervention to delete. Did you mean manually deleting it and TSM Journal Service automatically creating another?

droach, one thing you'll likely want to decide on is a setting in the tsmjdbb.ini is "PreserveDBOnExit."
From BA Client Guide - "Specifies that the journaled file system journal database is not deleted when the journal file system goes offline."

Good info here...
http://www-01.ibm.com/support/docvi...=swg21155524&loc=en_US&cs=utf-8&cc=us&lang=en

Known issues...
http://www-01.ibm.com/support/docview.wss?rs=663&tc=SSGSG7&uid=swg21281972
Search for "Moving a directory from Windows Explorer using cut and paste " and be cautious of that. In your particular situation you posted, it shouldn't be a problem.
 
Moon-buddy, not sure what you mean about TSM rebuilding a corrupt journal db. I've had occasion where a backup wouldn't run, even manually, and was fine after I deleted the journal, but it's always required manual intervention to delete. Did you mean manually deleting it and TSM Journal Service automatically creating another?

There are settings that allows you to do this. All you have to do is restart the Journal service. Sometimes, you don't even have to. I had observed this three times already.
 
16 million objects on a VM Windows server.... yikes.

We have deployed journalling on only two servers in our farm. The first is for a digital voice recording system with about 10 million static files and the second was the company home drive also with 10 million files.

In both cases it has worked very well. We install monthly MS security patches so our journal is reset at least once a month. It performs a full-inrc then back to the journal for the rest of the month. It has cut a 14 hour job to a 14 minute job.

The one thing we noticed is that journal has some built in excludes. One being a PST exclude. Before we could deploy the process we had to have managment sign off on the PST exclude.
 
Back
Top