Egy jó ideje már foglalkozok RAID-del. A komolyabb hardveres megoldásoktól kezdve, az olcsó FakeRAID borzalmakon át a Linuxos és Windowsos szoftraidekkel bezárólag elég sok mindennel kerültem már közelebbi kapcsolatba. Azonban álmomban sem mertem volna gondolni, hogy egyszer eljutok oda, hogy hexa editorral piszkáljam a lemezeimet. De ne siessünk ennyire előre.

Bevezető

Úgy egy hete ünnepeltük a névnapomat, ahol az ajándéktasakban a bor mellett ott mosolygott egy 1 TB-os Toshiba merevlemez is. Tárhelyből sosem elég, nemde? Mivel ezzel a lemezzel immár három tagúra bővült az egy terabyte méretű lemezeim száma, és a legöregebbnek már fura hangjai vannak, a legjobbnak láttam létrehozni egy RAID 5 tömböt. Így van 2 TB összefüggő helyem, és ha kiesik valamelyik vasreszelék-pörgető, akkor sincs adatvesztés.

Felépítés

Nincs is itt semmi látnivaló, gondolhatnánk, hiszen rendszer-üzemeltetőként rutinfeladatnak kell lennie egy általános célú RAID 5 felépítése. Nincs is vele gondom, minden ment flottul. Azonban elkövettem egy hibát: mivel szinte mindig tiszta (vadiúj vagy badblocks utáni) lemezzel dolgozok, így az itthoni lemezeknek még az elejüket sem írtam felül nullákkal vagy valamivel a /dev/random-ból. Ez később fontos lesz. Az mdadm persze szólt, hogy figyu, ez van rajta, de ha rátelepszek érvényét és értelmét veszti, ahogy a rajta lévő adatok is. Mondtam oké, csináld csak, már kiköltöztem ezekről a lemezekről.

Első bökkenő

Pillanatok alatt kész is lett. A Linux RAID implementációjában az a jó, hogy RAID 5 építése közben a tömb már használható, így „visszaköltözhettem” a helyemre. Ez mindenféle adatokat, mentéseket, ezt-azt takar, ahogy a címben is említettem, olyan 1,5 TB-nyit összesen. De „ez a világ már nagyon szűk nekem”, így ezeket a mentéseket csak elég szétszórva tudom tárolni, egyben csak itt vannak meg, így nem válnék meg szívesen tőlük, még addig sem, amíg visszavadászom őket.

Most a változatosság kedvéért cfdisk helyett GParteddel szétszedtem két részre a 2 TB-os tömböt: Az első a „Storage” ~1,9 TB mérettel, ide kerülnek a fentebb emlegetett anyagok. Emellett készült egy 100 GB-os „Portage” címkével ellátott, amin btrfs teljesít szolgálatot. Itt olyan adatok vannak, amelyek mehetnek a levesbe, ha bugzik az FS: Dropbox, Insync és Gentoo portage fa néhány overlay-jel.

A GParted indításkor érvénytelen GPT partíció szignatúrára – ugye van a vízi túra, helyi túra és szigna túra :) – panaszkodott. Ezt azonban neki már nem szabadott volna látnia, szerintem. Így fogtam magam és a létrejött RAID tömbön létrehoztam egy új, GPT partíciós táblát, majd a fentebb említett két partíciót. Fontolgattam az LVM-et is, de csak +1 réteg, itthon nincs szükségem az extráira. A kevesebb több. Innen minden zavartalanul ment, írtam is az mdadm.conf-ba a konfigurációt, nehogy a következő rebootnál meglepődjek.

Újraindítás

Egy kicsit elhúzódott a RAID első újraindítása. Részben a hosszú szinkronizációs idő miatt, részben pedig mivel inkább altatom a gépet. De péntek délután végre, majd egy hét után megtörtént. Ez sem azért, mert gond lett volna, hanem egyszerűen bütykölhetnékem támadt, így indítottam egy Gentoo-t. Ilyenkor még csak nem is sejtettem, hogy igencsak busásan megkapom az áhított bütykölésemet.

A Gentoo-nak természetesen fogalma sem volt róla, hogy mit kezdjen a RAID tömbbel, hiszen nem volt a kernelbe beleforgatva a RAID támogatás (sem). Kernel fordítás után eszembe jutott, hogy meg kellene már csinálni, hogy az Ubuntu Grub2-je töltse be a Gentoo-hoz tartozó Grub2-t, de ehhez kell egy rövid script a /etc/grub.d/-be de még az Ubuntuból. Az indítás után pislogtam mint hal a szatyorban, mert panaszkodik a Dropbox, hogy ő bizony nem leli a könyvtárát. Nautilusból utánanézve, én sem leltem. Kezdett elkapni a frász, de ránéztem még GPartedből és Lemezek segédprogramból (gnome-disks) is, és a helyzet olyan fura volt, hogy jól le is döbbentem.

A régi lemezeken a régi partíciós tábla köszönt vissza, ugyanazokkal a fájlrendszerekkel. Na ne, persze, gondoltam magamban, az elmúlt egy hetet meg álmodtam, mi? De nem álmodtam, mert a Toshiba lemez itt van és vígan hirdeti magáról, hogy ő „Linux RAID tag (1.2 verzió)”, bizony ám.

Nincs kettő, négy nélkül

Amiben biztos voltam, az az, hogy nem férhetett se egy darab lemezre, se a memóriába 1,5 TB-nyi adat, szóval ott kell lennie a lemezeken. Lehet, csak gond volt rendszerindítás közben és valójában minden rendben van. Sajnos az mdadm nem így gondolta: mdadm: No md superblock detected on /dev/sde. Fantasztikus, megpróbáltam ugyanezt, csak a RAID másik lábán, de ő is ezzel fogadott. Néztem a SMART-ot, egyik lemeznél sem változtak az értékek, minden rendben van. Akkor jónak kell lenniük, mi a fene van?

Viszonylag hosszabb keresgélés után sem találtam érdemi megoldást: Nagyon úgy tűnt, hogy ezt megszívtam, az utolsó lehetőség a lemezek nullázása, majd a RAID tömb újbóli létrehozása és a reménykedés abban, hogy nem fordul elő még egyszer. Ez elfogadhatatlan, kellenek az adataim és szentül hiszem, hogy megvannak, csak „némi” rábeszélésre van szüksége.

Magad uram, ha szolgád nincs

Úgy nézett ki a helyzet, hogy a jól bevált eszközökkel nem tudok segíteni a dolgokon. Van három lemezem, elvileg szabályos RAID 5-be szervezve, szinkronizálva. Ezek közül a legelső egy teljesen friss lemez, a második, illetve a harmadik viszont régi lemezek. Szokatlan probléma, szokatlan megoldásért kiált, így hexa editor után néztem. Olyan kellett, ami meg tudja nyitni a blokkeszközöket is, tehát a Bless kilőve. Tovább kutatva találtam rá a ht-ra, ami multiplatform és sokkal többet tud annál, mint amire nekem szükségem van.

Ha azt mondanám, hogy konkrétan tudtam, mit keresek, akkor hazudnék. Jelet kerestem arra, hogy megvan még minden adatom, a tömb egyben van, csak valami félre csúszott. Az első néhány byte meg is mondta nekem, hogy bizony itt a régi GPT partíciós tábla. Azaz tudtam, hogy ezt olvassa be a rendszer, ezért látom a partíciókat. Következő dolgom volt a RAID szuperblokkok felkutatása. Ez a tiszta lemeznél meg is volt, a lényegi rész a lemez 4096 és 4359 byte-ja között van. Viszont se ugyanebben a pozícióban, se máshol nem találtam a többi lemezen a szuperblokkokat. Nos igen, azt nehéz lett volna az mdadm-nek megtalálnia, ami nem is létezik.

Szinte biztos a rossz végkifejlet művelet indul!

A semminél a semmi nem kevesebb, így ha elcseszek valamit, akkor sem lesz nagyobb adatvesztésem, de ha összejön, sokat nyerhetek vele. Ha neked is ez a bajod, vagy csak érdekel a hogyan, folytassuk együtt! A nulladik lépésben, vedd elő a Linux RAID szuperblokk formátum dokumentációját, ez alapján haladtam én is: https://raid.wiki.kernel.org/index.php/RAID_superblock_format

Eszköz UUID felírása

Mielőtt hozzákezdenél, szükség van az eszközöd jelenlegi UUID-jére, vagy bármilyen más UUID-re, a lényeg, hogy kelleni fog egy egyedi azonosító.

Szuperblokk másolás

Ha nincs szuperblokk, hozzuk létre. Kézzel, azaz egészen pontosan félkézzel: másoljuk át az ép lemezről a RAID szuperblokkot. Bár maga a szuperblokk mindössze 256 byte méretű, nekem ennél érzésre többre volt szükségem. Ez annyit jelentett, hogy szuperblokk és a mögötte lévő nem nulla byte-okat is átmásoltam, esetemben a lemezről a 4096 és 4607 közti byte-ok kellenek.

Ezt a 4607 byte-ot a dd készséggel átmásolja nekünk: dd if=/dev/ép of=/dev/cél bs=1 count=4607. Tádá, kész is a szuperblokk alapja.

Eszköz UUID beállítása

Ez egy 16 byte méretű érték. Az első byte 4264. az utolsó pedig a 4279. Ide jöhet akár az eszköz előző UUID-ja. Maga az UUID egy-az-egyben mehet be, ugyanis ez egy hexadecimális érték.

Eszköz helyének beállítása

A dolgok egy kicsit kacifántosabbak innentől. Először is, meg kell adni a lemez helyét, hogy melyik „slot” az övé. Ehhez kell egy 16 bites, előjel nélküli egész szám, amit a 4256 és 4259 byte értékei reprezentálnak. Mivel ez lesz a második lemez, ezért a 4256-os byte értéke 01 lett, a többiek pedig nullák. Végül a 4354. és 4355. byte-ok értékei képviselik az eszköz helyét a tömbben, ezt is állítsd be, ami nálam 01 00, azaz a RAID kötet második lemeze.

Ellenőrzőösszeg „kijavítása”

Mivel biztos voltam benne, hogy a RAID tömbbel minden rendben van, tiszta leállítás történt és semminek sem szabad korrumpálódnia, így bár némi keserű gányolás ízzel a számban, de manipuláltam a tárolt ellenőrzőösszeget. Ez a 4312. byte-nál kezdődik és a 4315.-ben ér véget. Futtass le egy mdadm -E /dev/eszköz parancsot. Kiírja, hogy a jelenlegi ellenőrzőösszeg valamennyi, de ő egy másikat várt. A fenti byte-ok a várt értéket tárolják, szóval át kell írnunk, hogy a jelenlegit várja. Fontos, hogy figyelj, mert ellenőrzőösszeg fordított sorrendben tárolódik: azaz az általad elsőként, az mdadm kimenetéből olvasott érték a 4315. byte, a második a 4314. és így tovább. Könnyű elnézni. A mdadm -E /dev/eszköz paranccsal ellenőrizd, hogy minden oké-e.

Tedd, vagy ne tedd. De ne próbáld!

Eljött az ideje a tesztnek, elvileg minden oké. A szükséges parancs így néz ki:

root@Narada:~# mdadm -v --assemble /dev/md0 /dev/sdc /dev/sdd  --run –force
mdadm: looking for devices for /dev/md0
mdadm: /dev/sdc is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sdd is identified as a member of /dev/md0, slot 1.
mdadm: added /dev/sdd to /dev/md0 as 1
mdadm: no uptodate device for slot 4 of /dev/md0
mdadm: added /dev/sdc to /dev/md0 as 0
mdadm: /dev/md0 has been started with 2 drives (out of 3).

Ha hasonló kimenetet kapsz, az biztató, próbáld meg csatolni a fájlrendszered! Elvileg mindennek mennie kell! :)
Hogy miért nem csináltam meg a második felét is? Leginkább azért, mert ez gányolás, no meg ideje korrigálnom a régi hibámat és mindent felülírni nullákkal. Utána adott lemezt hozzáadni a RAID-hez és megvárni, amíg szinkronizál. Majd a másik lemezt kivenni a tömbből, felülírni nullákkal és visszatenni. Biztos, ami biztos alapon.

Hibalövészet

mdadm: failed to add /dev/sdd to /dev/md0: Invalid argument
Valószínűleg elrontottad az ellenőrzőösszeg manipulálását. A mdadm -E /dev/eszköz paranccsal ellenőrizd, hogy minden oké-e.

mdadm: /dev/sdd is identified as a member of /dev/md0, slot -1.
vagy
mdadm: /dev/md0 assembled from 1 drive and -1 spares - not enough to start the array.
Nem jó slotba tetted a lemezt, vagy olyan adatot írtál be, amit nem tud értelmezni az mdadm esetleg a lemez relatív helyét a tömbben rosszul adtad meg.

Soha ne hagyjon el a remény

Utoljára, de messze nem utolsósorban, fontos megemlítenem, hogy bízz néha egy kicsit. Van, mikor elég reménytelen a helyzet, de mindig van kiút. Mire odáig elértem, hogy a 1,5 TB-ot tartalmazó partícióm csatolható lehessen, minden ötlettel, kereséssel és ilyesmivel együtt legalább 10 óra eltelt, ráadásul igen nehezen vettem rá magam a szuperblokk kézi létrehozására, mert féltem, hogy valamit eltúrok. Feleslegesen mellesleg, mert ha igen, akkor se lett volna nagyobb gond a fennállónál.