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 dets arkiver; i skrivende stund v4.1-rc1. Det er muligvis ikke gyldigt for andre versioner.

Jeg havde for nylig en pludselig drevfejl i 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 skaffe et erstatningsdrev, der blev leveret allerede dagen efter, så jeg kunne komme i gang med genopbygningen.

Jeg var ganske vist lidt for billig, da jeg oprindeligt satte filserveren op; kun to af drevene er egentlige NAS-drev (Seagate IronWolf), mens resten er desktop-drev (Seagate Barracuda). Ikke overraskende var det et af desktopdrevene, der havde givet op (dog efter næsten tre års drift). Den var fuldstændig død; efter at have flyttet det til et desktop USB-kabinet, fik jeg kun en nervepirrende kliklyd, og hverken Ubuntu 20.04 eller Windows 10 var i stand til at registrere det.

Nå ja, videre til udskiftningsdelen (og ja, det nye drev, jeg købte, var en IronWolf, lektion 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 du ikke kender den korrekte procedure for at udskifte det. Det er ikke første gang, jeg skal udskifte et fejlbehæftet drev i et mdadm-array, men det er heldigvis så sjældent, at jeg normalt skal slå de rigtige kommandoer op. Denne gang besluttede jeg at lave min egen lille guide til fremtidig reference.

Så først og fremmest, når du får den frygtede fejl-e-mail fra mdadm, skal du identificere, hvilket drev der har fejlet. Sikker på, det vil fortælle dig enhedsnavnet (i mit tilfælde /dev/sdf), men det er sandsynligvis ikke indlysende, hvilket fysisk drev der faktisk er, da disse navne kan ændre sig, når maskinen startes.

Hvis du ikke engang er sikker på, hvilket enhedsnavn der er 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 fejlbehæftede drev ved at udstede denne kommando:

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

Serienummeret kan derefter sammenlignes med serienumrene på den fysiske mærkat på drevene for at finde ud af, hvilken der har fejlet.

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

Da jeg havde fysisk adgang til serveren (som du virkelig har brug for, hvis du selv skal udskifte et fysisk drev, formoder jeg ;-)), og serveren faktisk kørte, da disken fejlede (og fortsatte med at køre fint takket være RAID-6-redundansen), gik jeg med den virkelig primitive, men faktisk yderst effektive og indlysende metode, hvor jeg simpelthen kopierede en stor fil til serveren og så, hvilken HDD-flimmer, der ikke lyser. Inden for få sekunder havde jeg identificeret den skyldige.

Nu, før du trækker det fysiske drev ud, er det en god idé formelt at informere mdadm om denne hensigt ved at udstede denne kommando (erstat enhedsnavne med dine egne efter behov):

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

Hvis det fejler med en fejlmeddelelse, der ligner "enhed eller ressource optaget", kan det være, at mdadm faktisk ikke har registreret drevet til at have fejlet fuldstændigt. For at få det til at gøre det, giv denne kommando (igen, husk at erstatte enhedsnavne med dine egne efter behov):

Derefter skulle du være i stand til at fjerne enheden fra arrayet med den forrige kommando.

Nu er det tid til faktisk at udskifte drevet. Hvis du er virkelig, virkelig - ligesom, 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 til at gå på kritiske produktionssystemer, der kører på ægte, ordentlig serverhardware, som du med sikkerhed ved kan klare det. Min hjemmefilserver er baseret på et desktop-bundkort i forbrugerkvalitet med et par semi-noname SATA-controllere i PCIe-slotsene for at give flere SATA-porte.

Selvom SATA generelt burde understøtte hot swapping, var jeg ikke ved at 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 i /etc/fstab-filen, så Ubuntu ikke vil forsøge at montere den automatisk ved næste opstart, fordi 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 hovedløs uden skærm eller tastatur tilsluttet, så det ville være lidt af et besvær.

Efter opstart af maskinen med det skinnende nye drev installeret, skal du bruge lsblk eller en anden måde til at identificere det. Hvis du ikke har ændret noget andet, vil det sandsynligvis (men ikke nødvendigvis ) få samme navn som det drev, du har udskiftet. I mit tilfælde gjorde den det, så den nye hedder 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 nøjagtigt ens. Hvis du i stedet kører dit array på fysiske enheder, 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 enhedsnavne, så de matcher dine egne efter behov.

Læg mærke til rækkefølgen her: du angiver "til"-kørslen først! Dette er lidt kontraintuitivt for mig, men sørg bare for at få det rigtigt, så du ikke får endnu en drevfejl i arrayet ;-)

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

Og nu er tiden endelig kommet til at føje det nye drev til arrayet og sætte gang i genopbygningsfesten! (Okay, det er ikke rigtig en fest, det er faktisk en ret langsom og nervøs proces, da du virkelig, virkelig ikke ønsker, at endnu et drev fejler på nuværende tidspunkt. Øl kan dog hjælpe)

Under alle omstændigheder, for at tilføje det nye drev til arrayet, udsted 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, ​​at det faktisk er tilføjet som en "hot spare" som standard, men da dette array mangler en disk (den der fejlede), tages den straks i brug, og genopbygningsprocessen starter.

Du kan holde øje med det sådan:

Dette vil sandsynligvis tage et stykke tid; på min ringe server (hovedsagelig baseret på hardware og desktopdrev, vel at mærke) var den i stand til at nå lige under 100 MB/sek. Husk, at dette er RAID-6, så der er mange paritetsberegninger involveret i en genopbygning; en RAID-10 ville have været meget hurtigere. Denne særlige maskine har en AMD A10 9700E quad core CPU ("E", hvilket betyder, at det er en underklokket energieffektiv model, dvs. ikke superhurtig), 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 overlade det til genopbygningen, indtil det er færdigt. Husk på, at hvis et drev fejler, kan et andet snart følge efter, så du vil have genopbygningen udført så hurtigt som muligt, da du virkelig ikke ønsker, at et andet drev fejler under det. Derfor skal du ikke belaste det med andre IO, der ikke er strengt nødvendige.

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