Miklix

Pagpapalit ng Nabigong Drive sa isang mdadm Array sa Ubuntu

Nai-publish: Marso 19, 2025 nang 9:34:02 PM UTC

Kung ikaw ay nasa kinatatakutang sitwasyon ng pagkakaroon ng drive failure sa isang mdadm RAID array, ipinapaliwanag ng artikulong ito kung paano ito palitan nang tama sa isang Ubuntu system.


Ang pahinang ito ay isinalin sa makina mula sa Ingles upang gawin itong naa-access sa pinakamaraming tao hangga't maaari. Sa kasamaang palad, ang pagsasalin ng makina ay hindi pa isang perpektong teknolohiya, kaya maaaring mangyari ang mga error. Kung gusto mo, maaari mong tingnan ang orihinal na bersyong Ingles dito:

Replacing a Failed Drive in an mdadm Array on Ubuntu

Ang impormasyon sa post na ito ay batay sa Ubuntu 18.04 at ang bersyon ng mdadm na kasama sa mga repositoryo nito; sa oras ng pagsusulat, v4.1-rc1. Maaaring tama ito o hindi para sa ibang bersyon.

Kamakailan lang ay nakaranas ako ng biglaang pagkasira ng drive sa aking home file server, na binubuo ng siyam na drive sa isang mdadm RAID-6 array. Nakakatakot ito, pero sa kabutihang palad, nakahanap ako ng pamalit na drive na na-deliver na kinabukasan kaya't nakapagsimula akong mag-rebuild.

Aaminin ko, medyo naging matipid ako nang unang itayo ko ang file server; dalawa lang sa mga drive ay mga tunay na NAS drives (Seagate IronWolf), habang ang iba ay mga desktop drives (Seagate Barracuda). Hindi nakakagulat, isa sa mga desktop drives ang nasira (matapos ang halos tatlong taon ng paggamit). Wala na itong buhay; nang ilipat ko ito sa isang desktop USB enclosure, ang tanging narinig ko ay nakakabahalang tunog ng pag-click at hindi ito nakita ng Ubuntu 20.04 o Windows 10.

Aba, pumunta na tayo sa bahagi ng pagpapalit (at oo, ang bagong drive na binili ko ay isang IronWolf, aral na natutunan) - kahit nakakatakot ang mawalan ng drive sa isang tumatakbong array, mas nakakatakot kung hindi mo alam ang tamang pamamaraan ng pagpapalit nito. Hindi ito ang unang pagkakataon na kailangang palitan ko ang isang nasirang drive sa isang mdadm array, pero sa kabutihang palad, bihira ito kaya't kadalasan kailangan ko pang maghanap ng mga tamang utos. Ngayong pagkakataon, nagdesisyon akong gumawa ng sarili kong gabay para sa hinaharap.

Kaya, unang-una, kapag natanggap mo ang nakakabahalang fail event e-mail mula sa mdadm, kailangan mong tukuyin kung aling drive ang nasira. Sigurado, sasabihin nito ang pangalan ng device (sa kaso ko /dev/sdf), pero malamang hindi agad malinaw kung aling pisikal na drive ito dahil ang mga pangalan ng mga device ay maaaring magbago kapag nag-boot ang makina.

Kung hindi mo pa alam kung aling device name ang nasira, maaari mong gamitin ang sumusunod na utos upang malaman (palitan ang /dev/md0 ng iyong RAID device):

mdadm -–query -–detail /dev/md0

Tulad ng nabanggit, sa kaso ko ay /dev/sdf, kaya't ipagpatuloy natin iyon.

Pagkatapos, maaari mong subukang hanapin ang serial number ng nasirang drive sa pamamagitan ng pagpapatakbo ng utos na ito:

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

(kung hindi makita ang smartctl, kailangan mong i-install ang smartmontools package sa Ubuntu)

Ang serial number ay maaaring ikumpara sa mga serial number na nasa pisikal na label ng mga drive upang malaman kung alin ang nasira.

Sa pagkakataong ito, hindi ako pinalad. Ang drive ay totally dead at tumanggi pang magbigay ng SMART o ibang data, kasama na ang serial number.

Dahil may pisikal na access ako sa server (na talagang kailangan mo kung papalitan mo ang isang pisikal na drive ng ikaw mismo, siguro ;-)) at ang server ay patuloy na tumatakbo nang magka-aberya ang disk (at patuloy na tumakbo ng maayos salamat sa RAID-6 redundancy), pinili ko ang isang primitive, pero talagang epektibo at halatang paraan ng simpleng pagkopya ng isang malaking file sa server at pagtutok sa HDD light na hindi kumikislap. Sa loob ng ilang segundo, natukoy ko na ang salarin.

Ngayon, bago hilahin ang pisikal na drive, magandang ideya na pormal na ipaalam sa mdadm ang layunin na ito, sa pamamagitan ng pagpapatakbo ng utos na ito (palitan ang mga pangalan ng device ayon sa iyong mga kinakailangan):

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

Kapag matagumpay, magpapadala ng mensahe ang mdadm na nagsasabing "hot removed" ang drive, dahil ang virtual raid device ay talagang tumatakbo sa oras na iyon.

Kung mag-fail ito na may error message tulad ng "device or resource busy", maaaring hindi pa nakarehistro ng mdadm na ang drive ay ganap na nasira. Para ipagawa ito, patakbuhin ang utos na ito (muli, tandaan palitan ang mga pangalan ng device ayon sa iyong mga kinakailangan):

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

Pagkatapos nito, dapat mong magawa nang alisin ang device mula sa array gamit ang naunang utos.

Ngayon, oras na para talagang palitan ang drive. Kung talagang, talagang - tulad ng talaga - sigurado kang sinusuportahan ng iyong makina at controller ang hot swapping, maaari mo itong gawin nang hindi pinapatay ang makina. Iyon ang tamang gawin sa mga kritikal na production system na tumatakbo sa tunay, wastong server hardware na alam mong kayang-kaya ito. Ang aking home file server ay nakabase sa isang consumer-grade na desktop motherboard na may ilang semi-noname na SATA controllers sa PCIe slots para magbigay ng higit pang SATA ports, kahit na.

Kahit na ang SATA ay karaniwang dapat suportahan ang hot swapping, hindi ako maglalakas-loob na mag-risk dito sa setup na ito, kaya't pinili kong patayin ang makina habang pinapalitan ang drive.

Bago gawin iyon, magandang ideya na i-comment out ang raid device sa /etc/fstab file upang hindi subukan ng Ubuntu na i-mount ito nang awtomatiko sa susunod na boot, dahil maaari itong mag-hang at pilitin kang pumasok sa recovery mode dahil sa degraded na RAID array. Hindi ito malaking isyu kung ito ay isang desktop system, ngunit pinapatakbo ko ang server na ito nang walang monitor o keyboard, kaya medyo magiging abala ito.

Pagkatapos i-boot ang makina na may bagong drive na naka-install, gamitin ang lsblk o ibang paraan upang tukuyin ito. Kung hindi mo binago ang anumang bagay, malamang (ngunit hindi tiyak) na magkakaroon ito ng parehong pangalan tulad ng drive na pinalitan mo. Sa aking kaso, nangyari iyon, kaya ang bago ay tinatawag din na /dev/sdf.

Dahil ang aking array ay batay sa mga partition kaysa sa mga pisikal na device, kailangan kong kopyahin ang partition table mula sa isang gumaganang drive papunta sa bagong drive upang tiyakin na eksaktong magkapareho sila. Kung pinapatakbo mo ang iyong array sa mga pisikal na device, maaari mong laktawan ang hakbang na ito.

Ginamit ko ang sgdisk para sa layuning ito, kinopya ang partition table mula sa /dev/sdc papunta sa /dev/sdf. Siguraduhing palitan ang mga pangalan ng device upang tumugma sa iyo kung kinakailangan.

Paunawa sa pagkakasunud-sunod dito: ilista ang "to" drive muna! Medyo hindi intuitive ito para sa akin, ngunit tiyakin na tama ito upang hindi ka magkaroon ng isa pang pagkabigo ng drive sa array ;-)

sgdisk -R /dev/sdf /dev/sdc

Pagkatapos, upang maiwasan ang mga UUID conflict, lumikha ng bagong UUIDs para sa bagong drive:

sgdisk -G /dev/sdf

At ngayon, sa wakas, dumating na ang oras upang idagdag ang bagong drive sa array at simulan ang rebuild party! (Sige, hindi ito talagang party, ito ay isang medyo mabagal at nakakabahala na proseso dahil talagang, talagang ayaw mong magka-problema na naman ang isa pang drive sa oras na ito. Ngunit baka makatulong ang beer)

Gayunpaman, upang idagdag ang bagong drive sa array, ipasok ang utos na ito (muli, tiyakin na palitan ang mga pangalan ng device upang tumugma sa iyo kung kinakailangan):

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

Kung magiging maayos, madadagdag ang drive sa array nang walang aberya. Naniniwala akong awtomatikong idinadagdag ito bilang isang "hot spare", ngunit dahil ang array na ito ay nawawalan ng isang disk (ang nag-fail na disk), agad itong ginagamit at magsisimula ang rebuild process.

Maaari mong subaybayan ito tulad ng ganito:

watch cat /proc/mdstat

Malamang ay magtatagal ito; sa aking simpleng server (na karamihan ay gumagamit ng consumer-grade hardware at desktop drives, tandaan mo) ito ay umabot lamang sa ilalim ng 100 MB/sec. Isaisip na ito ay RAID-6, kaya't maraming parity calculations ang kasangkot sa rebuild; ang RAID-10 ay mas mabilis. Ang partikular na makinang ito ay may AMD A10 9700E quad core CPU (ang "E" ay nangangahulugang isang under-clocked na energy-efficient na modelo, ibig sabihin hindi sobrang bilis), para mabigyan ka ng ideya kung ano ang aasahan. Sa siyam na 8 TB na drive sa aking setup, ang buong rebuild ay tumagal ng mahigit 24 na oras.

Habang nire-rebuild, maaari mong i-mount ang filesystem sa array at gamitin ito tulad ng normal kung nais mo, ngunit mas gusto kong iwanan ito para sa rebuild hanggang matapos ito. Isaisip na kung ang isang drive ay magka-fail, malamang ay may susunod pang isa, kaya nais mong matapos agad ang rebuild upang hindi na magka-problema ang isa pang drive. Samakatuwid, huwag itong pasanin ng iba pang IO na hindi naman kinakailangan.

Kapag natapos na, idagdag ito pabalik sa iyong /etc/fstab file, mag-reboot at mag-enjoy sa iyong mga files :-)

Ibahagi sa BlueskyIbahagi sa FacebookIbahagi sa LinkedInIbahagi sa TumblrIbahagi sa XIbahagi sa LinkedInI-pin sa Pinterest

Mikkel Christensen

Tungkol sa May-akda

Mikkel Christensen
Si Mikkel ang lumikha at may-ari ng miklix.com. Siya ay may higit sa 20 taong karanasan bilang isang propesyonal na computer programmer/software developer at kasalukuyang nagtatrabaho ng full-time para sa isang malaking European IT corporation. Kapag hindi nagba-blog, ginugugol niya ang kanyang bakanteng oras sa isang malawak na hanay ng mga interes, libangan, at aktibidad, na maaaring sa ilang lawak ay makikita sa iba't ibang mga paksang sakop sa website na ito.