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 bijbehorende repositories is opgenomen; op het moment van schrijven was dat v4.1-rc1. Het is mogelijk dat deze informatie niet geldig is voor andere versies.

Onlangs viel een van de negen schijven in mijn thuisserver, een mdadm RAID-6-array, plotseling uit. Dat is altijd even schrikken, maar gelukkig kon ik snel een vervangende schijf bestellen die de volgende dag al geleverd werd, zodat ik meteen met het herstelproces kon beginnen.

Ik moet toegeven dat ik aanvankelijk wat te zuinig was toen ik de bestandsserver instelde; slechts twee van de schijven zijn echte NAS-schijven (Seagate IronWolf), de rest zijn desktop-schijven (Seagate Barracuda). Het is dan ook niet verwonderlijk dat een van die desktop-schijven het begaf (na bijna drie jaar trouwe dienst). Hij was volledig kapot; nadat ik hem in een USB-behuizing voor desktops had geplaatst, hoorde ik er alleen nog een onheilspellend tikkend geluid uit en noch Ubuntu 20.04 noch Windows 10 kon hem detecteren.

Nou ja, op naar het vervangende onderdeel (en ja, de nieuwe schijf die ik kocht was een IronWolf, les geleerd) - hoe eng het ook is om een schijf 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 schijf in een mdadm-array moet vervangen, maar gelukkig komt het zo zelden voor dat ik meestal de juiste commando's moet opzoeken. Deze keer besloot ik om zelf een kleine handleiding te maken voor toekomstig gebruik.

Dus allereerst, wanneer je de gevreesde e-mail met een foutmelding van mdadm ontvangt, moet je vaststellen welke schijf defect is. Natuurlijk wordt de apparaatnaam weergegeven (in mijn geval /dev/sdf), maar het is waarschijnlijk niet meteen duidelijk om welke fysieke schijf het precies gaat, aangezien die namen kunnen veranderen tijdens het opstarten van de computer.

Als je niet zeker weet welk apparaat defect is geraakt, kun je de volgende opdracht gebruiken om dat te achterhalen (vervang /dev/md0 door je RAID-apparaat):

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

Vervolgens kunt u proberen het serienummer van de defecte schijf te achterhalen door dit commando uit te voeren:

(Als smartctl niet gevonden wordt, moet je het smartmontools-pakket op Ubuntu installeren.)

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

Deze keer had ik echter minder geluk. De schijf was volledig defect en weigerde zelfs SMART-informatie of andere gegevens te verstrekken, waaronder het serienummer.

Omdat ik fysieke toegang had tot de server (wat je natuurlijk echt nodig hebt als je zelf een harde schijf wilt vervangen ;-)) en de server gewoon draaide toen de schijf het begaf (en dankzij de RAID-6-redundantie prima bleef werken), koos ik voor de primitieve, maar eigenlijk zeer effectieve en voor de hand liggende methode: ik kopieerde een groot bestand naar de server en keek welke harde schijf niet knipperde. Binnen een paar seconden had ik de boosdoener gevonden.

Voordat je de fysieke schijf eruit trekt, is het verstandig om mdadm formeel op de hoogte te stellen van dit voornemen door het volgende commando uit te voeren (vervang de apparaatnamen door je eigen namen indien van toepassing):

Bij succes zal mdadm antwoorden met een bericht dat de schijf "hot removed" is, blijkbaar omdat het virtuele RAID-apparaat op dat moment daadwerkelijk actief is.

Als er een foutmelding verschijnt zoals "apparaat of bron bezet", kan het zijn dat mdadm de schijf nog niet als volledig defect heeft geregistreerd. Om dit te laten gebeuren, voert u de volgende opdracht uit (vergeet niet de apparaatnamen waar nodig te vervangen door uw eigen namen):

Daarna zou je het apparaat met het eerder gegeven commando uit de array moeten kunnen verwijderen.

Nu is het tijd om de schijf daadwerkelijk te vervangen. Als je er echt, echt – echt helemaal zeker van bent – dat je computer en controller hot-swapping ondersteunen, kun je dit doen zonder de computer uit te schakelen. Dat is de beste manier om het te doen bij kritieke productiesystemen die draaien op echte, degelijke serverhardware waarvan je zeker weet dat die het aankan. Mijn thuisserver is echter gebaseerd op een consumentenmoederbord met een paar relatief onbekende SATA-controllers in de PCIe-slots om meer SATA-poorten te bieden.

Hoewel SATA-schijven over het algemeen hot-swapping ondersteunen, wilde ik in deze configuratie geen risico's nemen. Daarom heb ik ervoor gekozen de computer uit te schakelen tijdens het vervangen van de schijf.

Voordat je dat doet, is het verstandig om het RAID-apparaat in het bestand /etc/fstab uit te commentariëren, zodat Ubuntu het niet automatisch probeert te mounten bij de volgende opstart. Dit kan namelijk leiden tot een vastlopen en een herstelmodus vanwege de verslechterde RAID-array. Dit is wellicht geen groot probleem voor een desktopsysteem, maar ik gebruik deze server zonder monitor of toetsenbord, dus voor mij zou dit wel wat gedoe zijn.

Nadat je de computer hebt opgestart met de gloednieuwe schijf, gebruik je lsblk of een ander programma om de schijf te identificeren. Als je verder niets hebt veranderd, zal de nieuwe schijf waarschijnlijk (maar niet noodzakelijkerwijs) dezelfde naam hebben als de schijf die je hebt vervangen. In mijn geval was dat zo, dus de nieuwe schijf heet ook /dev/sdf.

Omdat mijn array is gebaseerd op partities in plaats van fysieke schijven, moest ik de partitietabel van een werkende schijf naar de nieuwe schijf kopiëren om ervoor te zorgen dat ze exact hetzelfde waren. Als je je array op fysieke schijven gebruikt, kun je deze stap overslaan.

Ik heb hiervoor sgdisk gebruikt om de partitietabel van /dev/sdc naar /dev/sdf te kopiëren. Zorg ervoor dat u de apparaatnamen aanpast aan uw eigen apparaatnamen.

Let op de volgorde: je vermeldt eerst de schijf waarnaar je de schijf wilt sturen! Dit is voor mij een beetje tegenstrijdig, maar zorg ervoor dat je het goed doet, zodat je geen nieuwe schijfstoring in de array krijgt ;-)

Om UUID-conflicten te voorkomen, genereer je vervolgens nieuwe UUID's voor de nieuwe schijf:

En nu is eindelijk het moment aangebroken om de nieuwe schijf aan de array toe te voegen en het herstelproces te starten! (Oké, het is niet echt een feestje, het is eerder een vrij traag en zenuwslopend proces, want je wilt echt, echt niet dat er nu weer een schijf uitvalt. Bier zou misschien wel helpen.)

Om de nieuwe schijf aan de array toe te voegen, gebruikt u dit commando (vervang de apparaatnamen waar nodig door uw eigen namen):

Als alles goed gaat, wordt de schijf zonder problemen aan de array toegevoegd. Ik denk dat deze standaard als "hot spare" wordt toegevoegd, maar omdat er een schijf ontbreekt in deze array (de defecte), wordt deze direct in gebruik genomen en start het herstelproces.

Je kunt het als volgt in de gaten houden:

Dit zal waarschijnlijk even duren; op mijn bescheiden server (die grotendeels is opgebouwd uit consumentenhardware en desktop-harde schijven, let wel) haalde hij net geen 100 MB/sec. Houd er rekening mee dat dit RAID-6 is, dus er komen veel pariteitsberekeningen kijken bij een herstelproces; 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 lagere kloksnelheid, dus niet supersnel), om je een idee te geven van wat je kunt verwachten. Met de negen 8 TB-schijven in mijn configuratie duurde het volledige herstelproces iets meer dan 24 uur.

Tijdens het herstelproces kunt u het bestandssysteem op de array koppelen en normaal gebruiken als u dat wilt, maar ik geef er de voorkeur aan om het herstelproces te voltooien. Houd er rekening mee dat als één schijf uitvalt, een andere snel kan volgen. U wilt dus dat het herstelproces zo snel mogelijk wordt afgerond, omdat u absoluut wilt voorkomen dat er tijdens dat proces nog een schijf uitvalt. Belast het proces daarom niet met andere I/O-bewerkingen die niet strikt noodzakelijk zijn.

Als het klaar is, voeg het dan weer toe aan je /etc/fstab-bestand, herstart de computer en geniet van je bestanden :-)