Miklix

Sikertelen meghajtó cseréje egy mdadm tömbben az Ubuntun

Megjelent: 2025. február 15. 22:02:20 UTC
Utolsó frissítés: 2026. január 12. 8:49:55 UTC

Ha abban a rettegett helyzetben vagy, hogy meghajtóhiba történik egy mdadm RAID tömbben, ez a cikk elmagyarázza, hogyan cserélheted ki helyesen egy Ubuntu rendszeren.


Ezt az oldalt angolból gépi fordítással készítettük, hogy minél több ember számára elérhető legyen. Sajnos a gépi fordítás még nem tökéletes technológia, ezért előfordulhatnak hibák. Ha szeretné, itt megtekintheti az eredeti angol nyelvű változatot:

Replacing a Failed Drive in an mdadm Array on Ubuntu

A bejegyzésben található információk az Ubuntu 18.04-en és az mdadm tárolóiban található verzióján alapulnak; a v4.1-rc1 verzióban, a bejegyzés írásakor. Előfordulhat, hogy más verziókra érvényesek, de előfordulhat, hogy nem.

Nemrég hirtelen meghajtóhiba történt az otthoni fájlszerveremben, ami kilenc meghajtóból áll egy mdadm RAID-6 tömbben. Ez mindig ijesztő, de szerencsére gyorsan sikerült beszereznem egy cseremeghajtót, amit már másnap kiszállítottak, így elkezdhettem az újjáépítést.

Elismerem, hogy egy kicsit túl spóroltam a fájlszerver eredeti beállításánál; a meghajtók közül csak kettő valódi NAS meghajtó (Seagate IronWolf), míg a többi asztali meghajtó (Seagate Barracuda). Nem meglepő módon ez volt az egyik olyan asztali meghajtó, amely feladta (bár majdnem három év szolgálat után). Teljesen halott volt; miután átraktam egy asztali USB-házba, csak egy idegesítő kattanó hangot hallottam belőle, és sem az Ubuntu 20.04, sem a Windows 10 nem tudta érzékelni.

Nos, akkor térjünk rá a cserealkatrészre (és igen, az újonnan vásárolt meghajtó egy IronWolf volt, tanultam a leckéből) – bármennyire is ijesztő elveszíteni egy meghajtót egy működő tömbben, még ijesztőbb, ha nem ismered a helyes csere eljárását. Nem ez az első alkalom, hogy egy mdadm tömbben kellett meghibásodott meghajtót cserélnem, de szerencsére olyan ritka, hogy általában meg kell keresnem a megfelelő parancsokat. Ezúttal úgy döntöttem, hogy összedobok egy saját kis útmutatót a későbbi felhasználáshoz.

Tehát, először is, amikor megkapod a rettegett hibaeseményről szóló e-mailt az mdadm-től, azonosítanod kell, hogy melyik meghajtó hibásodott meg. Persze, megmondja az eszköz nevét (az én esetemben /dev/sdf), de valószínűleg nem egyértelmű, hogy melyik fizikai meghajtóról van szó valójában, mivel ezek a nevek megváltozhatnak a gép indításakor.

Ha nem is biztos benne, hogy melyik eszköz neve hibásodott meg, a következő paranccsal megtudhatja (a /dev/md0 helyére írja be a RAID-eszköz nevét):

mdadm -–query -–detail /dev/md0

Ahogy említettem, az én esetemben ez a /dev/sdf volt, szóval folytassuk azzal.

Ezután megpróbálhatja megkeresni a hibás meghajtó sorozatszámát a következő parancs kiadásával:

smartctl -–all /dev/sdf | grep -i 'Serial'

(ha a smartctl nem található, telepítenie kell a smartmontools csomagot az Ubuntura)

A sorozatszám ezután összehasonlítható a meghajtók fizikai címkéjén található sorozatszámokkal, hogy kiderítsük, melyik hibásodott meg.

Ezúttal azonban nem voltam ilyen szerencsés. A meghajtó teljesen lemerült, és még a SMART vagy más adatok, beleértve a sorozatszámot is, megadására sem volt hajlandó.

Mivel fizikai hozzáférésem volt a szerverhez (amire valószínűleg nagy szükség van, ha valaki fizikai meghajtót cserél ;-)), és a szerver ténylegesen futott, amikor a lemez meghibásodott (és a RAID-6 redundanciának köszönhetően továbbra is jól futott), a nagyon primitív, de valójában nagyon hatékony és nyilvánvaló módszert választottam: egyszerűen átmásoltam egy nagy fájlt a szerverre, és figyeltem, melyik HDD jelzőfénye nem villog. Néhány másodpercen belül azonosítottam a hibásat.

Mielőtt kihúznánk a fizikai meghajtót, érdemes hivatalosan is tájékoztatni az mdadm-et erről a szándékról a következő parancs kiadásával (az eszközneveket szükség szerint cseréljük le a sajátunkra):

mdadm -–manage /dev/md0 -–remove /dev/sdf1

Siker esetén az mdadm egy üzenettel válaszol, hogy "forrón eltávolította" a meghajtót, nyilvánvalóan azért, mert a virtuális RAID eszköz éppen fut.

Ha a parancs a „eszköz vagy erőforrás foglalt”-hoz hasonló hibaüzenetet ad, akkor lehetséges, hogy az mdadm valójában nem regisztrálta a meghajtót teljes meghibásodásként. Ennek végrehajtásához add ki a következő parancsot (ismét ne felejtsd el a saját eszközneveket beírni):

mdadm --manage /dev/md0 --fail /dev/sdf

Ezután az előző paranccsal el kell tudni távolítani az eszközt a tömbből.

Itt az ideje, hogy ténylegesen kicseréljük a meghajtót. Ha nagyon, nagyon - úgymond, nagyon - biztos vagy benne, hogy a géped és a vezérlőd támogatja a hot swapping-et, akkor ezt megteheted a gép leállítása nélkül. Ez lenne a helyes út a kritikus éles rendszereknél, amelyek valódi, megfelelő szerverhardveren futnak, amiről biztosan tudod, hogy képes kezelni. Az otthoni fájlszerverem egy fogyasztói szintű asztali alaplapon alapul, néhány félig névtelen SATA vezérlővel a PCIe bővítőhelyeken, hogy több SATA portot biztosítsanak.

Bár a SATA-nak általában támogatnia kellene a hot swappet, ebben a beállításban nem akartam semmit kockáztatni, ezért úgy döntöttem, hogy leállítom a gépet a meghajtó cseréje közben.

Mielőtt ezt megtennéd, érdemes kikommentelni a raid eszközt az /etc/fstab fájlban, hogy az Ubuntu ne próbálja meg automatikusan csatolni a következő rendszerindításkor, mert a leromlott RAID tömb miatt lefagyhat és helyreállítási módba kényszeríthet. Ez asztali rendszeren nem jelenthet nagy problémát, de én ezt a szervert headless-sel, monitor és billentyűzet csatlakoztatása nélkül futtatom, szóval ez egy kicsit macerás lenne.

Miután a gépet a vadonatúj meghajtóval együtt elindítottad, használd az lsblk parancsot vagy valamilyen más módszert az azonosítására. Ha nem változtattál semmi mást, akkor valószínűleg (de nem feltétlenül) ugyanazt a nevet fogja kapni, mint a kicserélt meghajtó. Az én esetemben igen, így az új meghajtó neve is /dev/sdf.

Mivel a tömböm partíciókon, nem pedig fizikai eszközökön alapul, át kellett másolnom a partíciós táblát egy működő meghajtóról az új meghajtóra, hogy biztosan megegyezzenek. Ha a tömböt fizikai eszközökön futtatod, kihagyhatod ezt a lépést.

Erre a célra az sgdisk parancsot használtam, a partíciós táblát a /dev/sdc-ből a /dev/sdf-be másoltam. Ügyelj arra, hogy az eszközneveket a sajátoddal megegyezőre cseréld.

Figyelj a sorrendre: a "cél" meghajtót kell először felsorolni! Ez nekem kicsit ellentmondásos, de ügyelj arra, hogy jól csináld, nehogy újabb meghajtóhiba történjen a tömbben ;-)

sgdisk -R /dev/sdf /dev/sdc

Ezután az UUID-ütközések elkerülése érdekében generáljon új UUID-kat az új meghajtóhoz:

sgdisk -G /dev/sdf

És most végre elérkezett az idő, hogy hozzáadjuk az új meghajtót a tömbhöz, és elkezdjük az újjáépítési bulit! (Oké, ez nem igazán buli, hanem egy elég lassú és idegesítő folyamat, mivel nagyon-nagyon nem akarod, hogy egy újabb meghajtó meghibásodjon ebben a pillanatban. A sör talán segíthet.)

Mindenesetre az új meghajtó tömbhöz való hozzáadásához add ki ezt a parancsot (ismét ügyelj arra, hogy az eszközneveket a sajátoddal helyettesítsd):

mdadm -–manage /dev/md0 -–add /dev/sdf1

Ha minden jól megy, a meghajtó gond nélkül hozzáadódik a tömbhöz. Úgy hiszem, alapértelmezés szerint "tartalékként" van hozzáadva, de mivel ebből a tömbből hiányzik egy lemez (az, amelyik meghibásodott), azonnal használatba kerül, és megkezdődik az újjáépítési folyamat.

Így tudod szemmel tartani:

watch cat /proc/mdstat

Ez valószínűleg eltart egy ideig; az én szerény szerveremen (ami nagyrészt fogyasztói szintű hardvereken és asztali meghajtókon alapult, ne feledd) alig 100 MB/s alatti sebességet tudott elérni. Ne feledd, hogy ez RAID-6, így sok paritásszámítással kell számolni az újraépítés során; egy RAID-10 sokkal gyorsabb lett volna. Ebben a konkrét gépben egy AMD A10 9700E négymagos CPU található (az "E" azt jelenti, hogy ez egy alulórajelzett energiatakarékos modell, azaz nem szupergyors), csak hogy legyen elképzelésed arról, mire számíthatsz. A kilenc darab 8 TB-os meghajtóval a rendszeremben a teljes újraépítés alig több mint 24 órát vett igénybe.

Az újraépítés során felcsatolhatod a fájlrendszert a tömbre és a szokásos módon használhatod, ha szeretnéd, de én inkább az újraépítésre hagyom, amíg az be nem fejeződik. Ne feledd, hogy ha az egyik meghajtó meghibásodik, egy másik hamarosan követheti, ezért a lehető leggyorsabban szeretnéd elvégezni az újraépítést, mivel nem szeretnéd, hogy egy másik meghajtó meghibásodjon közben. Ezért ne terheld olyan egyéb I/O-val, ami nem feltétlenül szükséges.

Ha kész, add vissza az /etc/fstab fájlodhoz, indítsd újra a gépet, és élvezd a fájljaidat :-)

Oszd meg a Bluesky-nOszd meg a FacebookonOszd meg a LinkedIn-enOszd meg a Tumblr-enOszd meg X-enOszd meg a LinkedIn-enPin a Pinteresten

Mikkel Christensen

A szerzőről

Mikkel Christensen
Mikkel a miklix.com létrehozója és tulajdonosa. Több mint 20 éves tapasztalattal rendelkezik, mint hivatásos számítógépes programozó/szoftverfejlesztő, és jelenleg teljes munkaidőben dolgozik egy nagy európai informatikai vállalatnál. Amikor nem blogol, szabadidejét érdeklődési körének, hobbijainak és tevékenységeinek széles skálájával tölti, ami bizonyos mértékig tükröződhet a weboldalon tárgyalt témák sokféleségében.