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: [EMAIL PROTECTED] Skype: cristie.christian.svensson ________________________________________ Från: ADSM: Dist Stor Manager [EMAIL PROTECTED] för Richard Sims [EMAIL PROTECTED] Skickat: den 4 december 2008 13:06 Till: ADSM-L@VM.MARIST.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