Vervang 'n mislukte skyf in 'n mdadm-skikking op Ubuntu

Die inligting in hierdie plasing is gebaseer op Ubuntu 18.04 en die weergawe van mdadm wat in sy bewaarplekke ingesluit is; ten tyde van die skryf hiervan v4.1-rc1. Dit mag dalk geldig wees vir ander weergawes, of nie.

Ek het onlangs 'n skielike skyfversaking in my tuislêerbediener gehad, wat uit nege skywe in 'n mdadm RAID-6-skikking bestaan. Dis altyd skrikwekkend, maar ek kon gelukkig vinnig 'n plaasvervangende skyf opspoor wat reeds die volgende dag afgelewer is sodat ek die herbou kon begin.

Ek was weliswaar 'n bietjie te suinig toe ek die lêerbediener oorspronklik opgestel het; slegs twee van die skywe is werklike NAS-skywe (Seagate IronWolf), terwyl die res rekenaarskywe (Seagate Barracuda) is. Dit is geen verrassing dat dit een van die rekenaarskywe was wat opgegee het nie (na byna drie jaar se diens). Dit was heeltemal dood; nadat ek dit na 'n rekenaar-USB-omhulsel geskuif het, was al wat ek daaruit gekry het 'n ontstellende klikgeluid en nóg Ubuntu 20.04 nóg Windows 10 kon dit opspoor.

Ag wel, oor na die vervangingsonderdeel (en ja, die nuwe skyf wat ek gekoop het, was 'n IronWolf, les geleer) - so eng as wat dit is om 'n skyf in 'n lopende skikking te verloor, is dit selfs skrikwekkender as jy nie die korrekte prosedure ken om dit te vervang nie. Dis nie die eerste keer dat ek 'n mislukte skyf in 'n mdadm-skikking moes vervang nie, maar gelukkig is dit so skaars dat ek gewoonlik die korrekte opdragte moet opsoek. Hierdie keer het ek besluit om my eie klein gids vir toekomstige verwysing op te stel.

So, eerstens, wanneer jy die gevreesde e-pos van mdadm oor 'n mislukte gebeurtenis kry, moet jy identifiseer watter skyf gefaal het. Sekerlik, dit sal jou die toestelnaam vertel (in my geval /dev/sdf), maar dit is waarskynlik nie voor die hand liggend watter fisiese skyf dit eintlik is nie, aangesien daardie name kan verander wanneer die masjien selflaai.

As jy nie eers seker is watter toestelnaam misluk het nie, kan jy die volgende opdrag gebruik om uit te vind (vervang /dev/md0 met jou RAID-toestel):

Soos genoem, in my geval was dit /dev/sdf, so kom ons gaan daarmee voort.

Dan kan jy probeer om die reeksnommer van die mislukte skyf te vind deur hierdie opdrag uit te voer:

(indien smartctl nie gevind word nie, moet jy die smartmontools-pakket op Ubuntu installeer)

Die reeksnommer kan dan vergelyk word met die reeksnommers op die fisiese etiket op die aandrywers om uit te vind watter een gefaal het.

Hierdie keer was ek egter nie so gelukkig nie. Die skyf was heeltemal dood en het selfs geweier om SMART of ander data, insluitend die reeksnommer, te verskaf.

Aangesien ek fisiese toegang tot die bediener gehad het (wat jy regtig nodig het as jy self 'n fisiese skyf gaan vervang, neem ek aan ;-)) en die bediener was eintlik aan die gang toe die skyf gefaal het (en steeds goed geloop het danksy die RAID-6-oortolligheid), het ek die baie primitiewe, maar eintlik hoogs effektiewe en voor die hand liggende, metode gevolg om eenvoudig 'n groot lêer na die bediener te kopieer en te kyk watter HDD-liggie nie flikker nie. Binne 'n paar sekondes het ek die skuldige geïdentifiseer.

Nou, voordat jy die fisiese skyf uitruk, is dit 'n goeie idee om mdadm formeel van hierdie voorneme in kennis te stel deur hierdie opdrag uit te reik (vervang toestelname met jou eie soos toepaslik):

Indien dit suksesvol is, sal mdadm antwoord met 'n boodskap wat sê dat dit die skyf "warm verwyder" het, blykbaar omdat die virtuele aanvalstoestel tans loop.

Indien dit misluk met 'n foutboodskap soortgelyk aan "toestel of hulpbron besig", kan dit wees dat mdadm die skyf in werklikheid nie as heeltemal misluk geregistreer het nie. Om dit te laat doen, gee hierdie opdrag uit (onthou weer om toestelname met jou eie te vervang soos toepaslik):

Daarna behoort jy die toestel met die vorige opdrag uit die skikking te kan verwyder.

Nou is dit tyd om die skyf te vervang. As jy regtig, regtig – soos, regtig – seker is dat jou masjien en beheerder warm ruil ondersteun, kan jy dit doen sonder om die masjien af te skakel. Dit sou die manier wees om kritieke produksiestelsels te gebruik wat op regte, behoorlike bedienerhardeware loop wat jy verseker weet dit kan hanteer. My tuislêerbediener is gebaseer op 'n verbruikersgraad-tafelrekenaarmoederbord met 'n paar semi-naamlose SATA-beheerders in die PCIe-gleuwe om meer SATA-poorte te bied.

Alhoewel SATA oor die algemeen warm uitruiling behoort te ondersteun, was ek nie van plan om enigiets in hierdie opstelling te waag nie, so ek het gekies om die masjien af te skakel terwyl ek die skyf vervang.

Voordat jy dit doen, is dit 'n goeie idee om die raid-toestel in die /etc/fstab-lêer uit te kommentaar sodat Ubuntu dit nie outomaties met die volgende opstart sal probeer koppel nie, want dit kan dalk vashaak en jou in herstelmodus dwing as gevolg van die gedegradeerde RAID-skikking. Dit is dalk nie 'n groot probleem as dit 'n rekenaarstelsel is nie, maar ek laat hierdie bediener koploos loop sonder 'n monitor of sleutelbord gekoppel, so dit sal 'n bietjie van 'n gesukkel wees.

Nadat jy die masjien met die blink nuwe skyf geïnstalleer het, gebruik lsblk of 'n ander manier om dit te identifiseer. As jy niks anders verander het nie, sal dit waarskynlik (maar nie noodwendig nie) dieselfde naam kry as die skyf wat jy vervang het. In my geval het dit, so die nuwe een word ook /dev/sdf genoem.

Aangesien my skikking gebaseer is op partisies eerder as fisiese toestelle, moes ek die partisietabel van 'n werkende skyf na die nuwe skyf kopieer om seker te maak dat hulle presies dieselfde is. As jy jou skikking eerder op fisiese toestelle laat loop, kan jy hierdie stap oorslaan.

Ek het sgdisk vir hierdie doel gebruik en die partisietabel van /dev/sdc na /dev/sdf gekopieer. Maak seker dat jy toestelname vervang om by jou eie te pas soos toepaslik.

Let op die volgorde hier: jy lys die "na"-skyf eerste! Dit is 'n bietjie teenintuïtief vir my, maar maak net seker jy kry dit reg sodat jy nie nog 'n skyffout in die skikking kry nie ;-)

Om UUID-konflikte te vermy, genereer dan nuwe UUID's vir die nuwe skyf:

En nou het die tyd uiteindelik aangebreek om die nuwe skyf by die skikking te voeg en die herboupartytjie te begin! (Goed, dis nie regtig 'n partytjie nie, dis eintlik 'n redelik stadige en senuweeagtige proses, want jy wil regtig, regtig nie hê dat nog 'n skyf op hierdie tydstip faal nie. Bier kan egter help.)

In elk geval, om die nuwe skyf by die skikking te voeg, gee hierdie opdrag uit (maak weer seker dat jy toestelname met jou eie vervang soos toepaslik):

As alles goed gaan, sal die skyf sonder probleme by die skikking gevoeg word. Ek glo dit word eintlik standaard as 'n "warm spaar" bygevoeg, maar aangesien hierdie skikking 'n skyf kort (die een wat gefaal het), word dit onmiddellik in gebruik geneem en die herbouproses sal begin.

Jy kan dit so dophou:

Dit sal waarskynlik 'n rukkie neem; op my eenvoudige bediener (grotendeels gebaseer op verbruikersgraad-hardeware en rekenaarskywe, let wel) kon dit net onder 100 MB/sek bereik. Hou in gedagte dat dit RAID-6 is, so daar is baie pariteitsberekeninge betrokke by 'n herbou; 'n RAID-10 sou baie vinniger gewees het. Hierdie spesifieke masjien het 'n AMD A10 9700E vierkern-SVE (die "E" beteken dat dit 'n ondergeklokte energie-doeltreffende model is, d.w.s. nie supersnel nie), net om jou 'n idee te gee van wat om te verwag. Met die nege 8 TB-skywe in my opstelling het die volledige herbou net meer as 24 uur geneem.

Tydens die herbou kan jy die lêerstelsel op die skikking monteer en dit normaalweg gebruik as jy wil, maar ek verkies om dit aan die herbou oor te laat totdat dit klaar is. Hou in gedagte dat as een skyf faal, 'n ander dalk gou kan volg, so jy wil hê die herbou moet so vinnig as moontlik gedoen word, aangesien jy regtig nie wil hê dat 'n ander skyf gedurende dit moet faal nie. Moet dit dus nie belas met ander IO wat nie streng noodsaaklik is nie.

Sodra dit klaar is, voeg dit terug by jou /etc/fstab-lêer, herbegin en geniet jou lêers :-)