Een defecte schijf vervangen in een mdadm-array op Ubuntu

De informatie in dit bericht is gebaseerd op Ubuntu 18.04 en de versie van mdadm die in de repositories is opgenomen; op het moment van schrijven was dit v4.1-rc1. Het kan wel of niet geldig zijn voor andere versies.

Ik had onlangs een plotselinge schijfstoring in mijn home file server, die bestaat uit negen schijven in een mdadm RAID-6 array. Dat is altijd eng, maar ik kon gelukkig snel een vervangende schijf vinden die de volgende dag al werd geleverd, zodat ik kon beginnen met de herbouw.

Ik was toegegeven een beetje te gierig toen ik de bestandsserver oorspronkelijk instelde; slechts twee van de schijven zijn echte NAS-schijven (Seagate IronWolf), terwijl de rest desktopschijven zijn (Seagate Barracuda). Het was niet verrassend dat het een van de desktopschijven was die het had opgegeven (na bijna drie jaar dienst). Hij was helemaal dood; nadat ik hem naar een desktop-USB-behuizing had verplaatst, hoorde ik alleen een verontrustend klikgeluid en noch Ubuntu 20.04 noch Windows 10 konden het detecteren.

Nou ja, door naar het vervangende onderdeel (en ja, de nieuwe drive die ik kocht was een IronWolf, les geleerd) - hoe eng het ook is om een drive te verliezen in een draaiende array, het is nog enger als je niet weet hoe je hem moet vervangen. Het is niet de eerste keer dat ik een defecte drive in een mdadm array moet vervangen, maar gelukkig gebeurt dat zo zelden dat ik meestal de juiste commando's moet opzoeken. Deze keer besloot ik om mijn eigen kleine handleiding te maken voor toekomstig gebruik.

Dus, allereerst, wanneer u de gevreesde fail event e-mail van mdadm ontvangt, moet u identificeren welke drive is gefaald. Natuurlijk, het zal u de apparaatnaam vertellen (in mijn geval /dev/sdf), maar het is waarschijnlijk niet duidelijk welke fysieke drive dat daadwerkelijk is, aangezien die namen kunnen veranderen wanneer de machine wordt opgestart.

Als u niet zeker weet welke apparaatnaam het probleem veroorzaakt, kunt u de volgende opdracht gebruiken om erachter te komen (vervang /dev/md0 door uw RAID-apparaat):

Zoals gezegd was het in mijn geval /dev/sdf, dus laten we daarmee doorgaan.

Vervolgens kunt u proberen het serienummer van de defecte schijf te vinden door de volgende opdracht uit te voeren:

(als smartctl niet wordt gevonden, moet u het smartmontools-pakket op Ubuntu installeren)

Het serienummer kan vervolgens worden vergeleken met de serienummers op het fysieke label op de schijven om erachter te komen welke schijf defect is.

Deze keer had ik echter minder geluk. De drive was helemaal dood en weigerde zelfs SMART of andere gegevens te verstrekken, inclusief het serienummer.

Omdat ik fysieke toegang had tot de server (wat je echt nodig hebt als je zelf een fysieke schijf gaat vervangen, denk ik ;-)) en de server daadwerkelijk draaide toen de schijf kapotging (en prima bleef draaien dankzij de RAID-6 redundantie), koos ik voor de heel primitieve, maar eigenlijk zeer effectieve en voor de hand liggende, methode om gewoon een groot bestand naar de server te kopiëren en te kijken welk HDD-lampje niet knipperde. Binnen een paar seconden had ik de boosdoener geïdentificeerd.

Voordat u de fysieke schijf verwijdert, is het een goed idee om mdadm formeel op de hoogte te stellen van dit voornemen. Dit doet u door de volgende opdracht uit te voeren (vervang de apparaatnamen indien van toepassing door uw eigen namen):

Als de bewerking succesvol is uitgevoerd, zal mdadm reageren met een bericht dat de schijf 'hot removed' is, wat waarschijnlijk komt doordat het virtuele RAID-apparaat op dat moment daadwerkelijk actief is.

Als het mislukt met een foutmelding die lijkt op "apparaat of resource bezet", kan het zijn dat mdadm de drive niet heeft geregistreerd als volledig mislukt. Om dit te laten gebeuren, geeft u deze opdracht (vergeet niet om de apparaatnamen te vervangen door uw eigen namen indien van toepassing):

Hierna zou u het apparaat met de vorige opdracht uit de array moeten kunnen verwijderen.

Nu is het tijd om de drive daadwerkelijk te vervangen. Als u echt, echt - echt, echt - zeker weet dat uw machine en controller hot swapping ondersteunen, kunt u dit doen zonder de machine uit te schakelen. Dat zou de manier zijn om te werk te gaan op kritieke productiesystemen die draaien op echte, goede serverhardware waarvan u zeker weet dat deze het aankan. Mijn thuisbestandsserver is gebaseerd op een consumenten desktop moederbord met een paar semi-noname SATA controllers in de PCIe slots om meer SATA poorten te bieden.

Hoewel SATA over het algemeen hot-swapping zou moeten ondersteunen, wilde ik in deze opstelling geen enkel risico lopen. Daarom besloot ik de machine uit te schakelen terwijl ik de schijf verving.

Voordat u dat doet, is het een goed idee om het raid-apparaat in het bestand /etc/fstab uit te zetten, zodat Ubuntu niet automatisch probeert het te mounten bij de volgende keer opstarten, omdat het dan kan vastlopen en u in de recovery-modus kan dwingen vanwege de gedegradeerde RAID-array. Dat is misschien geen groot probleem als het een desktopsysteem is, maar ik draai deze server headless zonder aangesloten monitor of toetsenbord, dus dit zou een beetje lastig zijn.

Nadat u de machine hebt opgestart met de glimmende nieuwe drive geïnstalleerd, gebruikt u lsblk of een andere manier om deze te identificeren. Als u verder niets hebt gewijzigd, krijgt deze waarschijnlijk (maar niet noodzakelijkerwijs ) dezelfde naam als de drive die u hebt vervangen. In mijn geval wel, dus de nieuwe heet ook /dev/sdf.

Omdat mijn array is gebaseerd op partities in plaats van fysieke apparaten, moest ik de partitietabel van een werkende schijf naar de nieuwe schijf kopiëren om er zeker van te zijn dat ze exact hetzelfde zijn. Als u uw array in plaats daarvan op fysieke apparaten uitvoert, kunt u deze stap overslaan.

Ik heb hiervoor sgdisk gebruikt, waarbij ik de partitietabel van /dev/sdc naar /dev/sdf heb gekopieerd. Zorg ervoor dat u de apparaatnamen vervangt zodat ze overeenkomen met uw eigen namen.

Let op de volgorde hier: je vermeldt de "to" drive als eerste! Dit is een beetje tegenintuïtief voor mij, maar zorg ervoor dat je het goed doet zodat je niet nog een drive failure in de array krijgt ;-)

Om UUID-conflicten te voorkomen, genereert u nieuwe UUID's voor de nieuwe schijf:

En nu is het eindelijk tijd om de nieuwe drive aan de array toe te voegen en het rebuild-feestje te beginnen! (Oké, het is niet echt een feestje, het is eigenlijk een vrij langzaam en zenuwslopend proces, want je wilt echt, echt niet dat er op dit moment nog een drive kapotgaat. Bier kan helpen, hoewel)

Om de nieuwe schijf aan de array toe te voegen, geeft u de volgende opdracht (zorg er nogmaals voor dat u de apparaatnamen vervangt door uw eigen namen):

Als alles goed gaat, wordt de drive zonder haperingen aan de array toegevoegd. Ik geloof dat het eigenlijk standaard als "hot spare" is toegevoegd, maar omdat deze array een disk mist (degene die het begaf), wordt deze direct in gebruik genomen en start het rebuild-proces.

Je kunt het als volgt in de gaten houden:

Dit zal waarschijnlijk een tijdje duren; op mijn bescheiden server (voornamelijk gebaseerd op hardware van consumentenkwaliteit en desktopschijven, let wel) kon het net geen 100 MB/sec halen. Houd er rekening mee dat dit RAID-6 is, dus er zijn veel pariteitsberekeningen betrokken bij een herbouw; een RAID-10 zou veel sneller zijn geweest. Deze specifieke machine heeft een AMD A10 9700E quad-core CPU (de "E" staat voor een energiezuinig model met een onderkloksnelheid, d.w.z. niet supersnel), om u een idee te geven van wat u kunt verwachten. Met de negen 8 TB-schijven in mijn opstelling duurde de volledige herbouw iets meer dan 24 uur.

Tijdens het herbouwen kunt u het bestandssysteem op de array mounten en het gebruiken zoals u dat wilt, maar ik laat het liever aan het herbouwen over totdat het klaar is. Houd er rekening mee dat als één schijf kapotgaat, er snel een andere kan volgen, dus u wilt dat het herbouwen zo snel mogelijk wordt uitgevoerd, omdat u echt niet wilt dat er tijdens het herbouwen nog een schijf kapotgaat. Belast het daarom niet met andere IO die niet strikt noodzakelijk is.

Zodra het klaar is, voegt u het toe aan uw /etc/fstab-bestand, start u het systeem opnieuw op en kunt u genieten van uw bestanden :-)