Byta ut en misslyckad enhet i en mdadm-array på Ubuntu
Publicerad: 15 februari 2025 kl. 22:02:35 UTC
Om du är i den fruktade situationen att ha ett diskfel i en mdadm RAID-array, förklarar den här artikeln hur du korrekt byter ut den på ett Ubuntu-system.
Replacing a Failed Drive in an mdadm Array on Ubuntu
Informationen i det här inlägget är baserad på Ubuntu 18.04 och versionen av mdadm som ingår i dess arkiv; i skrivande stund v4.1-rc1. Det kan eller kanske inte är giltigt för andra versioner.
Jag hade nyligen ett plötsligt diskfel i min hemfilserver, som består av nio enheter i en mdadm RAID-6-array. Det är alltid läskigt, men jag kunde lyckligtvis snabbt köpa en ersättningsenhet som levererades redan nästa dag så att jag kunde få igång återuppbyggnaden.
Jag var visserligen lite för billig när jag ursprungligen satte upp filservern; endast två av enheterna är faktiska NAS-enheter (Seagate IronWolf), medan resten är stationära enheter (Seagate Barracuda). Inte överraskande var det en av stationära enheter som hade gett upp (efter nästan tre års tjänst dock). Den var helt död; efter att ha flyttat den till en stationär USB-hölje var allt jag fick ut ur det ett irriterande klickljud och varken Ubuntu 20.04 eller Windows 10 kunde upptäcka det.
Nåväl, vidare till ersättningsdelen (och ja, den nya enheten jag köpte var en IronWolf, lärdomar) - lika läskigt som det är att förlora en enhet i en löpande array, det är ännu läskigare om du inte vet hur man ska byta ut den. Det är inte första gången jag har varit tvungen att byta ut en trasig enhet i en mdadm-array, men lyckligtvis är det så sällsynt att jag vanligtvis måste leta upp de rätta kommandona. Den här gången bestämde jag mig för att piska upp min egen lilla guide för framtida referens.
Så, först och främst, när du får det fruktade felhändelsen e-postmeddelande från mdadm, måste du identifiera vilken enhet som har misslyckats. Visst, det kommer att berätta enhetens namn (i mitt fall /dev/sdf), men det är förmodligen inte uppenbart vilken fysisk enhet som faktiskt är eftersom de namnen kan ändras när maskinen startas.
Om du inte ens är säker på vilket enhetsnamn som har misslyckats kan du använda följande kommando för att ta reda på det (ersätt /dev/md0 med din RAID-enhet):
Som sagt, i mitt fall var det /dev/sdf, så låt oss fortsätta med det.
Sedan kan du försöka hitta serienumret för den misslyckade enheten genom att utfärda detta kommando:
(om smartctl inte hittas måste du installera smartmontools-paketet på Ubuntu)
Serienumret kan sedan jämföras med serienumren på den fysiska etiketten på enheterna för att ta reda på vilken som har misslyckats.
Den här gången hade jag dock inte så stor tur. Enheten var helt död och vägrade till och med att tillhandahålla SMART eller annan data, inklusive serienumret.
Eftersom jag hade fysisk åtkomst till servern (som du verkligen behöver om du ska byta ut en fysisk enhet själv, antar jag ;-)) och servern faktiskt körde när disken misslyckades (och fortsatte att fungera bra tack vare RAID-6-redundansen), valde jag den riktigt primitiva, men faktiskt mycket effektiva och självklara metoden att helt enkelt kopiera en stor fil till servern och titta på vilken HDD som inte flimrade. Inom några sekunder hade jag identifierat den skyldige.
Nu, innan du drar ut den fysiska enheten, är det en bra idé att formellt informera mdadm om denna avsikt genom att utfärda det här kommandot (ersätt enhetsnamn med dina egna efter behov):
Vid framgång kommer mdadm att svara med ett meddelande som säger att den "hotmoved" hårddisken, uppenbarligen för att den virtuella raidenheten faktiskt körs just då.
Om det misslyckas med ett felmeddelande som liknar "enhet eller resurs upptagen", kan det vara så att mdadm faktiskt inte har registrerat enheten för att ha misslyckats helt. För att få det att göra det, utfärda det här kommandot (återigen, kom ihåg att ersätta enhetsnamn med dina egna efter behov):
Efter det bör du kunna ta bort enheten från arrayen med föregående kommando.
Nu är det dags att faktiskt byta ut enheten. Om du är riktigt, verkligen - typ, verkligen - säker på att din maskin och styrenhet stöder hot swapping, kan du göra detta utan att stänga av maskinen. Det skulle vara vägen att gå på kritiska produktionssystem som körs på riktig, riktig serverhårdvara som du med säkerhet vet kan hantera det. Min hemfilserver är baserad på ett skrivbordsmoderkort av konsumentklass med ett par semi-noname SATA-kontroller i PCIe-platserna för att ge fler SATA-portar.
Även om SATA i allmänhet borde stödja hot swapping, var jag inte på väg att riskera något i den här installationen, så jag valde att stänga av maskinen medan jag bytte ut enheten.
Innan du gör det är det en bra idé att kommentera raidenheten i filen /etc/fstab så att Ubuntu inte försöker montera den automatiskt vid nästa uppstart, eftersom den kan hänga sig och tvinga dig till återställningsläge på grund av den försämrade RAID-arrayen. Det kanske inte är ett stort problem om det är ett stationärt system, men jag kör den här servern utan skärm utan ansluten bildskärm eller tangentbord, så det här skulle vara lite krångligt.
Efter att ha startat upp maskinen med den glänsande nya enheten installerad, använd lsblk eller något annat sätt för att identifiera den. Om du inte har ändrat något annat kommer den förmodligen (men inte nödvändigtvis ) att få samma namn som den enhet du bytte ut. I mitt fall gjorde det det, så den nya heter också /dev/sdf.
Eftersom min array är baserad på partitioner snarare än fysiska enheter, behövde jag kopiera partitionstabellen från en fungerande enhet till den nya enheten för att se till att de är exakt likadana. Om du kör din array på fysiska enheter istället kan du hoppa över det här steget.
Jag använde sgdisk för detta ändamål och kopierade partitionstabellen från /dev/sdc till /dev/sdf. Se till att ersätta enhetsnamn så att de matchar dina egna.
Lägg märke till ordningen här: du listar "att" köra först! Detta är lite kontraintuitivt för mig, men se bara till att du får det rätt så att du inte får ett nytt diskfel i arrayen ;-)
För att undvika UUID-konflikter genererar du sedan nya UUID för den nya enheten:
Och nu är det äntligen dags att lägga till den nya enheten i arrayen och få igång återuppbyggnadsfesten! (Okej, det är inte riktigt en fest, det är faktiskt en ganska långsam och nervös process eftersom du verkligen, verkligen inte vill att en annan enhet misslyckas just nu. Öl kan dock hjälpa)
Hur som helst, för att lägga till den nya enheten till arrayen, utfärda det här kommandot (igen, se till att ersätta enhetsnamn med dina egna efter behov):
Om allt går bra kommer enheten att läggas till i arrayen utan hicka. Jag tror att den faktiskt läggs till som en "hot spare" som standard, men eftersom denna array saknar en disk (den som misslyckades), tas den omedelbart i bruk och återuppbyggnadsprocessen kommer att starta.
Du kan hålla ett öga på det så här:
Detta kommer förmodligen att ta ett tag; på min lågmälda server (till stor del baserad på konsumentklassad hårdvara och stationära enheter, märk väl) kunde den nå strax under 100 MB/sek. Kom ihåg att detta är RAID-6, så det är många paritetsberäkningar involverade i en ombyggnad; en RAID-10 skulle ha varit mycket snabbare. Denna speciella maskin har en AMD A10 9700E quad core CPU ("E" betyder att det är en underklockad energieffektiv modell, dvs inte supersnabb), bara för att ge dig en uppfattning om vad du kan förvänta dig. Med de nio 8 TB-enheterna i min installation tog den fullständiga ombyggnaden drygt 24 timmar.
Under ombyggnaden kan du montera filsystemet på arrayen och använda det som vanligt om du vill, men jag föredrar att lämna det till ombyggnaden tills det är klart. Tänk på att om en enhet misslyckas kan en annan snart följa, så du vill att återuppbyggnaden ska göras så snabbt som möjligt eftersom du verkligen inte vill att en annan enhet ska misslyckas under den tiden. Belasta den därför inte med annan IO som inte är strikt nödvändig.
När det är klart, lägg till det igen i din /etc/fstab-fil, starta om och njut av dina filer :-)