Hoe vervang je een defecte harde schijf in een Linux RAID-array?

Wanneer een harde schijf in een Linux RAID-configuratie defect raakt , is paniek begrijpelijk: de server reageert niet meer, het systeem start niet meer op of de opslagpool komt in de status "NIET BESCHIKBAAR" terecht. Het goede nieuws is dat, mits de RAID correct is geconfigureerd en u er zorgvuldig mee omgaat, u de defecte schijf kunt vervangen en de gegevens kunt herstellen zonder verlies.

In dit artikel zullen we op een zeer gedetailleerde en praktische manier bekijken hoe u een defecte schijf kunt identificeren, hoe u deze met mdadm uit een software-RAID kunt verwijderen , hoe u omgaat met meer delicate gevallen zoals een ZFS-pool die niet wil importeren vanwege een gebrek aan replica's, wat er gebeurt wanneer u schijven probeert te lezen in Windows met WSL2 en XFS, en hoe u omgaat met scenario's waarbij de RAID-schijven verschillende groottes hebben en u vervolgens de resterende ruimte wilt benutten.

Basisbegrippen: Software-RAID in Linux (mdadm, ZFS, RAID-typen)

Voordat we ergens mee gaan experimenteren, is het belangrijk om een ​​aantal fundamentele concepten over RAID in Linux te begrijpen . Dit voorkomt onaangename verrassingen en onherstelbare fouten wanneer het tijd is om een ​​beschadigde schijf te vervangen.

De meeste traditionele Linux-servers gebruiken software-RAID op basis van mdadm . Dit systeem creëert virtuele /dev/mdX-apparaten (bijvoorbeeld /dev/md0, /dev/md1, enz.) die zijn opgebouwd uit fysieke partities zoals /dev/sda1, /dev/sdb2, enz. Bestandssystemen zoals ext4, XFS of andere worden op deze /dev/mdX-apparaten gemount.

Een ander, en steeds vaker voorkomend, geval is het gebruik van ZFS als bestandssysteem en volumemanager . ZFS is niet afhankelijk van mdadm, maar beheert zijn eigen redundantie met behulp van vdevs (mirrors, RAIDZ, enz.). Wanneer een schijf in ZFS uitvalt, wordt het vervangings- en herstelproces afgehandeld met commando's zoals zpool , en niet met mdadm.

Het is ook belangrijk om RAID niet te verwarren met back-ups: RAID biedt redundantie en continuïteit van de dienstverlening , maar het vervangt geen back-up. Een RAID 1-array kan je redden als een schijf uitvalt, maar niet als je per ongeluk gegevens verwijdert of als de volledige logische structuur van het bestandssysteem beschadigd raakt.

Bij veel providers (zoals Hetzner en andere gespecialiseerde aanbieders) worden systeemimages al geleverd met een vooraf geconfigureerde softwarematige RAID1 op twee schijven, verdeeld in verschillende partities: swap, /boot, de root / en soms /home, elk met een bijbehorende /dev/mdX-partitie.

Hoe controleer ik de status van een software-RAID met mdadm?

Als je vermoedt dat een van je schijven begint te haperen, is de eerste stap om precies te achterhalen wat er in de RAID-array gebeurt . Hiervoor heb je een aantal basistools tot je beschikking waarmee je vertrouwd moet zijn.

Een zeer nuttig commando is `lsblk` , waarmee je kunt zien hoe de schijven, partities en RAID-apparaten op het systeem georganiseerd zijn. Met één commando kun je zien welke fysieke schijven aanwezig zijn en hoe ze zich verhouden tot `/dev/mdX`.

Voorbeeld van de uitvoer van lsblk (vereenvoudigd):

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop1 7:1 0 110.6M 1 loop /snap/core/...
sda 8:0 0 3.6T 0 disk
├─sda1 8:1 0 16G 0 part └─md0 9:0 0 16G 0 raid1
├─sda2 8:2 0 512M 0 part └─md1 9:1 0 511M 0 raid1 /boot
├─sda3 8:3 0 2T 0 part └─md2 9:2 0 2T 0 raid1 /
└─sda4 8:4 0 1.7T 0 part └─md3 9:3 0 1.7T 0 raid1 /home
sdb 8:16 0 3.6T 0 disk
├─sdb1 8:17 0 16G 0 part └─md0 9:0 0 16G 0 raid1
├─sdb2 8:18 0 512M 0 part └─md1 9:1 0 511M 0 raid1 /boot
├─sdb3 8:19 0 2T 0 part └─md2 9:2 0 2T 0 raid1 /
└─sdb4 8:20 0 1.7T 0 part └─md3 9:3 0 1.7T 0 raid1 /home

Met deze structuur zie je dat er twee schijven zijn, sda en sdb, en dat elke partitie van sda een spiegelbeeld heeft in sdb, waardoor de arrays md0, md1, md2 en md3 ontstaan. In zo'n omgeving zou, als een van de schijven uitvalt, de andere schijf alle informatie moeten blijven bevatten.

Om dieper in een specifieke array te duiken, gebruikt u `mdadm --detail` . Bijvoorbeeld om de status van `/dev/md0` te bekijken:

mdadm --detail /dev/md0

De uitvoer bevat gegevens zoals RAID-niveau, grootte, aantal actieve schijven en tot slot een tabel met de apparaten waaruit de array bestaat. Je ziet dan zoiets als dit:

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1

In deze tabel kunt u zien of een partitie is gemarkeerd als defect , "verwijderd" of dat er een schijf ontbreekt. Deze informatie is essentieel om te weten welke schijf vervangen moet worden of welke verwijderd kan worden zonder het systeem te beschadigen.

Een gezonde schijf uit een RAID-array verwijderen (bijvoorbeeld in dedicated servers).

In sommige gevallen is er geen sprake van een fysieke schijfstoring; u wilt simpelweg een van de schijven in de RAID-array vrijmaken voor een ander doel: onafhankelijke opslag, back-ups, enzovoort. Dit komt vaak voor bij dedicated servers waar de provider standaard een RAID 1-configuratie installeert, maar u de tweede schijf vrij wilt hebben.

Het idee is als volgt: markeer de partities op die schijf als defect in elke array, verwijder ze uit de RAID en pas vervolgens het aantal apparaten aan zodat mdX niet langer op die tweede schijf hoeft te wachten. Het systeem blijft functioneren met een RAID met één schijf, wat eigenlijk een pseudo-RAID is, maar je bespaart wel een herinstallatie.

Het proces moet worden herhaald voor elke betrokken mdX-array (swap, /boot, /, /home…). Laten we het stap voor stap bekijken voor md0, wetende dat je hetzelfde moet doen voor md1, md2, enzovoort.

1. Bekijk de partitie die bij de array betrokken is.

Controleer eerst uit welke fysieke partities /dev/md0 bestaat:

mdadm -D /dev/md0

Aan het einde van de uitgang ziet u zoiets als:

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1

Als het uw doel is om de sdb-schijf uit de RAID te verwijderen, dan laat die tabel zien dat u actie moet ondernemen op /dev/sdb1 in het geval van md0, op /dev/sdb2 in het geval van md1, enzovoort.

2. Markeer de partitie als defect

Met mdadm kun je een partitie die als gezond wordt beschouwd niet zomaar verwijderen; je moet deze eerst als defect markeren. Dit beschadigt de schijf niet fysiek, het geeft de array alleen de opdracht om die replica niet meer te gebruiken.

Voorbeeld voor md0 en sdb1:

mdadm /dev/md0 --fail /dev/sdb1

Het gebruikelijke antwoord zal iets zijn als "set /dev/sdb1 faulty in /dev/md0". Vanaf dat moment weet de array dat deze replica niet langer betrouwbaar is en plaatst deze in een foutstatus.

3. Verwijder de defecte partitie uit de array.

Zodra een partitie als defect is gemarkeerd, kunt u deze uit de RAID verwijderen.

mdadm /dev/md0 --remove /dev/sdb1

Hierdoor zal mdadm de fysieke partitie van de array "ontkoppelen". Logischerwijs blijft md0 bestaan, maar er wordt alleen nog een back-up van gemaakt via /dev/sda1.

4. Pas het aantal RAID-apparaten aan.

Op dit punt kan md0 in een verslechterde toestand blijven als het nog steeds denkt dat er twee apparaten zouden moeten zijn. Om het systeem als stabiel te beschouwen, moet u het verwachte aantal schijven in de array wijzigen:

mdadm --grow /dev/md0 --raid-devices=1 --force

Hoewel het woord "groeien" wellicht uitbreiding suggereert, wijzigt u in deze context de interne configuratie om de array te laten weten dat er nu slechts één actief apparaat zal zijn.

Nadat u dit proces op alle mdX-schijven hebt herhaald, kunt u de server opnieuw opstarten. Het resultaat is een systeem dat opstart met een software-RAID met één schijf, terwijl de andere schijf volledig vrij is om naar wens te partitioneren en formatteren .

Het daadwerkelijk vervangen van een defecte schijf in een mdadm RAID-systeem.

Als het probleem niet is dat je een schijf wilt vrijmaken, maar dat er daadwerkelijk een schijf defect is geraakt , is de procedure vergelijkbaar, maar met enkele belangrijke verschillen: in plaats van slechts één schijf te behouden, is het de bedoeling de beschadigde schijf te vervangen door een nieuwe en de RAID-configuratie opnieuw op te bouwen.

In algemene termen zou de cyclus er als volgt uitzien:

• Identificeer welke schijf defect is (smartctl, kernelberichten, mdadm –detail).
• Markeer de partities op die schijf als defect in elk mdX-bestand.
• Verwijder ze uit de RAID met mdadm –remove.
• Vervang de defecte schijf fysiek door een nieuwe.Voorkom oplichting bij het kopen van platen.).
• Partitioneer de nieuwe schijf zodanig dat de partities qua grootte en type overeenkomen met die van de gezonde schijf.
• Voeg de nieuwe partities toe aan elke /dev/mdX met mdadm –add en laat het systeem opnieuw opbouwen.

met mdadm –detail /dev/md0 U kunt de status van het herstelproces controleren en zien wanneer alle schijven weer actief en gesynchroniseerd zijn. U kunt het proces ook volgen met watch -n1 cat /proc/mdstatwaardoor de voortgangsbalk van de synchronisatie elke seconde wordt vernieuwd.

Bij geavanceerdere configuraties (zoals RAID 5 of RAID 6) geldt hetzelfde principe, maar het uitvallen van meerdere schijven tegelijk kan catastrofale gevolgen hebben. Daarom is het cruciaal om een ​​schijf die begint te falen snel te vervangen voordat een andere schijf uitvalt.

Een nieuwe RAID-array aanmaken en beheren (bijvoorbeeld RAID6 met mdadm).

Hoewel het doel hier is om defecte schijven te vervangen, is het nuttig om te zien hoe een RAID-array vanaf nul wordt opgebouwd om te begrijpen wat er wordt gewijzigd wanneer een schijf wordt vervangen. Een typisch voorbeeld is het creëren van een RAID 6-array met meerdere schijven met behulp van mdadm.

De eerste stap is ervoor te zorgen dat mdadm op het systeem is geïnstalleerd. Op Debian/Ubuntu doe je dit met:

sudo apt-get install mdadm

In systemen zoals Red Hat zou het equivalente commando zijn:

sudo yum install mdadm

Voordat u de array aanmaakt, is het raadzaam te controleren of de schijven niet al superblocks bevatten van oude RAID-configuraties. Dit kunt u doen door de potentiële schijven of partities te onderzoeken:

sudo mdadm -E /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

Als er geen eerdere handtekening verschijnt, is de volgende stap het partitioneren van elke schijf met fdisk (of parted) door een primaire RAID-partitie (code fd) aan te maken. De gebruikelijke volgorde in fdisk is: nieuwe partitie aanmaken (n), primair (p), nummer kiezen, standaardsectoren accepteren, type wijzigen (t), code fd selecteren en wijzigingen opslaan (w).

Zodra alle partities zijn voorbereid, wordt de array aangemaakt:

sudo mdadm --create /dev/md0 --level=6 --raid-devices=5 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Hiermee wordt /dev/md0 als een RAID6-array met vijf partities aangemaakt. De array wordt automatisch opnieuw opgebouwd en u kunt de voortgang volgen met:

watch -n1 cat /proc/mdstat

Zodra de RAID gereed is, moet u het bestandssysteem aanmaken , bijvoorbeeld ext4:

sudo mkfs.ext4 /dev/md0

Vervolgens wordt het gekoppeld aan een map, bijvoorbeeld /mnt/Raid6:

sudo mkdir -p /mnt/Raid6
sudo mount /dev/md0 /mnt/Raid6/

Om ervoor te zorgen dat het automatisch bij het opstarten wordt aangekoppeld, wordt een regel toegevoegd aan /etc/fstab, zoiets als dit:

/dev/md0 /mnt/raid6 ext4 defaults 0 0

En om te voorkomen dat de arrayconfiguratie verloren gaat, wordt het mdadm-configuratiebestand gegenereerd:

sudo mdadm --detail --scan --verbose >> /etc/mdadm.conf

RAID testen door een schijfstoring te veroorzaken

Voordat u uw gegevens toevertrouwt aan een nieuw gecreëerde RAID-array, is het raadzaam te controleren of deze zich naar behoren gedraagt ​​in geval van een storing . De veiligste manier om dit te doen is door de storing van een van de schijven te simuleren met mdadm, zonder de fysieke hardware aan te raken.

Stel dat u een RAID-array hebt met /dev/sdb1, /dev/sdc1 en een reserveschijf /dev/sdg1. U kunt de logische fout van /dev/sdc1 forceren met:

sudo mdadm --manage --fail /dev/md0 /dev/sdc1

Controleer vervolgens de details van de array:

sudo mdadm --detail /dev/md0

Tijdens het opstarten zou u moeten zien dat de schijf die als defect was gemarkeerd, is gewist en vervangen door de reserveschijf, die vervolgens begint met synchroniseren. Dit is het beste bewijs dat de RAID goed reageert op een incident in de praktijk.

Bijzondere gevallen: problemen met ZFS wanneer een schijf in de pool uitvalt.

In modernere omgevingen, met name bij hypervisors zoals Proxmox, wordt ZFS gebruikt om schijven te beheren in pools met ingebouwde redundantie . Een typisch voorbeeld: je hebt een gespiegelde ZFS-pool (RAID 1), een van de twee schijven valt uit en plotseling start de server niet meer op omdat de rootpool niet kan worden geïmporteerd.

In die situatie, wanneer u de pool handmatig probeert te importeren, kunt u berichten tegenkomen zoals:

zpool import -f rpool
cannot import 'rpool': no such pool or dataset
Destroy and recreate the pool from a backup source

Of probeer andere opties:

zpool import -N

Het retourneert een UNAVAIL-status en geeft aan "onvoldoende replica's" en "beschadigde apparaten of gegevens". Kortom, ZFS ziet onvoldoende geldige kopieën om de integriteit van de pool te garanderen en weigert deze daarom op de standaardmanier te importeren.

In deze gevallen is het cruciaal om niet te veel willekeurige commando's te improviseren. Enkele punten om in gedachten te houden:

• Als de mirror correct is gemonteerd, zou één gezonde schijf voldoende moeten zijn om de pool in de gedegradeerde modus te importeren. Als ZFS onvoldoende mirrors meldt, kan er sprake zijn van ernstige corruptie of een slechte apparaatdetectie.
• Je kunt ZFS niet rechtstreeks "vertellen" om een ​​defecte schijf te vervangen door een andere als de pool niet kan worden geïmporteerd; het is niet zoals mdadm, waar je op partitieniveau werkt zonder het bestandssysteem te mounten.
• Het verstandigst is meestal om een ​​importproduct te proberen. geforceerd en alleen-lezen Gebruik geavanceerde vlaggen (bijv. -F, -o readonly=on) om te controleren welke datasets herstelbaar zijn en kopieer de gegevens indien mogelijk.
• Als de pool echt op geen enkele manier geïmporteerd kan worden, is de volgende logische stap het klonen of block image maken van de nog werkende schijf, om die "back-up" te bewaren voordat er verder geëxperimenteerd wordt.

Het grootste probleem in een scenario zoals hierboven beschreven (waarbij de werkende schijf ook de enige plek is waar de gegevens zijn opgeslagen) is dat er geen extra vangnet is . Daarom is het het beste om agressieve reparatiepogingen te staken en je eerst te concentreren op het redden van de inhoud van de nog functionerende schijf, zelfs als deze zich buiten ZFS bevindt.

Een Linux RAID-array (XFS, ext4) uitlezen vanuit Windows met WSL2

Een ander veelvoorkomend scenario is dat iemand een schijf uit een Linux-server verwijdert en de gegevens ervan wil lezen vanaf een Windows-pc . Op het eerste gezicht lijkt dit eenvoudig: je sluit de schijf aan via USB, gebruikt een programma zoals Linux Reader, en klaar. Maar wanneer die schijf deel uitmaakt van een software-RAID, wordt het ingewikkelder.

In het specifieke geval van een schijf met een GPT-tabel waarbij alle partities als "Linux RAID" worden weergegeven, weten Windows en veel grafische hulpprogramma's er niet mee om te gaan. Fdisk zou bijvoorbeeld zoiets als dit kunnen weergeven:

Device Start End Sectors Size Type
/dev/sdd1 1032192 5031935 3999744 1.9G Linux RAID
/dev/sdd2 5031936 9031679 3999744 1.9G Linux RAID
/dev/sdd3 30720 1032191 1001472 489M Linux RAID
/dev/sdd4 9031680 3907028991 3897997312 1.8T Linux RAID

Als er zich bijvoorbeeld in /dev/sdd4 een XFS-bestandssysteem bevindt dat deel uitmaakt van een mdadm-array, leidt een poging om dit rechtstreeks te mounten meestal tot iets als:

mount -t xfs /dev/sdd4 /mnt/tempdisk
mount: wrong fs type, bad superblock on /dev/sdd4...

Of als je het probeert zonder het FS-type te specificeren:

mount /dev/sdd4 /mnt/tempdisk
mount: unknown filesystem type 'linux_raid_member'

Deze berichten geven aan dat /dev/sdd4 geen zelfstandig bestandssysteem is , maar onderdeel uitmaakt van een RAID-array. Het "echte" bestandssysteem bevindt zich op /dev/mdX, dat in deze context nog niet bestaat. Om de inhoud vanuit WSL2 (bijvoorbeeld Ubuntu) te lezen, moet u het volgende doen:

• Laad de mdadm-modules in de WSL2-kernel als ze nog niet geladen zijn.
• gebruik mdadm –onderzoeken op RAID-partities om de array te identificeren waartoe ze behoren.
• Maak de mdX-array opnieuw aan in de "assemble"-modus (mdadm –assemble) zodat /dev/md0 (of de array die het zou moeten zijn) verschijnt.
• Zodra /dev/md0 bestaat, koppelt u dat apparaat met het juiste bestandssysteemtype (XFS, ext4, enz.).

Zonder de RAID-configuratiefase te doorlopen, kunt u partities die als Linux RAID zijn gemarkeerd niet rechtstreeks koppelen , zelfs niet als u weet dat ze een XFS-bestandssysteem bevatten. En in native Windows is het, afgezien van zeer specifieke tools (meestal betaalde of alleen-lezen tools), moeilijk om deze gevallen effectief af te handelen.

RAID met schijven van verschillende groottes en gebruik van de resterende ruimte.

Een merkwaardig, maar steeds vaker voorkomend geval is dat iemand een RAID 1-array opzet met twee schijven van zeer verschillende groottes , bijvoorbeeld een NVMe-schijf van 1 TB en een SATA-schijf van 500 GB. In noodsituaties zou dit acceptabel kunnen zijn, maar de RAID 1 zal voor de spiegeling alleen de capaciteit van de kleinere schijf benutten.

In dat scenario zal het typische resultaat zijn dat de "tweede helft" van de 1 TB-schijf ongebruikt blijft, simpelweg omdat RAID 1 beperkt is tot de eerste 500 GB (de grootte van de kleinere schijf). Dat gedeelte maakt geen deel uit van de array en blijft ongebruikte ruimte of staat op een aparte partitie.

Stel dat u nu besluit het goed aan te pakken en de kleine schijf wilt vervangen door een andere, identieke 1 TB-schijf. De procedure voor het vervangen van een schijf in mdadm is vergelijkbaar met wat al is beschreven: de oude schijf wordt gemarkeerd als defect, verwijderd uit de array, de nieuwe schijf wordt geplaatst, de bijbehorende partities worden aangemaakt en de schijf wordt toegevoegd aan de RAID-array om opnieuw te worden opgebouwd.

De volgende vraag is: hoe kun je de extra ruimte die je nu op beide schijven hebt benutten om bijvoorbeeld de rootpartitie (/) met ongeveer 500 GB uit te breiden? Over het algemeen worden hiervoor de volgende stappen gevolgd:

• Vergroot de RAID-partities op beide schijven zodat ze de extra ruimte benutten (gebruik hiervoor tools zoals parted of fdisk, en wees altijd uiterst voorzichtig).
• gebruik mdadm – groeien over de mdX-array om deze te laten weten dat de effectieve grootte ervan nu groter is.
• Zodra het RAID-apparaat meer capaciteit heeft, kunt u het bestandssysteem erboven vergroten (bijvoorbeeld door ext4 uit te breiden met resize2fs; zie Hoe maak je schijfruimte vrij in Linux?).

Dit soort bewerkingen, met name die waarbij de rootpartitie en UEFI/EFI, swap en andere componenten betrokken zijn, vereisen aanpassingen aan de partitietabel, RAID-array en bestandssystemen. Het is ten zeerste aan te raden om recente back-ups te hebben en een grondig begrip te hebben van hoe de EFI-partities en swap zijn geconfigureerd om te voorkomen dat het systeem niet meer opstart.

Als alles correct is gedaan, zouden noch de swap-partitie noch de EFI-partitie verkeerd geconfigureerd mogen raken. Echter, fouten in sectornummers, partitievolgorde of apparaten die geregistreerd staan ​​in /etc/fstab en de bootloader kunnen ertoe leiden dat het systeem in de "herstelmodus" terechtkomt en om handmatige reparaties vraagt.

Samenvattend is het gebruik van schijven van verschillende groottes in RAID1 op korte termijn weliswaar mogelijk, maar wordt het op middellange tot lange termijn afgeraden, omdat het toekomstig ruimtebeheer aanzienlijk bemoeilijkt wanneer men de hardware wil uniformeren.

Na dit alles is de belangrijkste conclusie dat het vervangen van een defecte schijf in een Linux RAID geen toverkunst is, maar wel een methodische aanpak vereist: eerst de RAID-topologie begrijpen (mdadm of ZFS); vervolgens vaststellen welke schijf of partitie moet worden aangepakt; en ten slotte de juiste commando's (mdadm –fail, –remove, –add, zpool import, enz.) met een koel hoofd uitvoeren. Met een goed georganiseerde strategie, goede back-ups en een geduldige aanpak kunt u de meeste situaties succesvol oplossen, van het vrijmaken van een schijf op een dedicated server tot het herstellen van een defecte ZFS-pool of het proberen om gegevens van Windows via WSL2 terug te halen.