ADSM-L

[ADSM-L] SV: Journal unsync?

2008-12-04 07:59:35
Subject: [ADSM-L] SV: Journal unsync?
From: Christian Svensson <Christian.Svensson AT CRISTIE DOT SE>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 4 Dec 2008 13:53:14 +0100
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&#246;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

<Prev in Thread] Current Thread [Next in Thread>