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
|