Udskiftning af et mislykket drev i et mdadm-array på Ubuntu

Oplysningerne i dette indlæg er baseret på Ubuntu 18.04 og den version af mdadm, der er inkluderet i dens repositories; på tidspunktet for skrivningen er v4.1-rc1. Den er muligvis gyldig for andre versioner, men er muligvis ikke gyldig.

Jeg oplevede for nylig en pludselig diskfejl på min hjemmefilserver, som består af ni drev i et mdadm RAID-6-array. Det er altid skræmmende, men jeg var heldigvis i stand til hurtigt at finde et erstatningsdrev, der blev leveret allerede dagen efter, så jeg kunne komme i gang med genopbygningen.

Jeg må indrømme, at jeg var lidt for snæversynet, da jeg oprindeligt satte filserveren op; kun to af drevene er rigtige NAS-drev (Seagate IronWolf), mens resten er stationære drev (Seagate Barracuda). Ikke overraskende var det et af stationære drevene, der havde givet op (dog efter næsten tre års tjeneste). Det var fuldstændig dødt; efter at have flyttet det til et USB-kabinet til stationær computer fik jeg kun en foruroligende kliklyd ud af det, og hverken Ubuntu 20.04 eller Windows 10 kunne registrere det.

Nå, så til reservedelen (og ja, det nye drev jeg købte var et IronWolf, lektien er lært) - lige så skræmmende som det er at miste et drev i et kørende array, er det endnu mere skræmmende, hvis man ikke kender den korrekte procedure for at udskifte det. Det er ikke første gang, jeg har været nødt til at udskifte et defekt drev i et mdadm-array, men heldigvis er det så sjældent, at jeg normalt er nødt til at slå de rigtige kommandoer op. Denne gang besluttede jeg mig for at lave min egen lille guide til fremtidig brug.

Så først og fremmest, når du modtager den frygtede fejlbegivenheds-e-mail fra mdadm, skal du identificere hvilket drev der er gået i stykker. Selvfølgelig vil den fortælle dig enhedsnavnet (i mit tilfælde /dev/sdf), men det er sandsynligvis ikke indlysende, hvilket fysisk drev det rent faktisk er, da disse navne kan ændre sig, når maskinen startes op.

Hvis du ikke engang er sikker på, hvilket enhedsnavn der har fejlet, kan du bruge følgende kommando til at finde ud af det (erstat /dev/md0 med din RAID-enhed):

Som nævnt var det i mit tilfælde /dev/sdf, så lad os fortsætte med det.

Derefter kan du prøve at finde serienummeret på det defekte drev ved at udføre denne kommando:

(hvis smartctl ikke findes, skal du installere smartmontools-pakken på Ubuntu)

Serienummeret kan derefter sammenlignes med serienumrene på den fysiske etiket på drevene for at finde ud af, hvilket et der er defekt.

Denne gang var jeg dog ikke så heldig. Drevet var fuldstændig dødt og nægtede endda at levere SMART eller andre data, inklusive serienummeret.

Da jeg havde fysisk adgang til serveren (hvilket man virkelig har brug for, hvis man selv skal udskifte et fysisk drev, formoder jeg ;-)), og serveren faktisk kørte, da disken gik i stykker (og fortsatte med at køre fint takket være RAID-6-redundansen), valgte jeg den meget primitive, men faktisk yderst effektive og indlysende metode med blot at kopiere en stor fil til serveren og se, hvilken harddisklampe der ikke blinkede. Inden for få sekunder havde jeg identificeret synderen.

Før du hiver det fysiske drev ud, er det en god idé formelt at informere mdadm om denne hensigt ved at udføre denne kommando (erstat enhedsnavne med dine egne efter behov):

Hvis det lykkes, vil mdadm svare med en besked, der siger, at den har "hot removed" drevet, tilsyneladende fordi den virtuelle raid-enhed faktisk kører på det tidspunkt.

Hvis den fejler med en fejlmeddelelse i stil med "enhed eller ressource optaget", kan det være, at mdadm faktisk ikke har registreret drevet som fuldstændigt fejlet. For at få det til at ske, skal du udføre denne kommando (igen, husk at erstatte enhedsnavne med dine egne efter behov):

Derefter burde du kunne fjerne enheden fra arrayet med den forrige kommando.

Nu er det tid til rent faktisk at udskifte drevet. Hvis du er virkelig, virkelig – altså, virkelig – sikker på, at din maskine og controller understøtter hot swapping, kan du gøre dette uden at lukke maskinen ned. Det ville være vejen frem med kritiske produktionssystemer, der kører på rigtig, ordentlig serverhardware, som du med sikkerhed ved kan håndtere det. Min hjemmefilserver er dog baseret på et bundkort til stationære computere i forbrugerkvalitet med et par semi-navnløse SATA-controllere i PCIe-slotsene for at give flere SATA-porte.

Selvom SATA generelt burde understøtte hot swapping, ville jeg ikke risikere noget i denne opsætning, så jeg valgte at lukke maskinen ned, mens jeg udskiftede drevet.

Før du gør det, er det en god idé at kommentere raid-enheden ud i /etc/fstab-filen, så Ubuntu ikke forsøger at montere den automatisk ved næste opstart, da den kan hænge og tvinge dig i gendannelsestilstand på grund af det forringede RAID-array. Det er måske ikke et stort problem, hvis det er et desktop-system, men jeg kører denne server headless uden skærm eller tastatur tilsluttet, så det ville være lidt besværligt.

Efter at have startet maskinen op med det nye drev installeret, skal du bruge lsblk eller en anden metode til at identificere det. Hvis du ikke har ændret noget andet, vil det sandsynligvis (men ikke nødvendigvis) få det samme navn som det drev, du udskiftede. I mit tilfælde fik det det, så det nye drev kaldes også /dev/sdf.

Da mit array er baseret på partitioner snarere end fysiske enheder, var jeg nødt til at kopiere partitionstabellen fra et fungerende drev til det nye drev for at sikre, at de er præcis ens. Hvis du kører dit array på fysiske enheder i stedet, kan du springe dette trin over.

Jeg brugte sgdisk til dette formål og kopierede partitionstabellen fra /dev/sdc til /dev/sdf. Sørg for at erstatte enhedsnavnene, så de matcher dine egne, efter behov.

Bemærk rækkefølgen her: Du angiver "til"-drevet først! Det er lidt kontraintuitivt for mig, men sørg bare for at gøre det rigtigt, så du ikke får endnu en drevfejl i arrayet ;-)

For at undgå UUID-konflikter skal du derefter generere nye UUID'er til det nye drev:

Og nu er tiden endelig kommet til at tilføje det nye drev til arrayet og starte genopbygningsfesten! (Okay, det er ikke rigtig en fest, det er faktisk en ret langsom og foruroligende proces, da du virkelig, virkelig ikke ønsker, at et andet drev går i stykker på nuværende tidspunkt. Øl kan dog hjælpe.)

Under alle omstændigheder, for at tilføje det nye drev til arrayet, skal du udføre denne kommando (igen, sørg for at erstatte enhedsnavne med dine egne efter behov):

Hvis alt går vel, vil drevet blive tilføjet til arrayet uden problemer. Jeg tror, det faktisk er tilføjet som en "hot spare" som standard, men da dette array mangler en disk (den der gik i stykker), tages det straks i brug, og genopbygningsprocessen starter.

Du kan holde øje med det sådan her:

Det vil nok tage et stykke tid; på min beskedne server (hovedsageligt baseret på forbrugerhardware og stationære harddiske, bemærk) kunne den nå lige under 100 MB/sek. Husk på, at dette er RAID-6, så der er en masse paritetsberegninger involveret i en genopbygning; en RAID-10 ville have været meget hurtigere. Denne specifikke maskine har en AMD A10 9700E quad core CPU ("E" betyder, at det er en underclocket energieffektiv model, dvs. ikke super hurtig), bare for at give dig en idé om, hvad du kan forvente. Med de ni 8 TB-drev i min opsætning tog den fulde genopbygning lidt over 24 timer.

Under genopbygningen kan du montere filsystemet på arrayet og bruge det som normalt, hvis du ønsker det, men jeg foretrækker at lade det være til genopbygningen, indtil den er færdig. Husk, at hvis ét drev fejler, kan et andet snart følge efter, så du ønsker, at genopbygningen skal udføres så hurtigt som muligt, da du virkelig ikke ønsker, at et andet drev skal fejle under det. Belast det derfor ikke med anden IO, der ikke er strengt nødvendig.

Når det er færdigt, så tilføj det tilbage til din /etc/fstab-fil, genstart og nyd dine filer :-)