Sziasztok!
Adott egy 4 lemezes RAID 10-es tömb, mdadm-el összerakva, amiből kiesett az egyik lemez már isten tudja mikor, nekem már csak akkor szóltak amikor a RAID1 párja is elkezdett vacakolni és RO-ban került a rajta lévő file rendszer. Szóval első körben megpróbáltam ismét teljessé tenni a tömböt egy új lemez hozzáadásával. A sync le is ment mdadm szreint minden block szinkronizálva lett de mégis 99%-on állt folyamat a dolog, dmesg szerint is lement a szinkronizálás ellenben írt egy hibát a párjára hogy valamilyen írási művelet nem sikerült. Ránéztem smartctl-el a kérdéses lemezre de nem engedte olvasni a SMART-ot róla, hibával elszállt. Úgy határoztam hogy próbáljuk meg akkor a teljes adatállományt átmásolni a kötetről, ha sikerül, és inkább építsünk egy új tömböt. Ellenben másolás közben megata magát a vacakoló lemez.
Így most van egy olyan RAID 10-es tömböm aminek csak az egyik RAID1-es kötete van meg mindkét lemezzel a másikból van 1 olyan lemezem amire elviekben lement a sync. na már most ha megpróbálom ebből a 3 lemezből összeépíteni a tömböt akkor azt mondja hogy van egy aktív párom ami eddig is volt, a másik lemezre amire elviekben lement a sync továbbra is azt írja hogy replacing, pedig dmesgben írta hogy lement a sync. Van esélyem valahogy megerőszakolni és azt is sync statusba tenni? Veszteni valóm nincs ha nem sikerül elindítanom ezzel a lemezzel akkor úgyis bukü az adat ami rajta volt, így nem veszthetek semmit.
Mielőtt bárki elkezdené, hogy miért nincs mentés az adatokról akkor nem kéne ezzel vacakolni. Nem az enyém a gép, csak megkerestek amikor már nem bírták írni a file rendszert. Próbálok nekik segíteni hátha sikerül valahogy feltámasztani, de itt nekem is megállt a tudásom, nem volt még sosem komolyabb problémá linuxos software RAID-el.
Tippeket, ötleteket előre is köszönöm!
Hozzászólások
Mielott kicsereld a diszket, erdemes azt --remove-val kiszedni. Ekkor tudatja az mdadm a tobbi diszkkel hogy az az adott /dev/sdx(y) device mar nem resze a tombnek. Ha a metaadatok inkonzisztensek akkor csinal(hat) ilyesmit emlekeim szerint.
De meg mielott barmi mast csinalsz, szerintem erdemes a teljes rendszerrol egy mentest, image szinten csinalni. Sajna az `mdadm` sem mindenhato, voltak olyan eseteim hogy megnyugtato(bb) volt keresni egy ures, nagy teruletet, egyenkent lementeni oda az image-ket, es akkor ugy jatszani, "hatha" alapokon.
Úgy nézett ki a dolog amikor hozzám került hogy mdstats szerint már csak 3 lemez volt benne így azt már remove-olni nem tudtad belőle. Alapvetően én is removeolni szoktam ha cserélek egy lemezt egy adott kötetben de mivel ez már nem volt tagja így itt nem removeoltam mert nem volt mit, gép sem látta már. Így volt ugye 3 lemez, emellé raktam be egy újat 4.-nek amire le is ment sync dmesg szerint de folyamat 99%-on állt az mdstats, emellé állandóan estek be az újabb bejegyzések a dmesgbe miszerint sikeresen lement az md2 syncje majd alatt rögtön egy hiba hogy super_written gets error=10. Gondolom emiatt állt folyamat 99%-on a sync.
Szerzel két nagy diszket, ddrescue image mind a _négy_ diszkről az egyik újra.
Után ezekről csinálsz egy másolatot (cp) a másik nagy diszkre.
Ezekután a második nagy diszken levő adattal elkezdhetsz mókolni, összeheggeszted az adatokat. Ha nem sikerül akkor az első kópiát elviszed egy szagértőhöz aki sok pénzért megheggeszti.
Ha a RAID1-es fele ép, akkor mennie kell, tudnod kell róla olvasni, sőt írni is.
Ha nem megy, akkor nem ép, vagy azok a lemezek is szarok. A smart nem szentírtás.
Viszont mivel minden diszk szar, azt érdemes amit írtak, hogy dd-zd le mindet, és azzal játssz, egyrészt az eredeti akkor marad ahogy van, másrészt a szar diszkeknek minden felpörgés, minden üzemóra, minden seek és olvasás kínlódás egy szög a koporsójába.
"Sose a gép a hülye."
Úgy értettem a dolgot hogy a RAID10 két darab RAID1-es kötet közötti stripe. Ennek a kettő RAID1-es kötetnek az egyik teljesen ép a másikból ugye az egyik diszk régen kipottyant a másik most kezdett el vacakolni de még benne volt a kötetben. ekkor raktam be egy 4. lemezt amire elvileg lement a sync de folyamat folyton újraindul. dmesgből is látszik hogy sync complete majd alatta rögtön hogy super_written gets error=10. És ezt percenként tolja dmesgbe.
Mivel dmesg szerint complete a sync csak a RAID1 kötet másik felén nem bírta updatelni a supert így adnék egy esélyt hogy frissen lesyncelt példányt berakni mint sync statusban lévő RAID1-es kötet fele és a másik ép RAID1-es résszel ismét összeállítani valahogy a RAID10-et. Csak ugye ha simán összerakom a 3 müködő lemezből akkor a friss lemezre amire elvileg lement a sync, hogy syncing. Így ugye RAID10nek csak az egyik RAID1-es kötete tud aktív lenni, mivel stripe így kellene legalább egy lemez a másik oldalra is külön csak minden második chunk lesz meg....
"Úgy értettem a dolgot hogy a RAID10 két darab RAID1-es kötet közötti stripe."
Igen valid, igazad van, ezt nekem mindig kétszer végig kell gondolni hogy a raid10 vagy a raid51 mit is jelent valójában....
Szóval akkor nagyon egyszerű a válasz, nincs mit menteni, hiszen az adatok fele nincs meg.
"Sose a gép a hülye."
Barbár ötlet, de azt írod: veszíteni valód nincs, alapállás, hogy sikáltak az adatoknak, ha bármit is sikerül visszahozni, az már nyereség.
Szóval az assemble parancsnak vannak olyan kulcsszavai, mint --run - indulj el akkor is, ha van kiesett lemez -, --force - rakd össze akkor is, ha egyébként nem kerek a dolog a fejléc szerint. Tegyük hozzá: nem csak az FS lehet RO, hanem raid tömb is. Ahhoz elég, hogy adatot menekíts róla. (Persze ha van hely és idő, akkor hasznos lehet egy mentés az aktuális állapotról és akkor ha valamit sikerül elnyesni, akkor még van kályha, ahova vissza lehet lépni és újra kezdeni az adatmenést.)
Igazából annak alapján, hogy a RAID10 tömb egyik RAID1-es tömbje hibátlan, a másiknál pedig az új diszk 99%-ra szinkronizált, elméletileg az adatok 99.5%-a megvan.
Nos konkrétan a 2 eredeti ép lemez és az 99%-os syncelt lemez event countja ugyanannyi, utoljára pont ugyanakkor voltak updatelve is. Csupán a különbség annyi hogy annak a lemeznek a statusa amire lement a sync elviekben nem változott meg device roleja active-ra hanem replacing maradt. Így nem szeretné elindítani az mdadm a tömböt sehogy sem mondván hogy az egyik RAID1-ből csak 1db replacing lemezt lát. Ezt kéne valahogy megkerülni és rákényszeríteni hogy legyen aktív bármi is történik.
Ha találok rá megoldást menetközben akkor megírom ide, hátha más is belefut.
Lehet kísérletezni, de mindenképp másolatokkal! Maradjon eredeti, olvasható, érintetlen darab.
Pl. meg lehet nézni hogy hol tárolja az mdadm a tömb állapotát és infókat, és kézzel hex editorral átírni "OK"-ra.
És természetesen minden nem működő vagy félresikerült próbálkozás után újra másolat az eredetiről, és arról próbálni újra.
"Sose a gép a hülye."
És ha a másik rossz disket is kivennéd, és a helyett is tennél egy újat?
Ha a RAID1 érintetlen, akkor elvileg arról tud a két új, szűz diskre egy másolatot csinálni.
Az induló állapot RAID10. Ez két RAID1, ami fölött van egy RAID0. Attól, hogy az egyik RAID1 hibátlan két diszkkel, a másik RAID1 döglött egy halott és egy 99%-ig szinkronizált diszkkel. Itt lehet csereberélni bármit, de nincs miről szinkronizálni: az ép RAID1-et minek, a döglött RAID1-et meg hogyan?
Sikerült megoldani a poblémát, jól felparaméterezett mdadm create segítségével újra létrehoztam a tömböt.
mdadm --create /dev/md0 --level=10 --chunk=512K --metadata=1.2 --data-offset=262144s --raid-devices=4 /dev/sdb1 /dev/sdd missing /dev/sdf1
data offset, chunk size, metadata verziót kinéztem a meglévő 3 lemezből amiből egynek ugye replacing volt a device roleja. Utána volt egy masszív file rendszer hibám, de fsck úgy néz ki kikalapált mindent. Mivel pontosan ugyanannyi volt az event count és a update timestamp is mindhárom lemez csak a device role nem stimmelt így 99% hogy minden adat sikeresen visszajött.
A tombben vegyesen hasznaltal particiokat es teljes diszkeket?
Vagy ezek a device nevek mar a masolatok?