The "Journal" is extremely finicky.  So much so that if you reboot the server 
you have to do a completely new backup of the drive the Journal service is 
watching so that the db will know what's going on again.  Now, for those that 
did not backup, if they did not reboot you should be able to just pick up from 
where you left off after Day 1.
ON those that HAD completed their backups you'll need to scratch the journal 
and do a new backup.  I know, it stinks, but such was our experience.  Unless 
they have drastically improved the journal service and stopped the crap they 
were doing before.
We had such trouble out of it that we went to the disk cache method for backups 
instead.  It's a little slower, and needs a good bit of disk space, but it's 
more reliable across reboots and crashes.

See Ya'
Howard

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Christian Svensson
> Sent: Thursday, December 04, 2008 6:53 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] SV: Journal unsync?
> 
> Hi Rich,
> Please don't comment our setup. We got much better performance when we
> moved from local disk to SAN and we have configure our SAN so it should
> work perfect.
> The issue was a Dell driver issue and nothing with the SAN. But we are
> still talking to DELL to understand why this happened.
> 
> I still wonder how Journal Database works in our case?
> Will it understand that our TSM Database doesn't have all information
> that the clients Journal Database has and will then do a roll-backward
> of the information?
> 
> Best Regards
> Christian Svensson
> 
> Cell: +46-70-325 1577
> E-mail: Christian.Svensson AT cristie DOT se
> Skype: cristie.christian.svensson
> ________________________________________
> Från: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] för Richard
> Sims [rbs AT BU DOT EDU]
> Skickat: den 4 december 2008 13:06
> Till: ADSM-L AT VM.MARIST DOT EDU
> Ämne: Re: Journal unsync?
> 
> On Dec 4, 2008, at 4:18 AM, Christian Svensson wrote:
> 
> > During the backup window and we say that maybe 50% of all our
> > backups have run successfully and the other half is maybe in
> > progress or are waiting for their time slot. But middle of the
> > backup windows does my SAN go down and all my backups stops that
> > mean 50% has run OK and 50% hasn't.
> > Now when I try to start my TSM Server it shows up that my log files
> > are corrupt and I need to do a TSM Database Recovery and my latest
> > TSM DB Backup is from Day 1.
> 
> Whoa, Christian...  Are you saying that your TSM database is on an
> unreliable SAN, rather than a far more reliable storage unit such as
> local disk?  This is the problem that really needs to be addressed,
> rather than secondary effects.  Your site is in great jeopardy where
> its storage networking is unreliable *and* its fall-back data store
> (TSM) is being crashed (and may be suffering damage you don't
> immediately perceive, which could make some restorals impossible).
> 
> Any issues with client backups needs to very much take a back seat
> until the manifest problems with TSM server infrastructure are
> corrected.  TSM db recovery should be a very exceptional thing, and
> not a routine consequence of unreliable storage.
> 
>     Richard Sims