ADSM-L

Re: [ADSM-L] Journaling database retaining upon reboot?

2008-07-10 19:27:22
Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 10 Jul 2008 16:25:33 -0700
You can change the tsmjbbd.ini file to PreserveDbOnExit=1 just before you 
reboot. Give it a few seconds, and the journal service should pick it up 
dynamically. Then go ahead and reboot.

Obviously we "support" PreserveDbOnExit=1, else it would not be there. I 
was simply trying to point out the caveats associated with usage 
("knowledge is power"). While even during a reboot, there is a small 
window of opportunity to miss journaling of a changed file, it is unlikely 
going to be for a critical file.

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page: 
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/09/2008 
10:48:18 AM:

> Well, I have to have some relief here, considering there's nothing that 
I can
> do about the setup. That means after they are using all 36 mount point
> (millions of files each), and there's a reboot, 36 different backups 
with
> journaling are going to have to start from scratch. Not only is that
> terrible, but there's nothing I can do about it! So for those reading 
this,
> what would you do in my situation, set PreserveDbOnExit to 1 or 0?
> 
> The TSM client host in question has 36 NTFS mount points, each will 5
> million+ files. Per IBM TSM Support recommendations, I set the host 
machine
> up with a TSM node for each mount point (therefore, 36), and configured
> journaling for each mount point as well. All per their guidelines and
> instruction. The application (an imaging app) on the host machine writes 
to a
> mount point until reaching a 80% utilized threshold, and then begins 
writing
> to the next numerical mount point. Last February, they started with 
mount
> point 1, and now they are on 12. That means when they patched the 
machine
> last night and rebooted, several backups have failed with memory errors, 
and
> there are 4 running right now, each just spinning their wheels on 
directories
> that mostly unchanged. I am really trying to remain calm, though it's
> sickening to think that there is simply nothing that I can do about it. 
:(
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Andrew Raibeck
> Sent: Wednesday, July 09, 2008 11:42 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
> 
> > Sooo...with all of these issues with jbb, are they being worked
> > on/fine-tuned?
> 
> Yes and no.
> 
> For the case where you use PreserveDbOnExit=1 and the journal service is 

> shut down for some period of time, the behavior will remain unchanged. 
Use 
> at your own risk. If the journal service is down, it cannot effectively 
> monitor file system changes so there is no known solution for this.
> 
> For the journal corruption issue, we are currently targeting an 
> enhancement that allows the journal service to know whether the database 

> was closed cleanly (by a clean journal service shutdown). Upon restart, 
if 
> the journal service does not detect the "I was closed cleanly" flag in 
the 
> journal database, it will effectively ignore PreserveDbOnExit=1 and 
reset 
> the journal database, as if PreserveDbOnExit=0 was in effect. This would 

> be in a future release of the product. Note that this does not represent 
a 
> formal announcement or commitment, so this is subject to change.
> 
> A THEORETICALLY cleaner solution could include implementation of of a 
> journal database with transactional capabilities, including rollback, 
more 
> thorough structural integrity checking, etc. Even in a rollback 
scenario, 
> in-flight file system changes would be lost (like the case where you use 

> PreserveDbOnExit=1 and journal service is down for some period of time), 

> leaving a less than perfect solution. But this is all hypothetical, and 
> there are no plans in place.
> 
> Best regards,
> 
> Andy
> 
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Product Development
> Level 3 Team Lead
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
> 
> IBM Tivoli Storage Manager support web page: 
> 
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.
> html
> 
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
> 
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/09/2008 
> 09:02:05 AM:
> 
> > The way the downtime for this particular machine goes, there should be 

> no
> > file system changes occurring.
> > 
> > Sooo...with all of these issues with jbb, are they being worked
> > on/fine-tuned?
> > 
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
> > Behalf 
Of
> > Andrew Raibeck
> > Sent: Wednesday, July 09, 2008 10:40 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
> > 
> > While the journal service is down, any file system changes are not 
> > tracked. If a file changes while the journal service is down, it will 
> not 
> > be backed up until either another full (non-journaled) backup runs, OR 

> the 
> > file changes again and the journal service is able to track it at that 

> > time.
> > 
> > If the journal service is not shut down cleanly (e.g., a cluster 
> failover 
> > in a cluster setup, or something else that causes the journal to not 
> shut 
> > down cleanly), the journal database might be in an inconsistent 
> > ("corrupt") state, after which behavior is unpredictable. 
> "Unpredictable" 
> > could run the gamut of files not getting backed up when they should or 
a 
> 
> > journal service crash when the corruption is encountered.
> > 
> > So PreserveDbOnExit=1 should only be used when you know you can stop 
the 
> 
> > journal service cleanly and you expect it to start shortly thereafter 
> > (like in a controlled reboot scenario).
> > 
> > Best regards,
> > 
> > Andy
> > 
> > Andy Raibeck
> > IBM Software Group
> > Tivoli Storage Manager Client Product Development
> > Level 3 Team Lead
> > Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> > Internet e-mail: storman AT us.ibm DOT com
> > 
> > IBM Tivoli Storage Manager support web page: 
> > 
> 
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.
> > html
> > 
> > The only dumb question is the one that goes unasked.
> > The command line is your friend.
> > "Good enough" is the enemy of excellence.
> > 
> > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/09/2008 
> > 08:09:54 AM:
> > 
> > > Yes, that's it. You set it to 1 if you want it to retain/preserve 
> after 
> > going
> > > offline.
> > > 
> > > I wonder why IBM recommended I keep it to zero in my situation?
> > > 
> > > -----Original Message-----
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
Behalf 
> Of
> > > Erwann Simon
> > > Sent: Wednesday, July 09, 2008 9:38 AM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
> > > 
> > > Hi Charles,
> > > 
> > > Look at the PreserveDbOnExit parameter of the tsmjbbd.ini 
> configuration 
> > > file.
> > > 
> > > As a general reference about JBB, read the FAQ :
> > > http://www-1.ibm.com/support/docview.wss?uid=swg21155524
> > > 
> > > -- 
> > > Best regards / Cordialement / مع تحياتي
> > > Erwann SIMON
> > > 
> > > Bell, Charles (Chip) a écrit :
> > > > I have a machine that has 36 NTFS Mount Points, each with millions 

> of
> > > files.
> > > > Since they are all hosted on the same machines, TSM Support highly
> > > > recommended setting up a node for each, and to have TSM journal 
> each. 
> > Now I
> > > > am running into a situation where every time that machine is 
> rebooted 
> > for
> > > > patches/etc., the incrementals have to rebuild the journal 
database. 
> 
> > Is
> > > there
> > > > a way to avoid that, as I am only 1/3 of the way through the Mount 

> > Point
> > > > Usage (They have only used 12 of the 36 thus far).  Please help. J 

> > > > 
> > > > 
> > > > 
> > > > God bless you!!! 
> > > > 
> > > > Chip Bell 
> > > > Network Engineer I
> > > > IBM Tivoli Certified Deployment Professional (ITSM)
> > > > Baptist Health System 
> > > > Birmingham, AL 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > -----------------------------------------
> > > > Confidentiality Notice:
> > > > The information contained in this email message is privileged and
> > > > confidential information and intended only for the use of the
> > > > individual or entity named in the address. If you are not the
> > > > intended recipient, you are hereby notified that any 
dissemination,
> > > > distribution, or copying of this information is strictly
> > > > prohibited. If you received this information in error, please
> > > > notify the sender and delete this information from your computer
> > > > and retain no copies of any of this information.
> > > 
> > > --------------------------------------------------------------
> > > Ce message ne contient aucun virus connu. http://www.astaro.fr
> > > 
> > > 
> > > --------------------------------------------------------------
> > > Ce message ne contient aucun virus connu. http://www.astaro.fr