Tűzoltás és megelőzés Esettanulmány az adatmentésről
Konstantinusz Kft. © 2010
„Kétféle ember létezik, akinek volt már adatvesztése, és akinek lesz.”
Kedves Hallgatók! Ez a tanulmány azért készült, hogy Ti, mint jövőbeni várható programozók / informatikusok / talán majd valamikori döntéshozók tisztában legyetek egy nagyon fontos dologgal, amiről nagyon sokan feledkeznek el, és aztán nagyon nagy árat fizetnek ezért: az adatok védelmével.
Tartalom Tartalom .............................................................................................................................................. 2 Bemutatkozás ...................................................................................................................................... 2 Mit mentünk? – az adatokról .............................................................................................................. 3 Mire mentünk? – az adattároló eszközökről ....................................................................................... 3 Mi van, ha nem mentünk? – tapasztalatok ......................................................................................... 6 Mit csináljunk, ha baj van? – tapasztalatok #2.................................................................................... 7 Összegzés........................................................................................................................................... 11
Bemutatkozás Általában ha adatmentésről kell írnom vagy beszélnem, mindig a fejlődés ütemének bemutatásával kell kezdenem, csak hogy érzékeltessem mekkora információmennyiség és technológiai tudás van ebben a szektorban. És hogy miért nem érthet mindenki mindenhez ezen a területen. Pedig csak számítógép, 1-esek meg 0-ák… Azt hiszem egyikőtöknek sem kell bemutatnom a technológia milyen fejlődésen ment keresztül, ha csak az utóbbi egy évtizedet nézzük. Én még „laktam” 20 Mbyte kapacitású diszken (igaz már vagy 15 éve volt), ma pedig, ha egy kisker árlistát előveszek 1.5 – 2 Tb-os lemezeket találok rajta. 500 Gb-nál kisebb HDD-t asztali gépekbe (3,5”) már nem is gyártanak. Esettanulmányunk nem csak az otthon használatos eszközökkel, hanem a nagyvállalati társaikkal is foglalkozik. Azt hiszem ez az a terület, ami kevésbé ismert előttetek.
Mit mentünk? – az adatokról Milyen adatokat tárolunk? Magánszemélyek oldaláról általában elsődleges fontosságúak a családi fotók. Nagyvállalatok vezetői hozták be a laptopjukat, hogy mentsük meg őket. A feleségüktől. Ugye a digitális fényképezőgépek révén ma már messze nem olyan körülményes dolog fotózni. Nem kell filmet tenni a gépbe, végére értem, kiveszem, elviszem előhívatni, majd egy hét múlva kész és örülök vagy nem, mert majdnem a fele nem sikerült. Tegye fel a kezét, aki nem lő el tízszer több kockát egy digitális masinával, mint egy hagyományossal. Aki felemelte a kezét az profi fotós, ők nem játszanak ebben a játékban. Szóval ugye a családfő és egyben családapa szorgalmasan fotózza csemetéjét, életének minden fontos pillanatát. Hol tárolja a fotókat? Persze, hogy a laptopon. Aztán mikor gyermeke harmadik születésnapja közeleg, megdöbbenve veszi észre, hogy bekapcsoláskor a színességes windows logó helyett a karakteres felület és egy disc not found felirat pislog rá vissza. Ilyenkor jön anyuka, akinek irtózatos haragja fenyegeti még a legnagyobb tőzsdecápákat is. Ilyenkor nem érdekli emberünket, hogy milyen céges dokumentumok voltak még esetleg a gépen, azokat lehet (talán) pótolni, a gyermek első három évét, és annak dokumentálását nem. Nem kell ahhoz cégvezetőnek lennünk, hogy olyan adataink legyenek, amik pótolhatatlanok. Megfigyeléseink szerint egy asztali gépben levő merevlemez átlagos élettartama 2-3 év. Igen, nekem is van olyan diszkem, ami 7 éve szorgalmasan kerreg a gépemben, de az átlag sajnos ennél jóval kevesebb. Még rosszabb a helyzet a laptopok terén. Egy laptop diszkjének átlagélettartama 1,5 – 2 év. Sokkoló, ugye? Na ezért kell lehetőleg minél több helyre menteni. Legalább időnként. Visszatérve az adatokhoz vállalati oldalról sokkal változatosabb a kép. Járt már nálunk grafikai stúdió a kiadványait visszakapni, nagyon gyakoriak az excel, word dokumentumok és a levelezés, de a legkellemetlenebb dolog, amikor egy vállalatirányítási rendszer alól esik ki az adatbázis. Mit kiesik? Elszublimál. Egyre több cég egyre több adatot tárol valamilyen adatbázisban. Komplex vállalatirányítási rendszerek kerülnek bevezetésre, ahol minden információ ott van egy helyen. És csak ott. Sehol máshol. A vállalatok jelentős része pedig nem foglalkozik backuppal. Aztán jön a krach. A kritikus adatvesztést elszenvedő cégek 75 %-a egy éven belül tönkremegy. Mármint azok, akiknek nem sikerült helyreállítani az adatait. Ez egy Uniós szintű adat. És mégis ott állnak mentés nélkül. Minek az? Engem nem érhet baj! – De.
Mire mentünk? – az adattároló eszközökről Itt is megkülönböztethetünk magánszemély és üzleti felhasználás területet. Értelemszerűen otthon nem használunk D2D2T (disc-to-disc-to-tape, lásd később) megoldást, így maradnak az egyszerűbb eszközök. Otthon elsődleges tárolási egységünk a winchester, amit egyébként csak idehaza nevezünk így, mindenhol máshol HDD-nek vagy egyszerűen csak diszknek nevezik. Szerintem mindenki látott már bontva ilyen eszközt, van többnyire egy, kettő vagy három tányér, amelyhez nagyon-nagyon közel ott vannak az író-olvasó fejek. 2007-ben a diszk-fej távolság a felülettől 0,00015mm volt. Egy átlagos lemez 5400, 7200 fordulat/perc sebességgel forog. Forrás: Králik János www.kralik.hu
Hogy elképzeljétek, ez az adatpárosítás mit jelent, olyan, mintha egy Boeing 747 közel 5 millió km/hval száguldana 2,5 milliméterrel a föld felett. Azt azért ebből kitalálhatjuk, hogy nem egyszerű igénybevételnek vannak kitéve egy merevlemez alkatrészei. Különösképpen, ha egy laptopban lakik szegény, ami még csak nem is stabil helyen van, ráadásul mozgunk vele. Mivel a tányérok mérete nem változott a kapacitásnövekedés csak az adatsűrűség növelésével volt megoldható. Ez egyetlen esetben jelent problémát, amikor meghibásodik az eszköz. Egy mechanikai sérülésnél így jóval több szektor tartalma vész el. Mit használjunk akkor helyette? CD/DVD? Sajnos ez sem megoldás. A képen egy pormentes tokban tartott 4 éves CD-t látunk, amin sajnos eléggé jelentős az anyagfáradás. Ez pedig olvasási hibát okoz. Ha hosszú távra szeretnénk ilyen lemezen tárolni adatokat, rendszeresen ellenőriznünk kell, és újra át kell írnunk, ha már nehézkes beolvasást tapasztalunk, szóval elég körülményes megoldás. Forrás: Nagy Barnabás (HP)
Szintén divatosak manapság az USB kulcsok vagy más néven pendriveok. Sajnos ez sem nyújt hosszú távú megoldást, ezen eszközök többsége az egy-két évet nem éli túl. Mit használjunk akkor? Legyen több diszkünk és az igazán fontos dolgokat tároljuk több helyen. (A fotókat pedig hívassuk elő).
Vállalati színtéren sokkal bőségesebb az eszköztár. Egy szervert az különböztet meg egy PC-től, hogy valamennyire redundáns kialakítású. Alapjában véve legalább a diszkek redundánsan kerülnek beépítésre, amelyeket egy RAID vezérlő lévén lát egy tömbnek a rendszer. Több változata használatos, a RAID 0,1,10 eljárások ma már PC-k számára is elérhetőek. A RAID 0, amit önmagában már nem használnak az összefűzés, ebben az esetben egy nagyméretű tömböt kapunk. Funkciója csak annyi, hogy nagyobb kapacitást érünk el egy tömbön, redundanciát nem biztosít. A RAID 1 (tükör) esetében minden információ mindkét diszkre kiírásra kerül, vagyis két diszk használata esetén csak egy diszknyi kapacitást tudunk használni, de amennyiben bármelyik diszk meghibásodik, a másikon még meg van az adat. A kettő összekapcsolása a RAID 10, amikor két RAID 1-es vagyis tükrözött tömböt kötünk össze. Erre azért van szükség, mert tükörpárt értelemszerűen csak két diszkből lehet képezni, ugyanakkor lehet, hogy jóval magasabb a kapacitásigényünk.
Ábrák forrása: Wikipedia
Mivel a RAID 10 esetén a beépített eszközök összkapacitásának csak a fele használható, nagyobb rendszereknél ez nem javasolt, helyette használják a RAID 5 kialakítást. Ennek lényege, hogy az adatok kiírása minimum 3, de gyakrabban 4 diszkre (3 lemez + 1 forgó paritás) történik. Három lemez és a paritás adataiból helyreállítható a negyedik lemez adata, így ez a megoldás egy lemez meghibásodása esetén működőképes marad, a meghibásodott eszköz kicserélése után a tömb újraépíthető. A paritás számolása miatt jelentős erőforrásigénye van, ezt vagy szoftveresen jelentős processzorterhelés mellett vagy – és ez a gyakoribb – RAID vezérlőkártyával oldják meg.
Eddig az elmélet. Mindez nagyon szép és jó, amíg a tömb egyben van. A probléma ott kezdődik, mikor a tömbünk szétesik. Ez leggyakrabban a már elöregedő eszközökkel történik meg, például amikor a vezérlőkártya elkezd hibázni, vagyis nem oda írja ki a sávokat, ahova azt kellene. Ennél is gyakoribb probléma, amikor a diszkek az élettartamuk végére érnek. A szerverekbe való HDD-k az asztali társaiktól eltérően 7/24-es (heti 7 nap, 24 órában) üzemelési igény alapján kerültek kialakításra. Ennél fogva stabilabbak és megbízhatóbbak, mindemellett 10, illetve 15 ezer fordulat / perces sebességük révén sokkal gyorsabb elérést is biztosítanak, mint az asztali gépekbe való társaik. Azonban egyszer ezek az eszközök is életük végére érnek. Csak az a baj, hogy többnyire még éles rendszerben helyezkednek el ekkor. Egy lemez kiesését mind a RAID 1, 10, 5 változatok kibírják. A meghibásodást viszont sajnos az üzemeltetők gyakran nem veszik észre. A hibás eszköz cseréjével és a tömb újraépítésével elhárulna a vészhelyzet (ilyenkor még nincs adatvesztés), de ez sokszor elmarad. Akkor kezdődik a probléma, amikor egy második lemez is megáll. Szerencsétlen RAID vezérlő még ekkor is küldözgeti neki az írási parancsokat, de az utasítás süket fülekre lel. A szerver eközben folyamatosan írogat a log file-ba, hogy segítség, csak többnyire nincs, aki ezt olvassa. Hiába a színes led a szerver elején vagy nem foglalkoznak vele, vagy megnyomják a confirm gombot azzal, hogy tudomásul vették a hibaüzenetet és minden megy… menne tovább. Egy szerver magától nagyon ritkán áll meg a redundáns kialakítás miatt. Ellenben amikor eljön egy újraindítás ideje, nagyon könnyen összeomlik. Üzleti környezetben mikor szokták leállítani vagy újraindítani a szervereket? Ünnepek és hosszú hétvégék idején. Na ezért van annyi munkánk húsvétkor, pünkösdkor és egyéb ünnepek alkalmából. Ezek az esetek is menthetőek, de jelentős a munkaigényük és nem biztos, hogy megoldható az adatok helyreállítása. Nagyobb rendszereknek, mint például adatbázisoknak jelentős tárhelyigénye van. Emiatt jelentek meg a bővítő dobozok, amelyekkel egy szerverhez még több diszket lehet csatolni. A megfelelő sebesség érdekében ezek a bővítő dobozok is saját vezérlő egységet (kontrollert) kaptak, így alakultak ki az első adattároló eszközök, a közvetlen csatolású storage-ok (Direct-Attached-Storage). Felmerült az igény arra, hogy ne csak egy szerver számára legyenek elérhetőek így alakultak ki a ma is használatos hálózati storage-ok (Network-Attached-Storage). Ezen eszközök előnye redundáns kialakításuk (két kontrollert tartalmaznak) és a hálózatban levő többi szerver részére is képesek nagysebességű, nagy tárhelyű kapacitást biztosítani. Mint minden centralizált megoldásnál itt is a probléma az, hogy ha ezek az eszközök működésképtelenné válnak, a teljes infrastruktúra megáll. Ezért szokták javasolni kritikus rendszereknél két replikált storage használatát, amikor mindkét eszközre kiírásra kerül ugyanaz az adat, és az egyik eszköz meghibásodása esetén a másik továbbra is
kiszolgálja az infrastruktúrát. Természetesen ez nagyon költséges megoldás és nem feltétlenül a kisés középvállalkozásoknak való. Ez alapján kijelenthetjük, hogy a biztonság pénzkérdés is. Van még egy eszköz, amit eddig nem említettem meg, pedig a biztonságos adattárolás jelenlegi legjobb megoldása: a szalagos adattárolók. Évek óta híresztelik sokan, hogy a szalagos egységeknek befellegzett, de nincs még egy olyan eszköz, amire 30 év garanciát vállalna bármelyik gyártó. Természetesen a garancia csak a gyártói előírásoknak megfelelő használat esetére vonatkozik, de így is nagyságrendekkel hosszabb idő, mint amit a többi említett megoldással biztosítani lehet. Hátránya, hogy a visszakeresés és visszaállás róla időigényes, ezért diszk alapú tárolással kombinálva javasolt a használata. Ennek egy megoldása a D2D2T (disc-to-disc-to-tape) eljárás, amikor az éles storage-ról egy backup storagera kerül kiírásra az adat, majd az kerül szalagra. Ennek előnye, hogy lemezen is található mentés, ergo gyorsan vissza lehet állni. A régebbi adatok viszont kiírhatóak szalagra, így nem muszáj a drága (és soha sem elegendő) diszk kapacitást használnunk archív adatok tárolására. Egy D2D2T rendszert összeállíthatunk mi is, de vannak külön e célra gyártott eszközök is.
Mi van, ha nem mentünk? – tapasztalatok Itt kezdődik a forróbbik része a történetnek. Magyarországon és szerte a világon a cégek jelentős részének nincs naprakész biztonsági mentése. Ez azt jelenti, hogy egy adatvesztés esetén vagy több héttel, hónappal korábbi állapotra kellene visszaállniuk vagy egyáltalán nincs visszaállási pontjuk. Gondoljunk bele, hogy például egy guminagykernél, egy csavarboltnál vagy egy hipermarketnél mekkora a cikkmennyiség és mekkora rekordváltozás van naponta. Képzeljétek el mekkora erőfeszítést jelent, ha akár csak egyetlen nap adatait be kell újra rögzíteni egyesével, ráadásul az eredetinek megfelelő sorrendben (hiszen a pénztárgép blokkja meg van). Ráadásul ilyen esetben nem elkerülhető emellett a teljes leltár, aminek folyamán általában mindig eltűnnek dolgok. És most csak egyetlen napról beszéltünk. Volt egy olyan könyvelő iroda, ami kénytelen volt 3 hónapra visszamenően az összes partnerének az összes bizonylatát újra berögzíteni a rendszerébe. Közel egy hónapjukba telt. Úgy hogy minden bizonylat ott volt. Szerintetek mennyire lelkes egy alkalmazott, aki mellé odatesznek egy közel 1,5 méter magas papírhegyet, hogy ezeket a bizonylatokat egyesével be kell rögzíteni? Mennyire lesz ez pontos? Mi történik, ha ez egy nagyker üzlet ahol átutalásos számlákat állítottak ki és véletlenül pár számla kimarad, vagy más összeg szerepel rajta? Bizony. Nem veszi észre senki. A kár pedig nem egy átsörözött éjszaka költségvetésével egyenértékű… Ha ez így van, mégis miért nincs a cégeknek naprakész mentése? Erre nincs egyértelmű válasz. A döntéshozók vagy nincsenek tisztában azzal, hogy informatikai rendszerük inkább hasonlít egy időzített bombához, mint egy a vállalat tevékenységeit támogató rendszerhez vagy nem akarnak tudni róla. Manapság ugye egyre nagyobb és fontosabb szerepe van az informatikának a vállalatok életében. Mondhatni beköszöntött a digitális korszak. A cégek egyre több tevékenységét nem csak hogy támogatják az informatikai eszközök, hanem egyenesen létfeltételükké váltak. Egy estleges leállás lehetetlenné teszi a vállalati folyamatok működését. Ugyanakkor az IT-t többnyire nem tekintik a vállalati tevékenységek részének. Az IT nem hoz pénzt, mint a termelés és az értékesítés, nem
törvényi kötelezettség, mint a könyvelés és a bérszámfejtés, az IT csak van. És ahelyett, hogy támogatná a többi részleget és megülne csendben, egyre több és több forrásra van szüksége. Innen aztán egyenes módon következik, hogy mi a spórolás tárgya. Nem vásárolnak legális szoftvereket, csak a működéshez létfontosságú eszközök kerülnek beszerzésre vagy még azok sem. Van olyan cég, amely még ma is 2001-ben gyártott szervereket használ. A közelmúltban kiderült, hogy a 3 db diszkből amit RAID 5-be fűzve használnak az egyik megállt. Jeleztük nekik, hogy nagyon sürgősen cserélni kellene, mert jelenleg a teljes összeomlás szélén áll a rendszerük. Azt mondták, hát igen, ez fontos téma, beszéljünk róla pár nap múlva. Azóta háromszor kerestem őket ebben a témában. Három hónapja húzódik az ügy. Valamiért inkább kockáztatják a teljes adatvesztés kockázatát – vagy egy milliós nagyságrendű adatmentési költséget – egy biztos megoldást nyújtó, százezer forintos nagyságrendű javítás helyett. Ilyen tapasztalatok mellett nem meglepő, hogy archiválásra gyakorlatilag nem költenek a cégek. Gyakori a hozzáértés vagy éppen a józan paraszti ész teljes hiánya. Mással nem tudom magyarázni azt, hogy egy az üzletmenet szempontjából kritikus szerver mentése ugyanazon a szerveren ugyanannak a RAID tömbnek egy másik partícióján található. Miért van szükségük mentésre? Azért, hogy ha baj történne és a RAID tömbjük szétesne, legalább az adatbázisuk adatai megmaradjanak. Hova teszi a mentést? Ugyanarra a RAID tömbre. Gratulálok. Akkor ez most mitől is fogja megvédeni őket?
Mit csináljunk, ha baj van? – tapasztalatok #2 Először is ne essünk pánikba. Gondoljuk végig, hogy mit csináltunk az elmúlt percekben, mitől állhatott le a rendszer. Aztán gondoljuk végig, hogy milyen olyan adatok vannak az érintett eszközön, amik fontosak. Ha nincs rajta fontos adat, jó szórakozást a kísérletező kedvűeknek. Csak nehogy utána kiderüljön mégis volt…
Itt most ajánlatos két részre választani a történetet. Első esetünk, amikor egy pc-ről vagy laptopról van szó. A leggyakoribb adatvesztést kiváltó ok értelemszerűen a diszk meghibásodása. Ez lehet üzemszerű működés közben bekövetkező meghibásodás vagy egyéb okokból eredő hiba. Egyéb okok közé tartozik a villámcsapás vagy az áramhálózaton jelentkező túlfeszültség. Ez leégeti a gép tápegységét, aztán szépen végigmegy a tápkábeleken és pusztít, amit ér. Volt már hozzá szerencsétlenségem, nekem a tápegység mellett az alaplapom a processzorom, a memória moduljaim és a grafikus kártyám bánta. A diszk valamilyen úton-módon nálam akkor kivételes módon megúszta. Pedig nem túlzottan ellenálló az ilyesmivel szemben. Ilyen egyéb okból történő meghibásodás, amikor a gép szerelése közben főhősünk sikeresen fordítva csatlakoztatja a tápkábelt a meghajtóra. Ez még nem lenne akkora baj, csak utána be is kapcsolja a gépet. Az egyes lábakon eltérő feszültséget kap az eszköz. Sajnos fontos, hogy melyik lábon mennyit. Elméletileg éppen ennek elkerülése érdekében nem lehetséges fordítva feldugni a tápkábelt. Én ennek ellenére két emberrel is találkoztam, akiknek ez sikerült. Nem mondom, hogy büszkék voltak erre a teljesítményükre. A leggyakoribb és legsúlyosabb hiba ilyen esetekben az, hogy az elkövető vagy egy szolgalmas
ezermester úgy gondolja, hogy ő ezt a hibát meg tudja javítani. „Ugyan, csak a panelt kell lecserélni, az sérült csak!”. Ezért aztán keres lehetőleg ugyanattól a gyártótól egy hasonló meghajtót és lecseréli a panelt és mégsem működik. A probléma a következő: a túláramból eredő meghibásodások 95 %ában a panel nem a végállomás, a túláram az eszköz készülékház alatti részeit is tönkreteszi – egy panel csere a belső részeket nem javítja. Ha esetleg az ilyesmire kényes író-olvasó fej vagy motor még túl is érte volna ezt a támadást, az új panellel való első bekapcsolás elvégzi azt, amit a túlfeszültség nem tudott. Az eszköz vezérlése ugyanis tudja, hogy konkrétan melyik panel lakik a burkolat külső oldalán (gyáriszám szinten), ezért egy panelcsere esetén a vezérlő elektronikának is meg kell mondani, hogy másik panellel kell együtt dolgoznia. Nem beszélve arról, hogy pont abból a típusból és abból a verziójából van szükség donorra, mivel egy adott gyártó, adott kapacitású eszközének is több változata van, eltérő panelekkel vagy vezérléssel. Egy meghajtó egy szériáját ritkán gyártják 6-12 hónapnál tovább. Tanulság: ne cserélgessük a panelt, ha fontosak a diszken levő adatok. Idevágóan: kedvencünk a különböző informatikai szaklapokban írt cikkek, „a hogyan mentsünk adatot otthon?” témakörben, mókusszőr ecsettel és hűtőszekrénnyel. Nem muszáj ahhoz barkácsolnunk, hogy elromoljon a meghajtónk. Rendeltetésszerű használat közben is történhetnek meghibásodások. Ilyenkor általában a szokásostól eltérő hangra és / vagy jelentős lassulásra figyelhetünk fel. Általában ilyenkor két dolog romolhat el. Az író-olvasó fej vagy a motor. Ha szokatlan hangokat hallunk az eszköz felől vagy időnként jelentősen és indokolatlanul belassul, haladéktalanul gondoskodjunk biztonsági mentésről. Lehet, hogy csak az operációs rendszer játszott velünk, de sosem volt még baj abból, ha máshova is le volt mentve a fontos adatunk. Fontos, hogy ha már a gép sem ismeri fel a meghajtót (se oprendszer, se bios), akkor ne erőltessük próbálkozással „hátha majd most megy” felkiáltás alapján. Csak a mechanikát gyötörjük és csökkentjük a helyreállítás esélyét. A véletlenszerű törlések vagy fájlrendszer összeomlások helyreállítására nagyon jó programok vannak. De mindenki csak saját felelősségre használja, annak ismeretében, hogy lehet, hogy a most először használt alkalmazással megoldja a hibát, de lehet, hogy most teszi végképp menthetetlenné az adatait. Természetszerűleg csak azt javasolhatom, forduljatok szakértő céghez. És ez most nem a reklám helye, nem mi vagyunk az egyetlen cég, aki ilyennel foglalkozik. Ha nincs baja az eszköznek, megmondják. Még pénzt se biztos, hogy kérnek érte.
Történetünk másik szála a vállalati rendszerekben bekövetkező meghibásodások, adatvesztések. Mivel többnyire ezek komplexebb rendszerek, így itt nem csak a meghajtó hibája az egyetlen hibaforrás. Tapasztalataink szerint az adatvesztések 95%-a megelőzhető vagy a bekövetkező kár mérsékelhető lett volna kellő odafigyelés esetén. Két fő meghibásodási okkal szoktunk találkozni általában: az eszköz valamiért bedobja a törölközőt vagy valaki nagyon okos volt. Illetve, ezen két változat kombinációja. Gyakran kulcsfontosságú, hogy minden információ a rendelkezésünkre álljon. Üzleti kritikus rendszereknél, ahol minden óra, minden nap állásidő komoly károkat okoz, kincset ér, ha nem nekünk kell kitalálni, hogy mi mindent próbáltak végig az eszközön. Előbb-utóbb kitaláljuk, de gyorsabban haladunk, ha csak a hiba elhárításának módját kell kitalálnunk, nem pedig azt is mellette, hogy konkrétan mi vezetett a hibához és mivel próbálták elhárítani azt. Összegyűjtöttem néhány érdekes esetet a közelmúltból:
1. eset: „Másik foglalatban biztos jó” Ebben az esetben adott volt egy szerver, ami 8 db diszkhellyel rendelkezett. Kedves partnernek nem volt ekkora tárhely igénye, ezért amikor vásárolták az eszközt réges-régen egy messzi-messzi galaxisban, akkor 4 db diszkkel kérték. A 4 db diszk RAID5 tömbbe lett rendezve. A szerver éveken át megbízhatóan működött, amikor is elkezdett világítani rajta mindenféle színes led és lassult is, de egyébként működött tovább. Aztán pár nappal később lefagyott, újraindították és nem indult el. Így került hozzánk az áldozat. A diszkek a 0,1,2,3 foglalatban voltak, a 4,5,6,7 foglalat üres volt. (Értelemszerűen, hiszen ilyen esetben az első 4 foglalatot szokás feltölteni). Kollégák leellenőrizték az eszközt és az alábbiakat állapították meg: -
a szerver az elmúlt 3 hónapban 4 alkalommal állt le thermal shutdown jelzéssel – ez konkrétan túlmelegedést jelent a 4 meghajtóból az egyik kb. 2 hónapja elhalálozott. egy másik a végső leálláskor, annak okozójaként állt meg – egy thermal shutdown mellett a RAID vezérlő logbejegyzései alapján a hiba bekövetkezte után további újraindítási próbálkozások voltak. Az egyes újraindítások alkalmával a log szerint diszk volt a 4,5,6,7 foglalatokban is. Volt, hogy mindegyikben, volt hogy csak egyikben-másikban. Valaki próbálgatta, hogy hátha másik foglalatban jó lesz. Természetesen szegény RAID vezérlő minden esetben próbált volna újjáépíteni a szétesett RAID tömböt, de ez nem sikerült.
És ezeket mindet nekünk kellett megfejtenünk, a kapcsolattartó nem tudott róla. Jó néhány munkaórába telt, de sikeresen helyreállították mérnökeink az adatokat. Tanulság: Szerver környezetben nem ajánlott kísérletezni. Főleg nem olyan dolgokkal, amik alapjában véve sem vezethetnek eredményre.
2. eset: „Hot-plug vagy non-hot-plug” Vannak az óvatos emberek. Kedves Ügyfél egy olyan szerverrel rendelkezett, ami hot-plug diszkekkel volt ellátva. Ennek lényege az, hogy menet közben, leállítás nélkül is cserélhetőek. Ha egy lemez meghibásodik, nem kell leállítani a szervert, hibás diszket kivesz, a csere diszket betol és a RAID vezérlő szépen újraépíti a tömböt. Főhősünk tudta hogy RAID 5 tömbje van, érzékelte a hibát, látta, hogy a szerver elején látható 4 diszk közül csak három villog zölden, a negyedik led-je sárgán ég. Lejelentette, hát a gyártónak a hibát, megkapta a garanciális csere diszket és annak rendje és módja szerint kihúzta a helyéről a meghibásodottat. Itt pedig elkezdett gondolkozni. Hogy ő most beteheti-e ebbe működés közben a másik diszket? (Helyes megoldás: mivel hot-plug, igen). Ő a biztonság kedvéért inkább kikapcsolja a szervert. Fényes nappal éles szervert, úgy hogy felhasználók voltak éppen rajta. Slusszpoénként hogy kapcsolta ki a szervert? Aki idáig eljutott az olvasással, az valószínűleg kitalálta. Power gombot hosszan nyomva. Nem állította le a futó service-eket, nem lépett ki az operációs rendszerből, hiszen minek is azt? Amennyiben csak simán betette volna a csere eszközt, a RAID vezérlő felismerte volna, hogy új eszköz van a tömbben és teljesen magától, mindenféle beavatkozás nélkül újraépítette volna a tömböt, visszaállítva a meghibásodás előtti biztonságos állapotot. Így egy összeomlott operációs
rendszer és file-rendszer fogadott minket. Szerencsére viszonylag egyszerűen helyre lehetett állítani az adatokat, főhősünk nem okozott jelentős kárt, de ilyen egyszerűen is tönkre lehet tenni egy rendszert. Tanulság: ha nem tudod, hogy mit csinálsz, inkább kérj segítséget.
3. eset: „Bolhából elefántot” Az egyik gyártóval rendezvényünk volt, előadásomba becsempésztem egy kis adatmentést is. Egy negyven perces prezentációba belefér 5 mondat, hogy mentsenek gyakran, és ne kísérletezzenek, ha fontos az adat. Nagyjából két hónappal később csörög a telefon. Egy kedves hölgy van a vonalban, hivatkozik a rendezvényre, hogy akkor hallott minket, és hogy most lenne egy kis problémája és rögtön ránk gondolt. A történet a következő: van nekik egy pc-jük, amiben lakott egy kedves diszk. Egy nap, amikor bekapcsolták a gépet, kiírt valami hibaüzenetet. Ők kihívták a céget, akiktől a pc-t vették. „Szakemberük” megállapította, hogy meghibásodott a panel. Sebaj, van nekik ilyen winchesterük, majd átszereli rá annak a paneljét és minden frankó lesz. Átszerelte. Nem ment. (Indokokat lásd fentebb). Visszaadta. A hölgy kollégái megpróbálták még egyszer. Megdöbbentő módon nekik se működött. Volt náluk egy még ennél is okosabb ember, aki kitalálta a frankót: szét kell szedni. Szétszedték. Többnyire azért ismert tény, hogy a diszken belül nagy tisztaságú pormentes levegő van. A por az adataink ellensége. Márpedig a levegőben por van. Emiatt a diszkeket kizárólag tisztatérben szokás megbontani. Ez technológiailag az inkubátorhoz hasonlít vagy a filmekben látható légzsilipelt helyiségekhez. Abban a pillanatban, hogy zseniális emberünk felnyitotta a készülékházat az elektromágneses felület megkötötte a levegőből a porszemcséket. Kérdeztem a hölgyet, van-e pótolhatatlan adat az eszközön. Válasz: igen. Kérdeztem, akkor miért nyúltak hozzá? Főleg ha rögtön eszébe jutottam. Válasz: háááát..öööööö….. A meghibásodás oka egy firmware hiba volt. Kb. fél óra alatt, bontás és kockázat nélkül el lehetett volna hárítani minimális költség mellett. Ehelyett olyan alacsony helyreállítási esélyt idéztek elő, olyan magas költség mellett, hogy inkább lemondtak a pótolhatatlan adatokról.
4. eset: „A kirúgott vezérlőkábel” Érdekes történet, főszerepben egy rossz helyen bóklászó IT vezetővel. A szervereket manapság két féle formában gyártják: torony szerver és rack-es szerver (ide számítottam a blade rendszerű szervereket is). Segítségképpen lásd képeket oldalt. torony szerver
rack szerver
Ügyfelünknek saját rack szekrénye volt. Érdekességképpen íme két kép, hogy néz ki egy ilyen szemből és hátulról. Mint látható, hátulról ez meglehetősen kesze-kusza látvány, avatatlan szemeknek még a legjobban megtervezett és kialakított kábelezés is inkább valami káoszelméletet juttat eszébe, mintsem tudatos tervezést. Általában a rack szekrény mögé nem megyünk, csak ha valami dolgunk van ott. Akkor is csak az megy oda, aki dolgozik. Kedves Ügyfélnek volt egy adatbázis szervere, ami egy közvetlen csatolású adattárolóra (DAS – Direct-Attached-Storage) dolgozott. Ennél a típusnál a storage nem rendelkezett külön vezérlő eszközzel (kontroller), hanem a szerver vezérlőkártyája utasította direktben a diszkeket. A szervert két vezérlőkábel kötötte össze az adattárolóval. Az IT vezető valamilyen fontos ügyből kifolyólag éppen a szekrény háta mögött tartózkodott, amikor egy véletlen mozdulattal sikeresen kirúgta mindkét vezérlőkábelt a helyéről. El nem ítélhető módon ez az adatbázis szervernek zokon esett. Főhősünk a mindent tudók nyugalmával és higgadtságával újra összekötötte a két eszközt. Egyetlen probléma az volt, hogy sikeresen felcserélte a két kábelt. Valamiért a szerver továbbra se látta ezután az adatokat, viszont ha már egyszer talált egy külső eszközt elkezdett rajta felépíteni egy RAID tömböt. Igen, ilyenkor a korábbi tömböt annak összes adatával felülírja… Miután szolid 8 óra tömb újraépítés után sem volt eredmény, felhívtak minket. Kollégáink sikeresen újraépítették az eredeti tömböt, főhősünk pedig megfogadta, hogy többé nem megy a szekrény mögé. Vagy ha igen, óvatosan lépked majd.
Összegzés Aki idáig eljutott az olvasásban az most már biztosan tudja, hogy miért fontos menteni, miért nem jó, ha addig ki nem próbált dolgokkal próbáljuk elhárítani az addig nem ismert hibát. Mégis mit kell akkor tenni? A kulcs, mint majdnem minden más esetben itt is a megelőzés. Menteni, menteni, menteni! Otthoni körülmények között ez egyszerű. A cél, hogy ne csak egy helyen legyenek a fontos adataink. Lehetnek azok egy külső diszken, lehetnek azok egy NAS dobozon vagy akár dvd-n is, de sohasem egyetlen helyen. Fontos, hogy rendszeresen mentsünk és ellenőrizzük is le, hogy használhatóak-e az archivált adatok. Már ha akarjuk őket később is használni… Vállalati környezetben ez egy kicsit bonyolultabb, például nem minden adatbázist lehet működés közben file szinten menteni, de még így is jobban megéri esetleg segítséget kérni a mentés megtervezéséhez, mint egy adatvesztés esetén kétségbeesetten keresni az – általában nem olcsó – megoldást.
Ha netalántán mégis beüt a baj, ne féljünk segítséget kérni. Ne rontsuk a helyzetet, ha nem muszáj. Egy vállalat esetében ugyanis mindig az ADAT a legnagyobb érték. Köszönöm a figyelmet!
