REFERENCIÁK - Raid tömbök
<<Vissza a referenciák főoldalára
Mentés
egy szétesett RAID tömbről (HP smartarray 8x SAS) 8 db SAS HP (Seagate) HDD
Megrendelőnk, a Pécsi Direkt Kft (az Alexandra könyvkiadó szerződött IT partnere) már nem az első adatmentési munkával fordult hozzánk.
Jelen esetben egy 8 HDD-ből álló
SAS csatolós RAID5 tömböt hozott be, amit a RAID vezérlő kártya nem tudott összeállítani, mivel 2 db eszköz is off-sync állapotban volt a 8-ból.
Ennek
az előzménye egy csúnya belassulásos-fagyásos szerver jelenség volt, aminek kapcsán SQL adatbázisok maradtak lezáratlanul, valamint az operációs rendszer FS cache-ében is maradtak kiíratlan adatok.
A bevizsgálás során megállapítottuk, hogy a probléma kettős.
Először az egyik HDD észlelt READ CHANNEL problémákat, amit be is jegyzett a SMART táblájába, majd a SMART állapota beállt FAILED-re.
Ezért a kártya kitiltotta a tömbből és a maradék 7 HDD-ről járt a renszer egy rövid ideig.
Viszont, ha egy RAID5 tömb DEGRADED állapotban van (hiányzik belőle egy elem), akkor jobban terheli a maradék hdd-ket is.
Ennek a megemelkedett terhelésnek a hatása egy emelkedett hőmérséklet lett.
A hőmérséklet emelkedése miatt pedig egy másik HDD elektronikája is meghibásodott és egyszerűen kifagyott rajta a mikroprocesszor. (MCU)
Mivel az MCU fagyott csak ki, így a fizikai SAS layer, a PHY még aktív volt, ezért a vezérlő kártya nem tudta, hogy miért nem tud kommunikálni a HDD-vel és miért nem érkezik sem hibaüzenet, sem válasz az eszköz felől, ezért várt.....
A várásnak az lett a következménye, hogy a vezérlőkártya maga is kifagyott.
A következő indításnál persze mind a 8 HDD ismét bejelentkezett (csak az egyik SMART FAILED állapottal), de a kártya nem tudta összeállítani újra a tömböt, mivel 2 HDD off-sync állapotban volt.
Szerencsére ekkor a megrendelőnk azonnal szakszerű segítségért fordult.
A labor körülmények között mind a 8 HDD-ről tudtunk teljes értékű image képet készíteni, de a HP Smartarray
kártya nem szabványos RAID5 szerkezete, valamint az off-sync hdd-k frisseségi adatainak a hiányában az adatmentés nem volt teljesen egyszerű.
Jó pár órát igénybevettek az egymást követő RAID szimulációs eljárások, aminek az egyetlen ellenőrzési eljárása a tömbön található 540GB-s sérült (dirty) XFS fájlrendszer elemzése.
A végén a legjobb állapot kiválasztásával kijavítottuk a fájlrendszert, majd visszatöltöttük a hibás HDD-k kicserélése után újra összeállított RAID tömbre.
A végeredmény pár napos munka után 98-99.9% körüli.
Sajnos a gép memóriájában rekedt kiíratlan adatok maradandó károsodásokat okoztak az adatbázisokban, amiket csak részlegesen lehetett kijavítani.
A megrendelő kérésére a helyreállított szerver gépet visszaszállítottuk a Pécsi telephelyére.
Mivel a megrendelőnk már kicsit unalmasnak találta, hogy újra és újra a méregdrága márkás szervereiről adatmentésért fizetnie kell, ezért úgy döntött, hogy kér ajánlatot cégünktől egy 60TB-os Gladiátor alapú Backup-restore rendszerre, hogy többet ne járhasson így.
2009. 09. 02. |
|
|
Adatmentés RAID5 tömbről (5x36GiB SCSI)
Ezt
a HDD-t a Gyöngyösi Polgármesteri Hivatal hozta be adatmentésre.
Egy időszakos biztonsági másolat közben következett be az az esemény, hogy a szerver váratlanul lefagyott. (kékhalál)
Az újraindítás során azt tapasztalták, hogy
a RAID adapter az 5 hdd-ből 3-at off-sync-nek jelölt és nem engedett semmit sem tenni, csak a tömb darabjait törölni, és újrainicializálással ismét létrehozni a tömböt, ami persze teljes adatvesztéssel is járt volna.
Az ottani informatikus mindent bevetve megpróbálta a hibát orvosolni, segítségül hívta még a HP magyarország képviseletét is, de végül, amikor már 5 napja több száz ember nem dolgozott a Polgármesteri hivatalban, úgy döntöttek, hogy szakemberhez fordulnak...
Akkor már igen égető volt a probléma, mert ugye nagyon le voltak maradva a munkákkal, ezért sürgősségiként igényelték a szolgáltatásunkat.
A RAID szimulációt FS konzisztencia ellenőrzés követet, ami után FS rekonstrukcióra is szükséges volt.
Az eredményt másnap, kb 20 óra elteltével már át is adtuk az informatikusnak, aki nem is tudott benne hibát találni végül.
A sikeresség
közel 100%-os lett.
Mivel a bevizsgálás során megállapítottuk azt is, hogy a régi SCSI hdd-k nem valami fényes állapotban vannak, így javaslatot tettünk az eszközök cseréjére is.
Az informatikus ezt meg is értette és el is fogadta, ezért már az új hdd-ken adtuk át a lementett adatokat másnap.
2008. 12.10. |
|
|
Adatmentés RAID5 tömbről (3x36GiB SCSI)
Ezt
a RAID-tömböt a Nagykanizsai Thúry György Kereskedelmi Vendéglátó és Idegenforgalmi Szakképző Iskola hozta be adatmentésre.
Az ügyfél elmondta, hogy a számítógép, ami az iskola egyik fő kiszolgálója volt, elkezdett belassulni, és újraindították emiatt.
Az eredeti hibája egy bad sectoros SCSI 36 Gigabyte-os hdd volt, amit az informatikus meg is próbált kicserélni.
A csere után a RAID kártya egy másik hdd-t is hibásnak mutatott.
Ekkor megpróbálták visszatenni az eredeti hibás hdd-t, de ez a művelet sem vezetett eredményre, a RAID kártya innentől már nem fogadta vissza a már eltávolított hdd-ket.
Szerencsére nem próbálkoztak vele tovább, hanem még időben segítséget kerestek, és meg is találták.
Az adatmentést "degraded" RAID5
szimulációval valósítottuk meg 100%-os sikerességgel.
2008. 12.02. |
|
|
Mentés
RAID tömbről (Promise Ultratrack RM8000)
Ezt
a RAID tömböt a Néprajzi Múzeum hozta be adatmentésre.
A tömb egy UW SCSI csatlakozóval szerelt RACK-ben volt 6db Seagate 80GB-s IDE csatolós HDD-kből összeállítva.
Az eredeti hibája az volt, hogy megjelent, mint eszköz, de a windows nem látta rajta a köteteket!
Az előzetes bevizsgálás során megállapítottuk, hogy a windows-os fájlrendszer adminisztrációs bejegyzései megsérültek.
Az adatmentést FS rekonstrukcióval végeztük el.
A végeredmény 100%-os lett.
Az adatmentés után javaslatot tettünk a régi HDD-k cseréjére, mivel azok már nem voltak tökéletes állapotúak, ezt az ügyfelünk el is fogadta.
2008. 10.28. |
 |
|
RAID5 Tömb rekonstrukció 5db SCSI hdd-ből
A Core Systems Informatikai KFT megbízásából 24 óra alatt kellett ezt a RAID5 tömböt helyreállítani, mert egy váratlan áramszünet 2 hdd-t egyszerre ejtett ki a raid szinkronjából.
A hardveres raid egy adaptec kártya segítségével volt létrehozva, ami az aszinkron tömb észlelésekor a hozzáférést letiltotta, nem engedett még Readonly módban sem hozzáférni sem a tömbhöz, sem pedig a lemezekhez egyenként.
Semmilyen lehetőséget nem engedett, csak az összes eszköz törlését és a raid tömb ismételt összeállítását újraformázással.
A kártyáról való leválasztás után raid rekonstruckió következett, amely segítségével
image másolatokat képeztünk a kártya headerjeit eltávolítva a lemezekről, majd Readonly módban logikai úton összeállítottuk a 'dirty' tömböt. A tömb összeállítása után egy új adathordozóra lett egy másolat készítve, amin elvégeztük a Windows NT filerendszer integritásának helyreállítását.
Az ügyfél péntek este adta le a munkát, vasárnap reggel már át is adtuk a >600GB-os ép tömböt.
2008. 04. 11. |
 |
|
RAID5
- rekonstrukció (3x160GB)
Ezt
a RAID5 tömböt a ügyfelünk jó ideig úgy használta, hogy nem vették észre,
hogy az egyik HDD hibás, és a RAID kártya már kitiltotta.
Sajnos idő közben a második HDD is kezdett meghibásodni, bizonytalanul
olvasni, és akkor vették észre először a problémát, amikor a windows
már kifagyott tőle.
Ezek után megpróbálták maguktól lementeni az adatokat a 3 ból 2 HDD
segítségével, mely sikertelennek bizonyult, mivel már a maradék 2-ből
is egy HDD seek hibákat dobott vissza.
Mi első lépésként lementettük az egyetlen hibátlanul működő HDD-t,
majd megbontás után ebből áthelyezve a fej szerelvényt a másik (seek-hibás)
HDD-be, lementettük azt is.
Ezek után következett be a módosított Linux kernellel való RAID rekonstrukció,
majd a windows alatti NTFS javítás.
Az végeredmény csaknem 100%-os lett.
2007. 06. 08. |
 |
|
RAID5
- rekonstrukció (4x120GB)
Ezt
a RAID5 tömböt a Webhotel Bt. hozta hozzánk, mert egy rövid ideje
a 4 hdd-ből csak 3 üzemelt és a végén a maradék 3-ból is megsérült
az egyik.
Ennek hatására a RAID kártya letiltotta az írási folyamatokat, ami
miatt további adatveszteség következett be.
A mentés során a raid kártyáról való leválasztást szoftveres raid
rekonstrukció követett, amit egy speciális, módosított Linux kernel segítségével
tudtunk megvalósítani, hogy a fizikailag hibás részeket biztonságosan
ki tudjuk kerülni az adathordozó további károsodása elkerülésével.
Ezek után EXT3-as FS javítás következett.
A mentés sajnos nem volt 100%-os a körülmények miatt, de a végeredmény
így is kielégítő lett.
2007. 01. 03. |
 |
|
|
