- A RAID rendszerek javítják a teljesítményt és a rendelkezésre állást, de nem helyettesítik a biztonsági mentéseket, és nem immunisak a fizikai, logikai vagy emberi hibákra.
- A furcsa zajok, a leromlott állapot, a rendellenes lassúság, valamint a paritásos vagy olvasási/írási hibák egyértelműen jelzik a RAID közelgő problémáit.
- Az újraépítések erőltetése, a lemezek dokumentáció nélküli átrendezése vagy az általános javítóeszközök használata egy kezelhető hibát teljes adatvesztéssé változtathat.
- A körültekintő és korai cselekvés, valamint a RAID-helyreállítási szakemberek támogatása jelentősen növeli az információk mentésének esélyét.
A RAID rendszerek elterjedtek a szerverekben, NAS eszközökben és tárolótömbökben, mivel megnövekedett teljesítményt és hibatűrést ígérnek . Azonban, bár megnyugtatóak, nem csodaszerek: egy rosszul kezelt hiba katasztrófához vezethet, és perceken belül adatok nélkül hagyhatja Önt.
Amikor egy RAID rendszer szokatlan tüneteket mutat, nem a leggyorsabb beavatkozás a lényeg, hanem a legóvatosabb. A meghibásodás jeleinek észlelése és annak ismerete, hogy mit NEM szabad tenni, jelenti a különbséget egy egyszerű lemezcsere és a teljes, helyrehozhatatlan adatvesztés között, még egy profi laboratórium számára is.
Mi a RAID hiba, és miért nem ugyanaz, mint egy biztonsági mentés?
A RAID (Redundant Array of Independent Disks, azaz Független Lemezek Redundáns Tömbje) több lemezt csoportosít a nagyobb rendelkezésre állás, teljesítmény és/vagy redundancia biztosítása érdekében , a használt szinttől függően. A klasszikus tükrözött RAID 1-től a bonyolultabb konfigurációkig, mint például a RAID 5, RAID 6 vagy RAID 10, az az elképzelés, hogy a rendszer akkor is tovább működjön, ha egy (vagy több) fizikai lemez meghibásodik.
A probléma az, hogy sokan azt feltételezik, hogy „van RAID-em, tehát van biztonsági mentésem”, és ez alapvető tévedés. A RAID nem helyettesíti a biztonsági mentéseket : véd egy vagy több lemez meghibásodása ellen (a RAID szinttől függően), de nem akadályozza meg a logikai sérülést, az emberi hibákat, a zsarolóvírusokat, a véletlen törléseket, illetve a vezérlő- vagy szerverhibákat.
Továbbá a vezérlő – beleértve a vezérlő firmware-ét is – általi adatelosztási módja (lemezsorrend, csíkméret, paritásalgoritmusok, metaadatok stb.) azt jelenti, hogy a tömb bármilyen helytelen manipulációja tönkreteheti a struktúrát, és rendkívül bonyolulttá teheti a helyreállítást, még akkor is, ha a lemezek „látszólag” rendben vannak.
A fő RAID-szintek és azok hatása a helyreállításra
Minden RAID-szint másképp viselkedik hibák esetén, és ez jelentősen befolyásolja az adat-helyreállítási lehetőségeket. Ezen különbségek megértése segít elkerülni a kockázatos döntéseket, ha valami rosszul sül el.
Egy RAID 0 tömbben az adatok több lemezen csíkozódnak paritás vagy tükrözés nélkül. Nincs semmilyen redundancia : ha egyetlen lemez meghibásodik vagy kellően leromlik, a logikai veszteség teljes, mivel minden fájl lényeges része hiányzik. A "rekonstrukcióról" itt nincs sok értelme; a prioritás az, hogy megpróbáljuk helyreállítani azt, amit a fizikailag sérült lemezekről helyre lehet állítani.
Egy RAID 1 tömbben a lemezek tükrözöttek: minden meghajtó az adatok teljes másolatát tartalmazza . Ez a konfiguráció általában meglehetősen megbízható az adat-helyreállítás szempontjából, feltéve, hogy nem történik kezelési hiba (például az egyik lemez inicializálása egy másik rendszeren, vagy keverésük inkompatibilis vezérlőkön).
A RAID 5 több meghajtó között osztja el az adatokat, és elosztott paritást számol, így képes ellenállni egy meghajtó meghibásodásának . A probléma akkor merül fel, amikor egy második meghajtó meghibásodik az újjáépítés során: a munkaterhelés az egekbe szökik, olvasási hibák jelennek meg, és a tömb figyelmeztetés nélkül összeomolhat.
A RAID 6 hasonlóan működik, mint a RAID 5, de egy második paritást is hozzáad, amely lehetővé teszi akár két lemez meghibásodásának elviselését . Cserébe az architektúra összetettebb, az újraépítések tovább tartanak, és a logikai vagy konfigurációs hibák tovább bonyolítják a helyreállítási erőfeszítéseket.
A RAID 10 egyesíti a tükrözött és a csíkozott lemezeket: a tükrözött lemezpárok „megsemmisülnek”. A helyreállítás szempontjából a lemezek sorrendje, valamint a tükrözött és a csíkozott lemezek közötti kapcsolat kritikus fontosságú; a pozíciók keverése vagy a vakon történő újraépítés tönkreteheti a tömböt, még akkor is, ha az összes lemez fizikailag ép.
Egyértelmű jelek arra, hogy a RAID meghibásodni kezd
Mielőtt egy rendszer teljesen összeomlik, általában egy sor nyomot hagy maga után. Ha megtanuljuk felismerni ezeket, időben meg tudjuk állítani a helyzetet és megelőzni a további károkat.
Az egyik legnyilvánvalóbb jel a lemezekről kiszűrődő furcsa zajok: ismétlődő kattanások, nyikorgás, szakaszos zümmögés vagy fémes hangok, amelyek korábban nem voltak jelen. Ezek a zajok általában az olvasó-/írófejek vagy a lemeztányérok mechanikai hibáira , vagy a motorral kapcsolatos problémákra utalnak. Ha figyelmen kívül hagyja őket, és továbbra is erőlteti az olvasást, a meghajtó állapota jellemzően nagyon gyorsan romlik.
Egy másik tipikus jel a „Degraded” (Csökkent teljesítményű), „Failed” (Hiba) vagy „Critical” (Kritikus) üzenetek megjelenése a NAS vagy RAID vezérlő kezelőkonzolján. Ez az üzenet azt jelenti, hogy egy vagy több lemezt problémásként jelöltek meg , és a tömb a kívánt redundancia nélkül működik. Ezen a ponton, különösen RAID 5 esetén, egy második hiba lehet az utolsó csepp a pohárban.
Figyeljen a kevésbé észrevehető, de ugyanolyan veszélyes tünetekre, mint például a hirtelen és megmagyarázhatatlan teljesítménycsökkenés . Ha az olvasási és írási idők az egekbe szöknek, különösen bizonyos kötetek vagy mappák elérésekor, akkor a vezérlőnek problémái lehetnek a nehezen olvasható szektorokkal, vagy folyamatos újrapróbálkozásokba ütközhet, amelyek túlterhelik a rendszert.
A rendszer- vagy vezérlőnaplók gyakran mutatnak I/O hibákat, helytelen paritásüzeneteket, „Javíthatatlan olvasási hiba”, „Paritásellenőrzés sikertelen” vagy „Hibás csík észlelve” üzeneteket. Az olvasási/írási hibák számának tartós növekedése , még akkor is, ha a rendszer továbbra is működik, egy olyan vészjelzés, amelyet nem szabad figyelmen kívül hagyni.
Egy másik vészjelzés, ha a kötet állapota romlottnak tűnik, annak ellenére, hogy látszólag egyetlen lemez sem hibásodott meg teljesen . Ez általában a RAID metaadatok vagy az elosztott blokkok logikai sérülését jelzi, és az automatikus újraépítés kikényszerítése ebben az állapotban a teljes tömbben elterjesztheti a sérülést.
A logikai sérülés és a csendes problémák tünetei RAID-ben
Nem minden RAID hiba eredményez azonnali „halott” lemezt. A probléma gyakran a fokozatos adatvesztés , amely észrevétlenül bekúszik, amíg a helyzetet már nagyon nehéz visszafordítani.
Tipikus példa erre az olyan fájlok, amelyek látszólag léteznek, megfelelő méretűek és nevűek, de nem nyílnak meg, formázási hibákat tartalmaznak, vagy csonkolva jelennek meg . A nem csatlakoztatható adatbázisok, a nem induló virtuális gépek vagy a megjelenítő által elutasított képek általában a lemezeken elosztott blokkok inkonzisztenciáira utalnak.
Az is gyakori, hogy az operációs rendszer vagy az alkalmazások lokális lassulást mutatnak bizonyos RAID köteteken, annak ellenére, hogy a CPU és a RAM nem tűnik különösebben leterheltnek. Ha a lassulás az ugyanazon a köteten végzett olvasási/írási műveletekre koncentrálódik, akkor nagy valószínűséggel sérüléssel vagy instabil szektorokkal van dolgunk.
Egy másik veszélyes tünet, hogy a lemezcsere után induló újraépítések mindig ugyanazon a ponton állnak meg , furcsa hibákat dobnak, vagy egyszerűen sikertelenként jelölik meg a folyamatot. Ez általában azt jelzi, hogy a forrásblokkok már sérültek, és a vezérlő nem tud koherens másolatot generálni az új lemezen.
Néha csak egyetlen lemezen jelennek meg SMART riasztások (újraelosztott szektorok, magas elérési idők stb.), de a szokatlan viselkedés az egész RAID tömbben észrevehető. Ilyen esetekben egyetlen hibás szektorokkal rendelkező lemez is veszélyeztetheti a teljes tömb konzisztenciáját, különösen paritásellenőrzés vagy újraépítés kezdeményezésekor.
Ha figyelmen kívül hagyjuk ezeket a figyelmeztetéseket, és továbbra is a megszokott módon működünk, vagy ami még rosszabb, intenzív feladatokat, például ellenőrzéseket, tömeges biztonsági mentéseket vagy automatikus újraépítéseket erőltetünk, az a sérülés terjedéséhez vezethet, és az érvényes blokkokat sérült adatokkal írhatjuk felül . Ettől a ponttól kezdve még a professzionális eszközök sem garantálják a teljes helyreállítást.
Tipikus hibák vezérlőkben, szerverekben és alaplapokban
Nem csak a lemezekről van szó. A RAID-vezérlő, az alaplap, vagy akár az egész szerver is gyenge láncszemmé válhat, és tömbhibákat okozhat, még akkor is, ha a lemezek rendben vannak.
A RAID-vezérlő, akár dedikált hardverről, akár az alaplapra integráltról van szó, felelős azért, hogy az egyes blokkok hová kerüljenek, hogyan kerüljön kiszámításra a paritás, és hogyan legyenek összeállítva a kötetek . Egy hiba, sérült firmware vagy túlfeszültség letilthatja, ami a tömb eltűnését vagy „Idegen”, „Offline” vagy hasonló jelzést okozhat.
A dedikált hardvervezérlők esetében van egy további probléma: a modellek és gyártók közötti szinte teljes kompatibilitás hiánya . Ha például egy adott Supermicro vezérlő meghibásodik, nem elég egyszerűen "egy hasonlóra" cserélni: gyakran pontosan ugyanolyan modellre, hasonló firmware verzióval van szükség ahhoz, hogy helyesen olvassa a RAID metaadatokat.
Az integrált RAID-megoldások (úgynevezett „ál-RAID”), mint például egyes AMD vagy Intel lapkakészlet szoftveres RAID-ek, esetében fennáll annak a kockázata, hogy az alaplap cseréje, a BIOS visszaállítása vagy a CMOS-konfiguráció elvesztése működésképtelenné teheti a tömböt. Számos asztali számítógépben és munkaállomásban az alaplap vagy a CMOS akkumulátor meghibásodása törölheti a RAID-konfigurációt, így a meghajtók elszigetelt egységekké válnak.
Továbbá maga a szerver ( tápegység , memória, alaplap, hátlap stb.) is meghibásodhat elektromos problémák, túlmelegedés vagy hardverhibák miatt. Ezekben az esetekben a gyakorlatban a RAID elérhetetlenné válik , bár a valóságban a lemezek, megfelelő stratégiával egy másik rendszerhez csatlakoztatva, helyreállíthatnák az adataikat.
Ráadásul a rendszernek minden újraindításkor vagy rendszerbetöltéskor „újra össze kell szerelnie” a RAID tömböt. Ha áramkimaradás, feszültségcsúcsok vagy hibák történnek a konfigurációs fájlokban (például az mdadm.conf fájlban Linuxon) a folyamat során, a rendszer helytelenül állíthatja össze a tömböt, hiányosan hagyhatja azt, vagy egyszerűen nem ismeri fel, így a kötet használhatatlanná válik.
Az adatvesztés gyakori okai RAID tömbökben
Mindezeket figyelembe véve egyértelmű, hogy a RAID tömbök, bár nagyon hasznosak, továbbra is jelentős kockázatoknak vannak kitéve. Az adatvesztés fő valódi okai ezekben a környezetekben általában fizikai, logikai és emberi tényezők kombinációjában rejlenek.
A legnyilvánvalóbb ok egy vagy több lemez meghibásodása kopás, gyártási hibák, rezgések, hőmérséklet vagy ütések miatt. Bár a RAID-et úgy tervezték, hogy ellenálljon ezeknek a helyzeteknek, nem mindig sikerül járulékos károk nélkül : egy sérült szektorokat tartalmazó lemez magával ránthatja a szomszédját, különösen az ellenőrzési vagy újraépítési folyamatok során.
A problémák egy másik gyakori forrása az összeszerelési vagy rekonstrukciós hibák . Ha a rendszer helytelen paraméterekkel, rossz sorrendben lévő lemezekkel, az eredetitől eltérő RAID-szintekkel vagy sikertelen migráció után csatolja a tömböt, az adatok könnyen eltérhetnek egymástól. A gyakorlatban a kötet RAW formátumban jelenhet meg, formázást igényelhet, vagy inkonzisztens fájlszerkezeteket mutathat.
A szerverhibák (alaplap, firmware, hátlap, SAS/SATA vezérlő stb.) szintén jelentős szerepet játszanak. Az esetek nagyon magas százalékában, amikor a szerver hirtelen meghibásodik, a RAID tömb elérhetetlenné válik, és az adatok nem láthatók a rendszer számára, annak ellenére, hogy fizikailag még léteznek a lemezeken.
Mindehhez hozzá kell adnunk az emberi tényezőket: a konfigurációs változtatások dokumentáció nélkül, a lemezek átrendezése "tesztelés céljából", a BIOS frissítések a konfiguráció korábbi biztonsági mentése nélkül, a kötetek véletlen törlése, az operációs rendszer újratelepítése a tömb részét képező lemezekre, vagy a sérült vagy hiányos biztonsági mentések visszaállítása ugyanazon a sérült RAID-en.
Végül, vannak külső fenyegetések, mint például a zsarolóvírusok, amelyek képesek titkosítani mind az adatokat, mind a RAID tömbökön tárolt kötetek struktúráit . Ilyen esetekben a helyreállítási folyamat kétszeresen bonyolulttá válik: először a titkosítással kell foglalkozni, majd magának a RAID-nek a lehetséges belső sérülésével.
Mit NE tegyünk, ha a RAID meghibásodni kezd
Amikor egy szerver hétvégén leáll, és mindenki feszült, a leggyakoribb reakció az, hogy valaki megpróbálja menet közben megjavítani. Ez érthető, de ezek közül a jó szándékú erőfeszítések közül sok pontosan az, ami végső soron rontja az adatok minőségét.
A legveszélyesebb kísértés az automatikus újraépítés kikényszerítése a lemezek tényleges állapotának előzetes elemzése nélkül . Ha az egyik lemez sérült adatokat vagy olvashatatlan szektorokat tartalmaz, az újraépítés a felesleges adatokat másolja és keveri a jó adatokkal, amíg a kötet szerkezete teljesen meg nem semmisül.
Egy másik gyakori hiba a meghajtók véletlenszerű cseréje anélkül, hogy tudnánk, melyik sérült valójában, vagy dokumentálnánk az egyes meghajtók eredeti helyzetét . A meghajtók mozgatása a rekeszek között, keverésük különböző vezérlők között, vagy több meghajtó egyidejű cseréje terv nélkül összezavarhatja a vezérlőt, és ahhoz vezethet, hogy a RAID tömb elveszíti a konfigurációjának nyomon követését.
Az olyan eszközök, mint a CHKDSK Windows rendszeren vagy az fsck Linux rendszeren közvetlenül egy sérülés jeleit mutató RAID-köteten történő futtatása szintén nagyon kockázatos. Ezek a segédprogramok a sérült táblázatok alapján próbálják meg „javítani” a fájlszerkezetet , és a javításaik gyakran bejegyzések törlését, blokkok áthelyezését és metaadatok átírását foglalják magukban. Egy már amúgy is sérült környezetben ez több ezer fájl végleges elvesztéséhez vezethet.
Ugyanilyen rossz dolog olyan általános RAID-helyreállító szoftverekre hagyatkozni, amelyek azt ígérik, hogy „automatikusan beállítanak bármilyen RAID-et ”. Ezen eszközök közül sok felületesen működik, szabványos csíkozási, eltolási és paritásmintákat feltételezve, amelyek nem mindig teljesülnek. A helytelen használat felülírhatja a kulcsfontosságú szektorokat, vagy a lemezeket rosszabb állapotban hagyhatja, mint amilyen állapotban eredetileg telepítve voltak.
Végül a szerver ismételt újraindítása, a NAS ki- és bekapcsolása, vagy egy leromlott állapotú vagy paritáshibákkal küzdő RAID tömbön a normál munka folytatása csak további károkat okoz a lemezeken, több szektort oszt át, és terjeszti a sérülést . Minél több írási műveletet hajtanak végre az első komoly probléma után, annál kevesebb mozgástere lesz a szakembereknek.
Óvatos lépések lehetséges RAID-hiba észlelése esetén
Bármilyen komoly tünet (zaj, leromlott állapot, paritáshibák, extrém lassúság, sikertelen újraépítések stb.) esetén a legbölcsebb lépés a lassítás és a módszeres haladás . Amit most nem írsz le vagy változtatsz meg, az később menthető lehet.
Az első teendő, hogy azonnal leállítsunk minden írási műveletet a tömbön : ne másoljunk rá adatokat, ne hozzunk létre új virtuális gépeket, és ne frissítsünk tömegesen. Ha a kötet még elérhető, akkor érdemes csak olvashatóként csatlakoztatni, ha a rendszer ezt lehetővé teszi.
Ezután tanácsos a lehető legrészletesebben dokumentálni az aktuális állapotot: képernyőképeket a BIOS vagy a NAS interfészről, a lemezek listáját a fizikai helyükkel, sorozatszámukkal, a csatlakoztatott portokkal, a naplókban megjelenő pontos hibaüzenetekkel stb. Ez az információ felbecsülhetetlen értékű bármely helyreállítási laboratórium számára az eredeti forgatókönyv rekonstruálásakor.
Azokban az esetekben, amikor a RAID nem tud csatlakozni, vagy a szerver nem indul el, az egyik technikai megoldás a lemezek eltávolítása és egy másik számítógéphez csatlakoztatása, hogy szektoronkénti, hitelesítő másolatokat készítsen az egyes meghajtókról . Ezek a csak olvasható módban készült másolatok lehetővé teszik a klónok utólagos kezelését az eredeti lemezek további károsítása nélkül.
Fejlett tudással, speciális eszközökkel és egy ellenőrzött környezetben megkísérelhető a tömb logikus rekonstrukciója ezekből a klónokból, levezetve a lemezek sorrendjét, a csíkok méretét, a paritásmintákat, az eltolásokat és a metaadatokat . Ez azonban egy kényes visszafejtési feladat: a véletlenszerű paraméterváltozásokkal járó próbálkozások és hibák az adatok félreértelmezéséhez vezethetnek.
A legtöbb vállalkozás és kritikus környezet számára a legbiztonságosabb megoldás az, ha a lehető leghamarabb felveszik a kapcsolatot egy professzionális RAID-helyreállítási szolgáltatással , és követik a kezdeti utasításaikat. A siker aránya általában szorosan összefügg a laboratóriumba jutás előtti sikertelen kísérletek számával.
Hogyan működnek a professzionális RAID-helyreállítási laboratóriumok
A RAID környezetekre szakosodott professzionális adatmentési szolgáltatások a hardverek és fájlrendszerek mélyreható ismeretét saját fejlesztésű eszközökkel és szigorú eljárásokkal ötvözik. Általánosságban elmondható, hogy ezt teszik, amikor meghibásodott RAID-del kapcsolatos esetet kapnak.
Az első lépés minden egyes merevlemez egyedi diagnosztikájának elvégzése : ellenőrzik a meghajtók mechanikai, elektronikus és logikai állapotát, azonosítják a hibás szektorokat, áttekintik a SMART-táblákat, és felmérik a rövid távú meghibásodás kockázatát. Ha bármelyik meghajtó fizikai sérülést szenvedett, akkor a tisztatéri kezelésük elsőbbséget élvez.
Ezután az összes érintett lemezről forenzikus klónokat hoznak létre . Az eredeti lemezek szerkesztése helyett szektoronkénti másolatot készítenek olyan eszközök segítségével, amelyek lehetővé teszik a súlyosan sérült szektorok kihagyását vagy a biztonságos mintákkal való újrapróbálkozást. A cél az eredeti állapot megőrzése arra az esetre, ha szükségessé válna a folyamat egy korábbi lépéséhez való visszatérés.
Miután a klónok elkészültek, manuálisan logikailag rekonstruálják a RAID-et : azonosítják a szintet (0, 1, 5, 6, 10 stb.), a lemezsorrendet, a csíkméretet, az eltolásokat, a paritásalgoritmusokat és az eredeti vezérlő egyéb jellemzőit. A kötet gyakran rekonstruálható anélkül is, hogy ugyanaz a vezérlő vagy NAS lenne, amely létrehozta.
Miután a rekonstruált virtuális kötet koherensnek tűnik, a fájlrendszert szükség esetén javítják: NTFS, ReFS, ext4, XFS, Btrfs, ZFS, VMFS és mások. Ez a munka hasonló egy sebész munkájához: a struktúrákat korrigálják, az inode táblákat, az MFT-ket, a szuperblokkokat vagy a naplókat újraépítik, mindig a minimális változtatásra törekedve.
Végül az adatokat kinyerik és szisztematikusan validálják. Ellenőrzik a fő adatbázisok, virtuális gépek és kritikus mappák konzisztenciáját, ellenőrzik a fájlok helyes megnyitását, és az adatokat új, elkülönített adathordozón , például külső merevlemezen vagy új NAS-on szállítják, hogy az ügyfél áttekinthesse a helyreállítást, mielőtt elfogadná.
Különösen összetett forgatókönyvekben, például zsarolóvírusok által érintett RAID-ek, korábbi sikertelen újraépítések vagy már sérült tömbökön belüli virtuális kötetek esetén a dekódolási technikákat, a forenzikus elemzést és a RAID-rekonstrukciót kombinálják, de mindig ugyanazon szabály szerint: ne érintse meg az eredeti fájlokat a feltétlenül szükségesnél többször.
Végső soron a RAID rendszerek hatékony eszközök az adatok elérhetőségének javítására, de továbbra is sebezhetőek a fizikai, logikai és emberi hibákkal szemben. A gyengeségeik megértése, a korai figyelmeztető jelek azonosítása és mindenekelőtt a meggondolatlan döntések elkerülése meghibásodás esetén az, ami igazán megkülönbözteti a kisebb ijesztő helyzeteket az adatkatasztrófától.
