Ok, iată ce am făcut. Fie ca acesta să ajute următoarea persoană.
Constatarea faptelor
În primul rând, am atașat toate discurile la un HBA. GNU/Linux a încercat să asambleze
raid, dar într-adevăr a găsit (cel puțin) două volume de raid (și puțin în plus). eu
apoi a făcut o copie de rezervă a primilor 32 și a ultimilor 32 MB din fiecare disc, indexate de
WWID/WWN-ul lor.
Am descărcat apoi specificația SNIA DDF
(https://www.snia.org/tech_activities/standards/curr_standards/ddf)
pentru că știam că megaraid/dell l-a implementat (parțial) (ddf
magia blocului de ancorare nu este de11de11 întâmplător :), și apoi a scris un foarte
script urât pentru a decoda datele și a le da sens.
Acest lucru mi-a arătat că matricea a fost, de fapt, împărțită în trei diferite
configurații, una care includea un disc, alta care includea asta
disc și încă 4, și încă unul care conținea restul de 2 discuri.
Scriptul în sine nu este foarte util fără a înțelege ce faceți, așa că nu l-am inclus aici.
În cele din urmă, acest lucru mi-a permis să obțin ordinea originală corectă a
discurile. Sugestie: după crearea unei matrice, notați ordinea WWN-urilor
(perccli /c0/s0 arată toate | grep WWN) și dimensiunea benzii, cel puțin.
Acest proces mi-a oferit și offset-ul de pornire (întotdeauna 0) și dimensiunea
compartimentări (19531825152 sectoare).
Varianta raid5 folosită de H740P (și probabil toate megaraid
controlori) se numește stânga-simetric sau „RAID-5 Rotating Parity N cu
Continuarea datelor (PRL=05, RLQ=03)".
Reasamblarea discurilor pentru testare
Apoi am încercat să testez-reasamblam raid-ul folosind mdadm --build. Din păcate, mdadm refuză să asambleze matrice raid5 - tu
avea pentru a scrie în matrice și a distruge datele :(
Ca o soluție, pentru a testa dacă ordinea este corectă, am pornit un kvm
în modul instantaneu cu o imagine aleatorie de boot GNU/Linux ca /dev/sda iar discurile ca discuri virtio:
exec kvmb -snapshot -m 16384 \
-drive file=linux.img,snapshot=off\
-drive file=/dev/sdm,if=virtio,snapshot=on \
-drive file=/dev/sdl,if=virtio,snapshot=on \
-drive file=/dev/sdk,if=virtio,snapshot=on \
-drive file=/dev/sdi,if=virtio,snapshot=on \
-drive file=/dev/sdg,if=virtio,snapshot=on \
-drive file=/dev/sdf,if=virtio,snapshot=on \
-drive file=/dev/sdh,if=virtio,snapshot=on
Acest lucru a făcut ca discurile să apară în ordinea specificată ca /dev/vda, /dev/vdb și așa mai departe și mi-a permis să testez cu ușurință diverse opțiuni. Prima încercare în interiorul VM a reușit:
mdadm --create /dev/md0 -f \
--metadata 1.0 \
--raid-devices 7 \
-z $((19531825152/2))K -c 256K \
-l raid5 -p ddf-N-continuare \
--assume-clean -k resync \
/dev/vd?
Pentru raid5, dimensiunea partiției este necritică - dacă este mai mare, GPT-ul dvs
tabela de partiții este coruptă și aveți date suplimentare, dar restul
discul ar trebui să fie în continuare lizibil.
Am verificat corectitudinea datelor prin montarea partiției (care ar trebui
nu arunca erori, dar ar putea reuși chiar dacă comanda este greșită), și folosind
btrfs scrub, care verifică sumele de verificare ale metadatelor și blocurilor de date, care este testul final și un plus major al btrfs.
Apoi am rulat din nou backzp.
Am notat apoi WWN-ul tuturor discurilor în ordine, ca să îl pot recrea
cu perccli. De asemenea, am făcut o copie de rezervă a primului și ultimului 1 GB de date de
volumul în sine, în cazul în care controlerul raid le-ar suprascrie.
Mutarea volumului înapoi în controlerul raid
Deoarece aproximativ 14 TB de date nu au fost făcute copii de rezervă (pentru că datele pot fi
recuperat din altă parte cu ceva efort și eram prea nerăbdător să
așteptați o copie), efectuarea unei restaurări complete nu era o opțiune pe care o așteptam cu nerăbdare
la, așa că am încercat să mut matricea înapoi în controler.
Prima mea încercare a fost să formatez matricea ca container DDF cu raid5
volum în interior, folosind aceiași parametri pe care îi folosește controlerul, dar, din păcate, controlerul megaraid - în timp ce folosește
DDF în sine - nu acceptă DDF „străin” pentru importuri și a arătat discurile pur și simplu
ca „bun neconfigurat”.
Apoi am încercat să recreez matricea pur și simplu adăugându-l din nou, de exemplu:
perccli /c0 add vd r5 name=XXX drives=3,6,9,1,2,3,0 pdcache=off wb ra strip=256
Făcând acest lucru pe un sistem pornit cu perccli se asigură că controlerul raid
va face o inițializare în fundal, care nu este distructivă și, cu RAID5,
nici măcar nu va distruge datele atunci când ordinea discului sau dimensiunea benzii sunt greșite, așa cum
atâta timp cât folosești exact toate discurile din matricea originală în orice ordine, fără a lăsa unul afară sau a da prea multe.
Aici am eșuat - cumva, am greșit complet ordinea discurilor,
și, de asemenea, a reușit să corupă primii 1,5 MB din volum. am absolut
nu am idee ce a mers prost, dar am încercat multe permutări și nu am văzut
datele corecte, până la punctul în care am crezut că va face controlorul raidului
reordonează cumva discurile mele (dar nu o face, este exact comanda ca
specificat).
Pe scurt, am atașat discurile la HBA din nou și am încercat și
nu a reușit să-i dea sens. Aici a fost utilă backup-ul meu original:
deși am pierdut ordinea discurilor, am aruncat o privire atentă asupra copiei de rezervă și
a scăzut ordinea potențială la două permutări posibile, pur și simplu, holbându-se la hexdumps. Crearea matricei cu mdadm și testarea datelor îmi oferă ordinea corectă.
Apoi am notat din nou ordinea WWN-urilor, am atașat discurile la
controller, a pornit și a făcut-o perccli /c0 adauga.... Am restaurat apoi primul
1,5 MB din volum (care a inclus partiția GPT și etichetele LVM și
niște date vechi de gunoi rămase care au fost foarte utile atunci când ghiciți ce
ordinea ar putea fi). Un anumit nivel de încredere în a putea anula
greșelile este de ajutor în această situație.
Rezultat: matricea a revenit, btrfs este consecvent și controlerul este acum inițializat în fundal, ceea ce face ca întregul sistem să încetinească câteva zile, dar este un preț mic de plătit.
Lucruri Învățate
Am invatat multe!
Controlerele perc (și probabil toate controlerele megaraid) nu fac față
bine cu probleme frecvente rapide și intermitente de disc - bănuiesc că discurile dispar și revin rapid a declanșat o condiție de cursă în care controlerul încerca să scrie noua configurație pe discuri și a reușit doar parțial cu unele discuri, în cele din urmă împărțind raidul în două . Acesta este în mod clar o eroare de firmware. Dar atunci, cine s-ar aștepta ca cablurile de alimentare să fie defecte...
mdadm nu este foarte util în înțelegerea sau afișarea antetelor DDF -
Pur și simplu nu am putut înțelege datele afișate și așa cum am aflat
atunci când decodez singur anteturile, acest lucru se datorează faptului că multe informații sunt
lipsă din --detaliu și --examina ieșire.De asemenea, nu este foarte util în experimentare, deoarece refuză să facă o asamblare nedistructivă doar în citire.
Controlerele perc/megaid folosesc formatul SNIA DDF intern, iar acesta fiind a
specificație accesibilă publicului, a fost extrem de utilă, deși până la urmă mi-am dat seama de ce aveam nevoie fără aceste informații.
Fiind capabil să ghicească ordinea corectă a benzilor de raid numai din date
este foarte util. Resturile de gunoi și alte date care pot ajuta în acest sens
este, de asemenea, foarte util. Voi lua în considerare scrierea „disc 1”, „disc 2” și așa mai departe în
zonele „goale” ale anteturilor mele de volum RAID de acum înainte (există porțiuni lungi de 0 octeți în primii 2MB).
Este foarte ușor să dai dracu - nume de dispozitive, numere de membri ai raidului, WWN-uri,
numerele de slot și așa mai departe fiind diferite, pot însemna o mulțime de date pentru
gestionați, iar WWN-urile sunt lungi și vechii mei ochi nu mai sunt atât de buni. În plus, nu sunt bine organizat și prea încrezător în mine :/
Crearea și ștergerea unei matrice folosind discuri cu date pe ea
nu va șterge datele, cel puțin cu RAID5 și folosind fundal
initializare. Inițializarea primului plan se va reduce aproape sigur
discurile. Asta înseamnă că poți crea și șterge matricea cât mai multe
ori cât doriți, fără a risca pierderea datelor, cu o posibilă excepție:
ștergerea unei matrice necesită uneori opțiunea de forță deoarece RAID-ul
controlerul crede că este „în uz” din cauza unei etichete valide de partiție. Și asta ar putea eliminați eticheta GPT - YMMV și asigurați-vă că aveți o copie de rezervă a
primii câțiva megabiți pentru orice eventualitate.
Perc/megaraid nu înțeleg containerele DDF non-dell/megaraid. La
cel puțin nu am aflat cum să-mi fac controlerul să accepte DDF creat de mdadm
containere. A fi capabil să formateze discul în GNU/Linux și să le muți înapoi în controler ar fi ajutat foarte mult și ar fi evitat multe ore de durere din partea mea.
rezumat
Am recuperat totul fără a restabili din backup, în detrimentul unui
câteva zile de timp lent de inițializare de fundal.Mi-am notat solutia
de mai sus, în cazul în care unele dintre ele ar putea fi utile altor persoane în
situatii similare.
