Ubuntu पर mdadm Array में विफल ड्राइव को बदलना
प्रकाशित: 15 फ़रवरी 2025 को 10:02:40 pm UTC बजे
आखरी अपडेट: 12 जनवरी 2026 को 8:50:06 am UTC बजे
अगर आप mdadm RAID ऐरे में ड्राइव फेलियर की खतरनाक स्थिति में हैं, तो यह आर्टिकल बताता है कि Ubuntu सिस्टम पर इसे सही तरीके से कैसे बदला जाए।
Replacing a Failed Drive in an mdadm Array on Ubuntu
इस पोस्ट में दी गई जानकारी Ubuntu 18.04 और इसकी रिपॉजिटरी में शामिल mdadm के वर्शन पर आधारित है; लिखते समय v4.1-rc1. यह दूसरे वर्शन के लिए वैलिड हो भी सकता है और नहीं भी।
हाल ही में मेरे होम फ़ाइल सर्वर में अचानक ड्राइव फेल हो गई, जिसमें mdadm RAID-6 ऐरे में नौ ड्राइव हैं। यह हमेशा डरावना होता है, लेकिन किस्मत से मुझे जल्दी से एक रिप्लेसमेंट ड्राइव मिल गई जो अगले ही दिन डिलीवर हो गई ताकि मैं रीबिल्ड शुरू कर सकूं।
जब मैंने शुरू में फ़ाइल सर्वर सेटअप किया था, तो मैं थोड़ा कंजूस था; सिर्फ़ दो ड्राइव असली NAS ड्राइव हैं (सीगेट आयरनवुल्फ़), जबकि बाकी डेस्कटॉप ड्राइव हैं (सीगेट बाराकुडा)। इसमें कोई हैरानी की बात नहीं है कि यह उन डेस्कटॉप ड्राइव में से एक थी जो (लगभग तीन साल की सर्विस के बाद) खराब हो गई थी। यह पूरी तरह से खराब हो गई थी; इसे डेस्कटॉप USB एनक्लोजर में लगाने के बाद मुझे इसमें से सिर्फ़ एक अजीब सी क्लिकिंग की आवाज़ सुनाई दी और न तो Ubuntu 20.04 और न ही Windows 10 इसे पहचान पाया।
खैर, अब रिप्लेसमेंट वाले हिस्से पर आते हैं (और हाँ, मैंने जो नई ड्राइव खरीदी थी वह आयरनवुल्फ थी, सबक सीखा) - रनिंग ऐरे में ड्राइव खोना जितना डरावना होता है, उससे भी ज़्यादा डरावना तब होता है जब आपको उसे बदलने का सही तरीका नहीं पता हो। यह पहली बार नहीं है जब मुझे mdadm ऐरे में खराब ड्राइव को बदलना पड़ा है, लेकिन अच्छी बात यह है कि ऐसा बहुत कम होता है कि मुझे आमतौर पर सही कमांड देखने पड़ते हैं। इस बार मैंने भविष्य में इस्तेमाल के लिए अपनी खुद की एक छोटी सी गाइड बनाने का फैसला किया।
तो, सबसे पहले, जब आपको mdadm से खतरनाक फेल इवेंट ईमेल मिले, तो आपको यह पहचानना होगा कि कौन सी ड्राइव फेल हो गई है। हाँ, यह आपको डिवाइस का नाम बताएगा (मेरे मामले में /dev/sdf), लेकिन शायद यह साफ़ नहीं होगा कि वह असल में कौन सी फिजिकल ड्राइव है क्योंकि मशीन बूट होने पर वे नाम बदल सकते हैं।
अगर आपको पक्का नहीं है कि कौन सा डिवाइस नाम फेल हो गया है, तो आप यह पता लगाने के लिए नीचे दिए गए कमांड का इस्तेमाल कर सकते हैं (/dev/md0 को अपने RAID डिवाइस से बदलें):
जैसा कि बताया गया है, मेरे मामले में यह /dev/sdf था, तो चलिए उसी के साथ आगे बढ़ते हैं।
फिर, आप यह कमांड देकर खराब ड्राइव का सीरियल नंबर ढूंढने की कोशिश कर सकते हैं:
(अगर smartctl नहीं मिलता है, तो आपको Ubuntu पर smartmontools पैकेज इंस्टॉल करना होगा)
फिर सीरियल नंबर की तुलना ड्राइव पर फिजिकल लेबल पर दिए गए सीरियल नंबर से की जा सकती है, ताकि पता चल सके कि कौन सा फेल हो गया है।
लेकिन इस बार मैं इतना लकी नहीं था। ड्राइव पूरी तरह से डेड हो गई थी और सीरियल नंबर समेत SMART या दूसरा डेटा भी नहीं दे रही थी।
क्योंकि मेरे पास सर्वर का फिजिकल एक्सेस था (अगर आप खुद फिजिकल ड्राइव बदलने जा रहे हैं, तो आपको इसकी बहुत ज़रूरत होती है, मुझे लगता है ;-)) और जब डिस्क फेल हुई तो सर्वर असल में चल रहा था (और RAID-6 रिडंडेंसी की वजह से ठीक चलता रहा), मैंने बहुत ही पुराना, लेकिन असल में बहुत असरदार और साफ़ तरीका अपनाया, जिसमें बस एक बड़ी फ़ाइल को सर्वर पर कॉपी किया और देखा कि कौन सी HDD लाइट नहीं जल रही है। कुछ ही सेकंड में मैंने गलती का पता लगा लिया।
अब, फिजिकल ड्राइव को निकालने से पहले, यह अच्छा रहेगा कि आप mdadm को इस बारे में फॉर्मल तरीके से बता दें, इसके लिए यह कमांड दें (जहां सही लगे, डिवाइस के नाम अपने नाम से बदलें):
सफल होने पर, mdadm एक मैसेज के साथ जवाब देगा जिसमें लिखा होगा कि उसने ड्राइव को "हॉट रिमूव" कर दिया है, ऐसा इसलिए है क्योंकि उस समय वर्चुअल रेड डिवाइस असल में चल रहा है।
अगर यह "डिवाइस या रिसोर्स बिज़ी" जैसे एरर मैसेज के साथ फेल होता है, तो हो सकता है कि mdadm ने असल में ड्राइव को पूरी तरह से फेल होने के लिए रजिस्टर नहीं किया हो। ऐसा करने के लिए, यह कमांड दें (फिर से, याद रखें कि डिवाइस के नाम को ज़रूरत के हिसाब से अपने नाम से बदलें):
उसके बाद, आप पिछले कमांड से डिवाइस को ऐरे से हटा पाएंगे।
अब असल में ड्राइव बदलने का समय आ गया है। अगर आपको सच में, सच में - सच में - पक्का है कि आपकी मशीन और कंट्रोलर हॉट स्वैपिंग को सपोर्ट करते हैं, तो आप मशीन को बंद किए बिना भी ऐसा कर सकते हैं। असली, सही सर्वर हार्डवेयर पर चलने वाले ज़रूरी प्रोडक्शन सिस्टम पर यही तरीका होगा, जिसके बारे में आप जानते हैं कि वह इसे संभाल सकता है। मेरा होम फ़ाइल सर्वर एक कंज्यूमर ग्रेड डेस्कटॉप मदरबोर्ड पर आधारित है, जिसमें PCIe स्लॉट में कुछ सेमी-नोनेम SATA कंट्रोलर हैं ताकि ज़्यादा SATA पोर्ट मिल सकें।
हालांकि SATA को आम तौर पर हॉट स्वैपिंग को सपोर्ट करना चाहिए, लेकिन मैं इस सेटअप में कोई रिस्क नहीं लेना चाहता था, इसलिए मैंने ड्राइव बदलते समय मशीन को बंद करने का ऑप्शन चुना।
ऐसा करने से पहले, /etc/fstab फ़ाइल में RAID डिवाइस को कमेंट करना एक अच्छा आइडिया है ताकि Ubuntu अगले बूट पर इसे ऑटोमैटिकली माउंट करने की कोशिश न करे, क्योंकि यह हैंग हो सकता है और खराब RAID ऐरे की वजह से आपको रिकवरी मोड में जाने के लिए मजबूर कर सकता है। अगर यह डेस्कटॉप सिस्टम है तो यह कोई बड़ी बात नहीं है, लेकिन मैं इस सर्वर को बिना मॉनिटर या कीबोर्ड के हेडलेस चलाता हूं, इसलिए यह थोड़ी परेशानी वाली बात होगी।
नई चमकदार ड्राइव लगाकर मशीन को बूट करने के बाद, इसे पहचानने के लिए lsblk या किसी और तरीके का इस्तेमाल करें। अगर आपने कुछ और नहीं बदला है, तो शायद (लेकिन ज़रूरी नहीं) इसका नाम वही होगा जो आपने बदली हुई ड्राइव का नाम रखा था। मेरे मामले में ऐसा हुआ, इसलिए नई ड्राइव का नाम भी /dev/sdf है।
क्योंकि मेरा ऐरे फिजिकल डिवाइस के बजाय पार्टीशन पर आधारित है, इसलिए मुझे पार्टीशन टेबल को वर्किंग ड्राइव से नई ड्राइव पर कॉपी करना पड़ा ताकि यह पक्का हो सके कि वे बिल्कुल एक जैसे हैं। अगर आप अपना ऐरे फिजिकल डिवाइस पर चलाते हैं, तो आप इस स्टेप को छोड़ सकते हैं।
मैंने इस काम के लिए sgdisk का इस्तेमाल किया, पार्टीशन टेबल को /dev/sdc से /dev/sdf में कॉपी किया। ध्यान रखें कि डिवाइस के नाम को अपने नाम से मैच करें।
यहां ऑर्डर पर ध्यान दें: आप "टू" ड्राइव को पहले लिस्ट करते हैं! यह मेरे लिए थोड़ा उल्टा है, लेकिन बस यह पक्का कर लें कि आप इसे सही तरीके से करें ताकि ऐरे में कोई और ड्राइव फेलियर न हो ;-)
फिर UUID कॉन्फ्लिक्ट से बचने के लिए, नई ड्राइव के लिए नए UUID बनाएं:
और अब आखिरकार ऐरे में नई ड्राइव जोड़ने और रीबिल्ड पार्टी शुरू करने का समय आ गया है! (ठीक है, यह असल में कोई पार्टी नहीं है, यह असल में काफी धीमा और परेशान करने वाला प्रोसेस है क्योंकि आप सच में नहीं चाहेंगे कि इस समय कोई और ड्राइव फेल हो जाए। हालांकि, बीयर मदद कर सकती है)
वैसे भी, ऐरे में नई ड्राइव जोड़ने के लिए, यह कमांड दें (फिर से, डिवाइस के नाम को ज़रूरत के हिसाब से अपने नाम से बदलना पक्का करें):
अगर सब ठीक रहा, तो ड्राइव बिना किसी दिक्कत के ऐरे में जुड़ जाएगी। मेरा मानना है कि यह असल में डिफ़ॉल्ट रूप से "हॉट स्पेयर" के तौर पर जुड़ती है, लेकिन क्योंकि इस ऐरे में एक डिस्क नहीं है (जो खराब हो गई थी), इसलिए इसे तुरंत इस्तेमाल में लाया जाएगा और रीबिल्ड प्रोसेस शुरू हो जाएगा।
आप इस पर इस तरह नज़र रख सकते हैं:
इसमें शायद थोड़ा समय लगेगा; मेरे छोटे से सर्वर पर (जो ज़्यादातर कंज्यूमर ग्रेड हार्डवेयर और डेस्कटॉप ड्राइव पर आधारित है, ध्यान रहे) यह 100 MB/sec से थोड़ा कम स्पीड तक पहुँच पाया। ध्यान रखें कि यह RAID-6 है, इसलिए रीबिल्ड में बहुत सारे पैरिटी कैलकुलेशन शामिल हैं; RAID-10 बहुत तेज़ होता। इस खास मशीन में AMD A10 9700E क्वाड कोर CPU है ("E" का मतलब है कि यह एक अंडर-क्लॉक्ड एनर्जी एफिशिएंट मॉडल है, यानी सुपर फास्ट नहीं), बस आपको यह अंदाज़ा देने के लिए कि क्या उम्मीद की जा सकती है। मेरे सेटअप में नौ 8 TB ड्राइव के साथ, पूरे रीबिल्ड में 24 घंटे से थोड़ा ज़्यादा समय लगा।
रीबिल्ड के दौरान, आप चाहें तो फ़ाइल सिस्टम को ऐरे पर माउंट कर सकते हैं और नॉर्मल तरीके से इस्तेमाल कर सकते हैं, लेकिन मैं इसे तब तक रीबिल्डिंग पर छोड़ना पसंद करता हूँ जब तक यह पूरा न हो जाए। ध्यान रखें कि अगर एक ड्राइव फेल हो जाती है, तो दूसरी भी जल्द ही फेल हो सकती है, इसलिए आप चाहते हैं कि रीबिल्ड जितनी जल्दी हो सके हो जाए क्योंकि आप सच में नहीं चाहेंगे कि उस दौरान कोई दूसरी ड्राइव फेल हो जाए। इसलिए, इस पर दूसरे IO का बोझ न डालें जो बहुत ज़रूरी नहीं हैं।
एक बार हो जाने के बाद, इसे अपनी /etc/fstab फ़ाइल में वापस जोड़ें, रीबूट करें और अपनी फ़ाइलों का आनंद लें :-)