Miklix

Ubuntu मा mdadm एरेमा असफल ड्राइभ बदल्दै

प्रकाशित: २०२५ फेब्रुअरी १५: २२:०८:१६ UTC

यदि तपाईं mdadm RAID एरेमा ड्राइभ विफलताको डरलाग्दो अवस्थामा हुनुहुन्छ भने, यो लेखले Ubuntu प्रणालीमा यसलाई कसरी सही रूपमा प्रतिस्थापन गर्ने भनेर वर्णन गर्दछ।


यो पृष्ठलाई सकेसम्म धेरै मानिसहरूको पहुँचयोग्य बनाउनको लागि अंग्रेजीबाट मेसिन अनुवाद गरिएको थियो। दुर्भाग्यवश, मेसिन अनुवाद अझै पूर्ण प्रविधि होइन, त्यसैले त्रुटिहरू हुन सक्छन्। यदि तपाईं चाहनुहुन्छ भने, तपाईं यहाँ मूल अंग्रेजी संस्करण हेर्न सक्नुहुन्छ:

Replacing a Failed Drive in an mdadm Array on Ubuntu

यस पोस्टमा भएको जानकारी v4.1-rc1 लेख्ने समयमा यसको भण्डारहरूमा समावेश गरिएको Ubuntu 18.04 र mdadm को संस्करणमा आधारित छ। यो अन्य संस्करणहरूको लागि मान्य हुन पनि सक्छ वा नहुन पनि सक्छ।

मेरो गृह फाइल सर्भरमा हालसालै अचानक ड्राइभ फेल भयो, जसमा mdadm RAID-6 एरेमा नौ ड्राइभहरू हुन्छन्। त्यो सधैं डरलाग्दो हुन्छ, तर भाग्यवश म चाँडै नै अर्को दिन डेलिभर गरिएको प्रतिस्थापन ड्राइभ प्राप्त गर्न सक्षम भएँ ताकि म पुनर्निर्माण सुरु गर्न सकूँ।

मैले सुरुमा फाइल सर्भर सेटअप गर्दा म अलि धेरै सस्तो थिएँ भन्ने कुरा स्वीकार्य छ; ड्राइभहरू मध्ये केवल दुई वास्तविक NAS ड्राइभहरू (Seagate IronWolf) हुन्, जबकि बाँकी डेस्कटप ड्राइभहरू (Seagate Barracuda) हुन्। अचम्म मान्नु पर्दैन, यो डेस्कटप ड्राइभहरू मध्ये एक थियो जसले छोडेको थियो (लगभग तीन वर्षको सेवा पछि, यद्यपि)। यो पूर्ण रूपमा मृत थियो; यसलाई डेस्कटप USB एन्क्लोजरमा सारिएपछि म यसबाट बाहिर निस्केको सबै एक निराशाजनक क्लिक ध्वनि थियो र न त Ubuntu 20.04 न त Windows 10 ले यसलाई पत्ता लगाउन सकेन।

ठीक छ, प्रतिस्थापन भागको बारेमा (र हो, मैले किनेको नयाँ ड्राइभ आइरनवुल्फ थियो, पाठ सिकियो) - चलिरहेको एरेमा ड्राइभ गुमाउनु जति डरलाग्दो छ, यदि तपाईंलाई यसलाई प्रतिस्थापन गर्ने सही प्रक्रिया थाहा छैन भने यो अझ डरलाग्दो छ। mdadm एरेमा असफल ड्राइभ बदल्नु परेको यो पहिलो पटक होइन, तर भाग्यवश यो यति दुर्लभ छ कि मलाई सामान्यतया उचित आदेशहरू हेर्नु पर्छ। यस पटक मैले भविष्यको सन्दर्भको लागि मेरो आफ्नै सानो गाइड तयार गर्ने निर्णय गरें।

त्यसैले, सबैभन्दा पहिले, जब तपाईंलाई mdadm बाट डरलाग्दो असफल घटनाको इमेल प्राप्त हुन्छ, तपाईंले कुन ड्राइभ असफल भएको छ भनेर पहिचान गर्न आवश्यक छ। अवश्य पनि, यसले तपाईंलाई उपकरणको नाम बताउनेछ (मेरो मामलामा /dev/sdf), तर यो सम्भवतः स्पष्ट छैन कि त्यो वास्तवमा कुन भौतिक ड्राइभ हो किनकि मेसिन बुट हुँदा ती नामहरू परिवर्तन हुन सक्छन्।

यदि तपाईंलाई कुन उपकरणको नाम असफल भएको छ भन्ने कुरा पनि निश्चित छैन भने, तपाईंले पत्ता लगाउन निम्न आदेश प्रयोग गर्न सक्नुहुन्छ (/dev/md0 लाई आफ्नो RAID उपकरणले बदल्नुहोस्):

mdadm -–query -–detail /dev/md0

उल्लेख गरिएझैं, मेरो मामलामा यो /dev/sdf थियो, त्यसैले त्यसलाई जारी राखौं।

त्यसपछि, तपाईंले यो आदेश जारी गरेर असफल ड्राइभको सिरियल नम्बर फेला पार्न प्रयास गर्न सक्नुहुन्छ:

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

(यदि smartctl फेला परेन भने, तपाईंले Ubuntu मा smartmontools प्याकेज स्थापना गर्नुपर्छ)

त्यसपछि कुन असफल भएको छ भनेर पत्ता लगाउन सिरियल नम्बरलाई ड्राइभको भौतिक लेबलमा रहेको सिरियल नम्बरसँग तुलना गर्न सकिन्छ।

यसपालि, म त्यति भाग्यमानी थिइनँ। ड्राइभ पूर्ण रूपमा निष्क्रिय थियो र SMART वा सिरियल नम्बर सहित अन्य डेटा प्रदान गर्न पनि अस्वीकार गर्‍यो।

मसँग सर्भरमा भौतिक पहुँच भएको हुनाले (जुन तपाईंलाई वास्तवमै भौतिक ड्राइभ बदल्नको लागि आवश्यक पर्दछ, मलाई लाग्छ ;-)) डिस्क असफल हुँदा सर्भर वास्तवमा चलिरहेको थियो (र RAID-6 रिडन्डन्सीको कारणले राम्रोसँग चल्न जारी रह्यो), मैले साँच्चै आदिम, तर वास्तवमा अत्यधिक प्रभावकारी र स्पष्ट, सर्भरमा ठूलो फाइल प्रतिलिपि गर्ने र कुन HDD लाइट झिलिमिली छैन भनेर हेर्ने विधि अपनाएँ। केही सेकेन्डमै मैले अपराधी पहिचान गरें।

अब, भौतिक ड्राइभ निकाल्नु अघि, यो आदेश जारी गरेर mdadm लाई औपचारिक रूपमा यस उद्देश्यको बारेमा जानकारी गराउनु राम्रो हुन्छ (उपयुक्त भएमा उपकरणको नामलाई आफ्नै नामले बदल्नुहोस्):

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

सफलता प्राप्त भएमा, mdadm ले एउटा सन्देशको साथ जवाफ दिनेछ कि यसले ड्राइभलाई "हट रिमूभ" गर्यो, स्पष्ट रूपमा किनभने भर्चुअल रेड उपकरण वास्तवमा त्यस समयमा चलिरहेको थियो।

यदि यो "उपकरण वा स्रोत व्यस्त" जस्तै त्रुटि सन्देशको साथ असफल भयो भने, यो हुन सक्छ कि mdadm ले वास्तवमा ड्राइभ दर्ता गरेको छैन र पूर्ण रूपमा असफल भएको छ। त्यसो गर्न, यो आदेश जारी गर्नुहोस् (फेरि, उपयुक्त भएमा आफ्नै नामले उपकरणको नाम बदल्न नबिर्सनुहोस्):

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

त्यस पछि, तपाईंले अघिल्लो आदेशको साथ एरेबाट उपकरण हटाउन सक्षम हुनुहुनेछ।

अब ड्राइभ बदल्ने समय आएको छ। यदि तपाईं साँच्चै, साँच्चै - जस्तै, साँच्चै - निश्चित हुनुहुन्छ कि तपाईंको मेसिन र नियन्त्रकले हट स्वापिङलाई समर्थन गर्दछ भने, तपाईंले मेसिन बन्द नगरी यो गर्न सक्नुहुन्छ। वास्तविक, उचित सर्भर हार्डवेयरमा चल्ने महत्वपूर्ण उत्पादन प्रणालीहरूमा जाने तरिका यो हुनेछ जुन तपाईंलाई थाहा छ कि यसले यसलाई ह्यान्डल गर्न सक्छ। मेरो गृह फाइल सर्भर उपभोक्ता ग्रेड डेस्कटप मदरबोर्डमा आधारित छ जसमा PCIe स्लटहरूमा केही अर्ध-नाम SATA नियन्त्रकहरू छन् जसले थप SATA पोर्टहरू प्रदान गर्दछ।

यद्यपि SATA ले सामान्यतया हट स्वापिङलाई समर्थन गर्नुपर्छ , म यो सेटअपमा कुनै पनि जोखिम लिनेवाला थिइनँ, त्यसैले मैले ड्राइभ बदल्दा मेसिन बन्द गर्ने छनौट गरें।

त्यसो गर्नु अघि, /etc/fstab फाइलमा रहेको raid उपकरणलाई टिप्पणी गर्नु राम्रो हुन्छ ताकि Ubuntu ले अर्को बुटमा यसलाई स्वचालित रूपमा माउन्ट गर्ने प्रयास नगरोस्, किनकि यो ह्याङ्ग हुन सक्छ र घटेको RAID एरेको कारणले तपाईंलाई रिकभरी मोडमा बाध्य पार्न सक्छ। यदि यो डेस्कटप प्रणाली हो भने त्यो ठूलो समस्या नहुन सक्छ, तर म यो सर्भरलाई मनिटर वा किबोर्ड जडान नगरी हेडलेस चलाउँछु, त्यसैले यो अलि झन्झट हुनेछ।

चम्किलो नयाँ ड्राइभ स्थापना गरेर मेसिन बुट गरेपछि, यसलाई पहिचान गर्न lsblk वा अन्य कुनै माध्यम प्रयोग गर्नुहोस्। यदि तपाईंले अरू केही परिवर्तन गर्नुभएको छैन भने, यसले सम्भवतः (तर आवश्यक छैन) तपाईंले प्रतिस्थापन गर्नुभएको ड्राइभको नाम नै पाउनेछ। मेरो मामलामा यो भयो, त्यसैले नयाँलाई /dev/sdf पनि भनिन्छ।

मेरो एरे भौतिक उपकरणहरूको सट्टा विभाजनहरूमा आधारित भएकोले, मलाई विभाजन तालिकालाई काम गर्ने ड्राइभबाट नयाँ ड्राइभमा प्रतिलिपि गर्न आवश्यक थियो ताकि तिनीहरू ठ्याक्कै उस्तै छन् भनी सुनिश्चित गर्न सकियोस्। यदि तपाईंले आफ्नो एरे भौतिक उपकरणहरूमा चलाउनुभयो भने, तपाईं यो चरण छोड्न सक्नुहुन्छ।

मैले यस उद्देश्यको लागि sgdisk प्रयोग गरें, विभाजन तालिकालाई /dev/sdc बाट /dev/sdf मा प्रतिलिपि गर्दै। उपयुक्त भएमा आफ्नो नाम मिलाउन उपकरणको नाम बदल्न निश्चित गर्नुहोस्।

यहाँ क्रमलाई ध्यान दिनुहोस् : तपाईंले पहिले "to" ड्राइभ सूचीबद्ध गर्नुहोस्! यो मेरो लागि अलि विपरीत छ, तर तपाईंले यसलाई सही तरिकाले गर्नुभयो भनेर निश्चित गर्नुहोस् ताकि तपाईंले एरेमा अर्को ड्राइभ विफलता नपरोस् ;-)

sgdisk -R /dev/sdf /dev/sdc

त्यसपछि UUID द्वन्द्वबाट बच्न, नयाँ ड्राइभको लागि नयाँ UUID हरू उत्पन्न गर्नुहोस्:

sgdisk -G /dev/sdf

अनि अब अन्ततः एरेमा नयाँ ड्राइभ थप्ने र पुनर्निर्माण पार्टी सुरु गर्ने समय आएको छ! (ठीक छ, यो वास्तवमा पार्टी होइन, यो वास्तवमा एकदमै ढिलो र निराश पार्ने प्रक्रिया हो किनकि तपाईं वास्तवमै, साँच्चै यस समयमा अर्को ड्राइभ असफल भएको चाहनुहुन्न। यद्यपि, बियरले मद्दत गर्न सक्छ)

जे भए पनि, एरेमा नयाँ ड्राइभ थप्नको लागि, यो आदेश जारी गर्नुहोस् (फेरि, उपयुक्त भएमा उपकरणको नामलाई आफ्नै नामले बदल्न निश्चित गर्नुहोस्):

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

यदि सबै कुरा ठीकठाक भयो भने, ड्राइभ बिना कुनै बाधा एरेमा थपिनेछ। मलाई विश्वास छ कि यो वास्तवमा पूर्वनिर्धारित रूपमा "हट स्पेयर" को रूपमा थपिएको छ, तर यो एरेमा डिस्क हराइरहेको हुनाले (जुन असफल भयो), यसलाई तुरुन्तै प्रयोगमा राखिन्छ र पुनर्निर्माण प्रक्रिया सुरु हुनेछ।

तपाईं यसमा यसरी नजर राख्न सक्नुहुन्छ:

watch cat /proc/mdstat

यो सम्भवतः केही समय लाग्नेछ; मेरो कम सर्भरमा (मुख्यतया उपभोक्ता ग्रेड हार्डवेयर र डेस्कटप ड्राइभहरूमा आधारित, ध्यान दिनुहोस्) यो १०० MB/सेकेन्ड भन्दा कम गतिमा पुग्न सक्षम थियो। ध्यान राख्नुहोस् कि यो RAID-6 हो, त्यसैले पुनर्निर्माणमा धेरै समानता गणनाहरू समावेश छन्; RAID-10 धेरै छिटो हुने थियो। यो विशेष मेसिनमा AMD A10 9700E क्वाड कोर CPU छ ("E" को अर्थ यो कम-घडी गरिएको ऊर्जा कुशल मोडेल हो, अर्थात् सुपर फास्ट होइन), केवल तपाईंलाई के आशा गर्ने भन्ने बारे एक विचार दिनको लागि। मेरो सेटअपमा नौ 8 TB ड्राइभहरूको साथ, पूर्ण पुनर्निर्माणमा २४ घण्टा भन्दा बढी समय लाग्यो।

पुनर्निर्माणको क्रममा, तपाईंले एरेमा फाइल प्रणाली माउन्ट गर्न सक्नुहुन्छ र यदि तपाईं चाहनुहुन्छ भने यसलाई सामान्य रूपमा प्रयोग गर्न सक्नुहुन्छ, तर म यसलाई पुनर्निर्माणको लागि छोड्न रुचाउँछु जबसम्म यो पूरा हुँदैन। ध्यान राख्नुहोस् कि यदि एउटा ड्राइभ असफल भयो भने, अर्को चाँडै पछ्याउन सक्छ, त्यसैले तपाईं पुनर्निर्माण सकेसम्म छिटो सम्पन्न गर्न चाहनुहुन्छ किनकि तपाईं वास्तवमा त्यस समयमा अर्को ड्राइभ असफल हुन चाहनुहुन्न। त्यसकारण, यसलाई कडा रूपमा आवश्यक नभएको अन्य IO ले बोझ नगर्नुहोस्।

एकचोटि यो सकिएपछि, यसलाई तपाईंको /etc/fstab फाइलमा फेरि थप्नुहोस्, रिबुट गर्नुहोस् र तपाईंको फाइलहरूको आनन्द लिनुहोस् :-)

ब्लुस्कीमा सेयर गर्नुहोस्फेसबुक मा शेयर गर्नुहोस्लिंक्डइनमा सेयर गर्नुहोस्Tumblr मा सेयर गर्नुहोस्X मा सेयर गर्नुहोस्लिंक्डइनमा सेयर गर्नुहोस्Pinterest मा पिन गर्नुहोस्

मिकेल बाङ क्रिस्टेनसेन

लेखकको बारेमा

मिकेल बाङ क्रिस्टेनसेन
मिकेल miklix.com का निर्माता र मालिक हुन्। उनीसँग एक पेशेवर कम्प्युटर प्रोग्रामर/सफ्टवेयर विकासकर्ताको रूपमा २० वर्ष भन्दा बढीको अनुभव छ र हाल उनी एक ठूलो युरोपेली आईटी निगममा पूर्ण-समय कार्यरत छन्। ब्लगिङ नगर्दा, उनी आफ्नो खाली समय विभिन्न रुचि, शौक र गतिविधिहरूमा बिताउँछन्, जुन केही हदसम्म यस वेबसाइटमा समेटिएका विषयहरूको विविधतामा प्रतिबिम्बित हुन सक्छ।