Miklix

Zamenjava okvarjenega pogona v matriki mdadm na Ubuntu

Objavljeno: 15. februar 2025 ob 10:02:34 pop. UTC
Nazadnje posodobljeno: 12. januar 2026 ob 8:50:03 dop. UTC

Če se znajdete v strašni situaciji, ko vam v RAID polju mdadm pride do okvare pogona, vam bo ta članek razložil, kako ga pravilno zamenjati v sistemu Ubuntu.


Ta stran je bila strojno prevedena iz angleščine, da bi bila dostopna čim večjemu številu ljudi. Žal strojno prevajanje še ni popolna tehnologija, zato lahko pride do napak. Če želite, si lahko izvirno angleško različico ogledate tukaj:

Replacing a Failed Drive in an mdadm Array on Ubuntu

Informacije v tej objavi temeljijo na Ubuntu 18.04 in različici mdadm, ki je vključena v njegove repozitorije; v času pisanja v4.1-rc1. Morda veljajo za druge različice ali pa ne.

Pred kratkim se mi je v domačem datotečnem strežniku, ki ga sestavlja devet diskov v polju RAID-6 mdadm, nenadoma pokvaril disk. To je vedno strašljivo, a na srečo sem hitro našel nadomestni disk, ki je bil dostavljen že naslednji dan, tako da sem lahko začel z obnovo.

Priznam, da sem bil pri prvotni nastavitvi datotečnega strežnika nekoliko preveč skopuh; le dva diska sta dejanska NAS diska (Seagate IronWolf), ostali pa so namizni diski (Seagate Barracuda). Ni presenetljivo, da je bil to eden od namiznih diskov, ki je odpovedal (čeprav po skoraj treh letih delovanja). Bil je popolnoma mrtev; po prestavitvi v namizno ohišje USB sem iz njega slišal le moteč klikajoč zvok, ki ga niti Ubuntu 20.04 niti Windows 10 nista mogla zaznati.

No, pa k nadomestnemu delu (in ja, novi disk, ki sem ga kupil, je bil IronWolf, lekcija se je naučila) - čeprav je strašljivo izgubiti disk v delujočem polju, je še bolj strašljivo, če ne poznate pravilnega postopka za njegovo zamenjavo. Ni prvič, da sem moral zamenjati okvarjen disk v polju mdadm, a na srečo je to tako redko, da moram običajno poiskati ustrezne ukaze. Tokrat sem se odločil, da za prihodnjo uporabo sestavim svoj kratek vodnik.

Najprej, ko od mdadm prejmete strašno e-pošto o napaki, morate ugotoviti, kateri disk je odpovedal. Seveda vam bo povedal ime naprave (v mojem primeru /dev/sdf), vendar verjetno ni očitno, kateri fizični disk dejansko je to, saj se ta imena lahko spremenijo, ko se računalnik zažene.

Če niste prepričani, katera naprava je odpovedala, lahko to ugotovite z naslednjim ukazom (zamenjajte /dev/md0 z vašo napravo RAID):

mdadm -–query -–detail /dev/md0

Kot že omenjeno, je bil v mojem primeru to /dev/sdf, zato nadaljujmo s tem.

Nato lahko poskusite najti serijsko številko okvarjenega pogona tako, da izdate ta ukaz:

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

(če smartctl ni najden, morate v Ubuntu namestiti paket smartmontools)

Serijsko številko je nato mogoče primerjati s serijskimi številkami na fizični nalepki na pogonih, da se ugotovi, kateri je odpovedal.

Tokrat pa nisem imel te sreče. Disk je bil popolnoma mrtev in celo ni hotel posredovati SMART ali drugih podatkov, vključno s serijsko številko.

Ker sem imel fizični dostop do strežnika (kar verjetno res potrebuješ, če boš sam zamenjal fizični disk ;-)) in je strežnik dejansko deloval, ko je disk odpovedal (in je še naprej deloval brezhibno zaradi redundance RAID-6), sem se odločil za res primitivno, a pravzaprav zelo učinkovito in očitno metodo, da preprosto kopiram veliko datoteko na strežnik in opazujem, katera lučka trdega diska ne utripa. V nekaj sekundah sem prepoznal krivca.

Preden izvlečete fizični pogon, je dobro, da o tej nameri uradno obvestite mdadm z izdajo tega ukaza (imena naprav po potrebi zamenjajte s svojimi):

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

V primeru uspeha bo mdadm odgovoril s sporočilom, da je disk "vroče odstranil", očitno zato, ker naprava virtualni RAID v tistem trenutku dejansko deluje.

Če ne uspe in prikaže sporočilo o napaki, podobno kot »naprava ali vir zaseden«, je možno, da mdadm v resnici ni registriral pogona kot popolnoma neuspešnega. Če želite to storiti, izdajte ta ukaz (ponovno ne pozabite ustrezno zamenjati imen naprav s svojimi):

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

Po tem bi morali biti sposobni odstraniti napravo iz polja s prejšnjim ukazom.

Zdaj je čas, da dejansko zamenjate pogon. Če ste res, res – res, res – prepričani, da vaš računalnik in krmilnik podpirata vročo zamenjavo, lahko to storite, ne da bi izklopili računalnik. To bi bil pravilen način za kritične produkcijske sisteme, ki delujejo na pravi, ustrezni strežniški strojni opremi, za katero zagotovo veste, da jo lahko obvladuje. Moj domači datotečni strežnik pa temelji na matični plošči za namizne računalnike potrošniškega razreda z nekaj napol brezimenskimi krmilniki SATA v režah PCIe, ki zagotavljajo več vrat SATA.

Čeprav bi SATA na splošno moral podpirati vročo zamenjavo, pri tej nastavitvi nisem hotel tvegati, zato sem se odločil, da med zamenjavo pogona izklopim računalnik.

Pred tem je dobro, da napravo RAID v datoteki /etc/fstab zakomentirate, da Ubuntu ne bo poskušal samodejno priklopiti naprave ob naslednjem zagonu, saj se lahko zaradi okvarjenega polja RAID zatakne in vas prisili v način za obnovitev. To morda ne bo velik problem, če gre za namizni sistem, vendar jaz ta strežnik uporabljam brez povezave, brez priključenega monitorja ali tipkovnice, zato bi bilo to nekoliko težavno.

Ko zaženete računalnik z nameščenim novim pogonom, ga identificirajte z ukazom lsblk ali na kakšen drug način. Če niste spremenili ničesar drugega, bo verjetno (vendar ne nujno) dobil isto ime kot pogon, ki ste ga zamenjali. V mojem primeru ga je dobil, zato se novi imenuje tudi /dev/sdf.

Ker moja tabela temelji na particijah in ne na fizičnih napravah, sem moral kopirati tabelo particij z delujočega diska na nov disk, da bi se prepričal, da sta popolnoma enaki. Če svojo tabelo namesto tega zaženete na fizičnih napravah, lahko ta korak preskočite.

Za ta namen sem uporabil sgdisk in kopiral tabelo particij iz /dev/sdc v /dev/sdf. Imena naprav ustrezno zamenjajte z vašimi.

Bodite pozorni na vrstni red: najprej navedete pogon "do"! To se mi zdi nekoliko nelogično, ampak poskrbite, da boste pravilno navedli, da ne boste imeli še ene okvare pogona v matriki ;-)

sgdisk -R /dev/sdf /dev/sdc

Nato, da se izognete konfliktom UUID-jev, ustvarite nove UUID-je za novi pogon:

sgdisk -G /dev/sdf

In končno je prišel čas, da v polje dodamo nov disk in začnemo obnovo! (V redu, to ni ravno zabava, ampak precej počasen in mučen postopek, saj si res, res ne želite, da bi vam v tem trenutku odpovedal še en disk. Morda pa bi pomagalo pivo.)

Kakorkoli že, če želite dodati nov pogon v polje, izdajte ta ukaz (ponovno se prepričajte, da imena naprav ustrezno zamenjate s svojimi):

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

Če bo vse potekalo po sreči, bo disk brez težav dodan v polje. Mislim, da je privzeto dodan kot "vroča rezerva", vendar ker temu polju manjka disk (tisti, ki je odpovedal), se takoj uporabi in začne se postopek obnove.

Lahko ga spremljate takole:

watch cat /proc/mdstat

To bo verjetno trajalo nekaj časa; na mojem skromnem strežniku (ki temelji predvsem na strojni opremi potrošniškega razreda in namiznih diskih) je dosegel nekaj manj kot 100 MB/s. Upoštevajte, da gre za RAID-6, zato je pri obnovi potrebnih veliko izračunov paritete; RAID-10 bi bil veliko hitrejši. Ta stroj ima štirijedrni procesor AMD A10 9700E ("E" pomeni, da gre za energetsko učinkovit model s prenizko taktirano hitrostjo, tj. ni super hiter), samo da si predstavljate, kaj lahko pričakujete. Z devetimi 8-TB diski v moji konfiguraciji je celotna obnova trajala nekaj več kot 24 ur.

Med obnovo lahko datotečni sistem priklopite na polje in ga uporabljate kot običajno, če želite, vendar jaz raje prepuščam obnovo, dokler ni končana. Upoštevajte, da če en disk odpove, lahko kmalu sledi drug, zato želite, da se obnova izvede čim hitreje, saj resnično ne želite, da med tem odpove še en disk. Zato ga ne obremenjujte z drugimi V/I operacijami, ki niso nujno potrebne.

Ko je končano, ga dodajte nazaj v datoteko /etc/fstab, znova zaženite računalnik in uživajte v datotekah :-)

Delite na BlueskyDelite na FacebookuDelite na LinkedInuDelite na TumblrDelite na XDelite na LinkedInuPripni na Pinterest

Mikkel Christensen

O avtorju

Mikkel Christensen
Mikkel je avtor in lastnik spletne strani miklix.com. Ima več kot 20 let izkušenj kot profesionalni računalniški programer/razvijalec programske opreme in je trenutno za polni delovni čas zaposlen v veliki evropski IT korporaciji. Kadar ne piše bloga, svoj prosti čas posveča številnim interesom, hobijem in dejavnostim, kar se do neke mere odraža v raznolikosti tem na tem spletnem mestu.