I know, I know. :) I appreciate that you even share your knowledge here on the ListServ. But you can see how I would be frustrated. Though I knew some of the caveats before I posted, I guess I was hoping you would say "No problem! Don't worry about it!". Sometimes, I can be naïve. I need to keep my child-like qualities, including "Wah! Things aren't going my way! Fix it!". :)
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Raibeck Sent: Thursday, July 10, 2008 6:26 PM To: [email protected] Subject: Re: [ADSM-L] Journaling database retaining upon reboot? 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/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <[email protected]> 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:[EMAIL PROTECTED] On Behalf Of > Andrew Raibeck > Sent: Wednesday, July 09, 2008 11:42 AM > To: [email protected] > 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/[EMAIL PROTECTED] > Internet e-mail: [EMAIL PROTECTED] > > 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" <[email protected]> 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:[EMAIL PROTECTED] On Behalf Of > > Andrew Raibeck > > Sent: Wednesday, July 09, 2008 10:40 AM > > To: [email protected] > > 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/[EMAIL PROTECTED] > > Internet e-mail: [EMAIL PROTECTED] > > > > 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" <[email protected]> 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:[EMAIL PROTECTED] On Behalf > Of > > > Erwann Simon > > > Sent: Wednesday, July 09, 2008 9:38 AM > > > To: [email protected] > > > 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
