mdadm raid5 डबल डिस्क विफलता को पुनर्प्राप्त करता है - एक मोड़ (ड्राइव ऑर्डर) के साथ

Question

मुझे पहले स्वीकार करें कि मैंने गलतियाँ की हैं, और मेरे पास इस RAID के अधिकांश डेटा के लिए बैकअप है, लेकिन सभी के लिए नहीं । मुझे अभी भी बाकी डेटा के ठीक होने की उम्मीद है। मेरे पास रिकवरी विशेषज्ञ कंपनी के पास ड्राइव करने के लिए पैसे नहीं हैं।

गलती # 0, एक 100% बैकअप नहीं है। मुझे पता है।

मेरे पास mdadm4x3TB का एक RAID5 सिस्टम है। ड्राइव / देव / एसडी [हो], सभी एक विभाजन के साथ /dev/sd[b-e]1। मुझे पता है कि बहुत बड़े ड्राइव पर RAID5 जोखिम भरा है, फिर भी मैंने इसे वैसे भी किया।

वतॆमान की घटनाये

दो ड्राइव की विफलता के बाद RAID अपमानित हो जाता है। एक ड्राइव [/ dev / sdc] वास्तव में चला गया है, अन्य [/ dev / sde] एक शक्ति चक्र के बाद वापस आया, लेकिन स्वचालित रूप से RAID में पुन: नहीं जोड़ा गया। तो मैं एक 4 डिवाइस RAID केवल 2 सक्रिय ड्राइव [/ dev / sdb और / dev / sdd] के साथ छोड़ दिया गया था।

RAID पुनर्स्थापित करने के लिए ड्राइव की dd प्रतियों का उपयोग न करते हुए गलती # 1। मेरे पास ड्राइव या समय नहीं था। # 2 गलती, सुपरब्लॉक और mdadm -Eशेष ड्राइव का बैकअप नहीं बना रहा है ।

वसूली का प्रयास

मैं reassembled RAID के साथ अपमानित मोड में

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

मैं तब अपना डेटा एक्सेस कर सकता था। मैं /dev/sdcएक स्पेयर के साथ बदल दिया ; खाली; समान ड्राइव।

मैं पुराने /dev/sdc1से हटा दिया RAID

mdadm --fail /dev/md0 /dev/sdc1

गलती # 3, ड्राइव को बदलने से पहले ऐसा नहीं करना

मैंने तब नया विभाजन किया /dev/sdcऔर इसे RAID में जोड़ा।

mdadm --add /dev/md0 /dev/sdc1

इसके बाद RAID को पुनर्स्थापित करना शुरू किया। ईटीए 300 मि। मैंने /proc/mdstat2% तक प्रक्रिया का पालन किया और फिर अन्य सामान करने के लिए चला गया।

परिणाम की जाँच कर रहा है

कई घंटे (लेकिन कम से कम 300 मिनट) बाद में, मैंने प्रक्रिया की जांच की। पर पढ़ने में त्रुटि के कारण यह बंद हो गया था /dev/sde1।

यहाँ वह जगह है जहाँ मुसीबत वास्तव में शुरू होती है

मैं तो /dev/sde1RAID से हटा दिया और इसे फिर से जोड़ा। मुझे याद नहीं है कि मैंने ऐसा क्यों किया; उसमें देर हो चुकी थी।

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

हालाँकि, /dev/sde1अब स्पेयर के रूप में चिह्नित किया गया था। इसलिए मैंने जो सही सोचा था, उसका उपयोग करके और /dev/sdc1लापता होने के साथ -समूह-स्वच्छ का उपयोग करके पूरे सरणी को फिर से बनाने का फैसला किया ।

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

यह काम किया, लेकिन माउंट करने की कोशिश करते समय फाइल सिस्टम को मान्यता नहीं दी गई थी। (यह EXT4 होना चाहिए था)।

डिवाइस क्रम

मैंने तब एक हालिया बैकअप की जाँच की जो मेरे पास था /proc/mdstat, और मुझे ड्राइव ऑर्डर मिला।

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

फिर मुझे याद आया कि इस RAID को लगभग एक साल पहले एक ड्राइव लॉस हुआ था, और एक फाल्ट ड्राइव के साथ दोषपूर्ण ड्राइव को बदलकर इसे रिकवर किया था। हो सकता है कि उसने डिवाइस के ऑर्डर को थोड़ा बढ़ा दिया हो ... इसलिए कोई ड्राइव नहीं थी [३] लेकिन केवल [०], [१], [२] और [४]।

मैंने Permute_array स्क्रिप्ट के साथ ड्राइव ऑर्डर खोजने की कोशिश की: https://raid.wiki.kernel.org/index.php/Permute_array.pl लेकिन उसे सही ऑर्डर नहीं मिला।

प्रशन

मेरे पास अब दो मुख्य प्रश्न हैं:

1. मैंने ड्राइव पर सभी सुपरब्लॉक खराब कर दिए, लेकिन केवल दिया:

   mdadm --create --assume-clean
   

   आज्ञाओं (इसलिए मुझे स्वयं डेटा को ओवरराइट नहीं करना चाहिए था /dev/sd[bde]1। क्या मैं सही हूं कि सिद्धांत में RAID को बहाल किया जा सकता है [एक पल के लिए मान /dev/sde1लेना ठीक है] अगर मुझे सिर्फ सही डिवाइस ऑर्डर मिल जाए?

2. क्या यह महत्वपूर्ण है कि /dev/sde1RAID में डिवाइस नंबर [4] दिया जाए? जब मैं इसके साथ बनाता हूं

   mdadm --create /dev/md0 --assume-clean -l5 -n4 \
     /dev/sdb1 missing /dev/sdd1 /dev/sde1
   

   इसे संख्या [3] सौंपी गई है। मुझे आश्चर्य है कि अगर यह समता ब्लॉकों की गणना के लिए प्रासंगिक है। यदि यह महत्वपूर्ण हो जाता है, तो मैं /dev/sdb1[0]लापता [1] के साथ सरणी को कैसे पुनः बना सकता हूं /dev/sdd1[2] /dev/sde1[4]? अगर मुझे वह काम मिल जाए तो मैं /dev/sdc1इसे नीचा मोड में शुरू कर सकता हूं और नई ड्राइव जोड़ सकता हूं और इसे फिर से सिंक कर सकता हूं ।

यह ठीक है अगर आप मुझसे कहना चाहेंगे कि यह कार्रवाई का सबसे अच्छा कोर्स नहीं हो सकता है, लेकिन आप पाएंगे कि मुझे इसका एहसास हुआ। अगर किसी के पास कोई सुझाव हो तो बहुत अच्छा होगा।

Comments

+1 यह एक बहुत अच्छा विचार और प्रलेखित प्रश्न है। काश मेरे पास आपके लिए एक उत्तर होता।

— अनुदान

आपकी टिप्पणी के लिए धन्यवाद, मुझे लगता है कि यह एक कठिन है।

— पीटर बोस

क्या आपने इस पर ध्यान दिया है, या आप अभी भी इस पर काम कर रहे हैं? यदि आप इस पर काम कर रहे हैं, तो मेरी सलाह, आपके द्वारा बिछाई गई सभी ड्राइवों को साफ़ करें और एक अन्य मशीन पर एक JBOD बनाएं, जिससे आप DD चित्र बना सकते हैं, इससे निपटने के लिए बेहतर है कि आप इस तरह से अधिक से अधिक प्रयास कर सकते हैं। । (LVM का उपयोग करें और उसके समाप्त होने के बाद स्नैपशॉट का उपयोग करें, ताकि आप स्नैपशॉट को हटा सकते हैं और पूरी चीज़ को पुनः कॉपी नहीं करना पड़े)। मैं एक समान नाव में रहा हूं, और मैं अधिकांश डेटा अक्ष के साथ सरणी को पुनर्प्राप्त करने में कामयाब रहा।

— रीगन

आपकी प्रतिक्रिया के लिए धन्यवाद। थोड़ी देर बाद मैंने इस पर हार मान ली, दो ड्राइव को नए के साथ बदल दिया, बैकअप से 98% पुनर्प्राप्त किया, 2% डेटा हानि को स्वीकार किया और आगे बढ़ गया। अब मैं RAID-Z का उपयोग कर रहा हूं और मेरी बैकअप-रणनीति को अपडेट कर दिया है। अब तक सब ठीक है।

— पीटर बोस

Answer 1

आपके सवालों के जवाब देने के लिए,

1. क्या इसे बहाल किया जा सकता है?

   • पहली बात सबसे पहले - STOP, वापस बैठो और बस थोड़ा सोचो। हां, एल्गोरिथ्म, चंक आकार और डिस्क ऑर्डर जो भी फाइल सिस्टम मौजूद था, उसे ठीक से री-असेंबल करने के लिए महत्वपूर्ण है। लेकिन जब से आपने सुपरब्लॉक को ओवरराइट किया है, अब आप परीक्षण और त्रुटि से बचे हैं।
   • दूसरा, क्या कोई ऐसा तरीका है जिससे आप पिछले डिस्क लेआउट को पुनः प्राप्त कर सकते हैं? मैं हमेशा एक mdadm --detail> backupfile करता हूं ताकि उस डिस्क लेआउट को कहीं सुरक्षित रखा जा सके। छापे में डिस्क को कैसे कॉन्फ़िगर किया गया था, इसके किसी भी सबूत के लिए dmesg, / var / log की जाँच करें।
   • अंत में, यदि आप पिछले चंक आकार और डिस्क क्रम से मेल खाते हैं, तो आपने ext4 सुपरब्लॉक को नुकसान पहुंचाया हो सकता है - अन्य सुपरब्लॉक के लिए क्विकली स्कैन करने के तरीके हैं (और टेस्टडिस्क नामक एक निफ्टी प्रोग्राम है जो मौजूदा फाइल सिस्टम के सुपरब्लॉक के लिए स्कैन करता है और उन्हें ब्राउज़ करने की कोशिश करता है। मैन्युअल रूप से: http://www.cgsecurity.org/wiki/Main_Page )

2. चूँकि sdc नया है, मैं कोशिश करूँगा और लापता क्लॉज़ के माध्यम से मैन्युअल रूप से इकट्ठा करना चाहता हूँ, और हाँ, sde को सही क्रम में इसे अपमानित मोड में इकट्ठा करना होगा। एक बार जब आपको सही लेआउट मिल जाता है - सरणी से सभी डेटा की प्रतिलिपि बनाएँ और लेआउट को फिर से शुरू करें (ताकि आप इस मुद्दे पर फिर से न चलें)।

शुभ लाभ

Comments

ext3 / 4 निरर्थक सुपरब्लॉक लिखता है। इसके बजाय आप बैकअप सुपरब्लॉक का उपयोग करने के लिए माउंट या fsck के तर्क के रूप में सुपरब्लॉक ऑफ़सेट पास कर सकते हैं। फिर भी, RAID 5 = गेम ओवर में दो ड्राइव डाउन हो जाते हैं।

— dmourati

Answer 2

इससे पहले कि आप कुछ भी करें, प्रत्येक ड्राइव के लिए एक 'mdadm --examine / dev / sdX1' पर कब्जा करें, जो आपके सरणी में थे, और उसके बाद 'mdadm --detail / dev / md0', आपको निर्धारित करने में सक्षम होना चाहिए सटीक लेआउट।

मुझे सिर्फ एक अलग प्रश्न में एक Synology सरणी को पुनर्प्राप्त करने के लिए खुद ऐसा करना पड़ा:

"ई" राज्य में ड्राइव के साथ Synology NAS पर एक mdadm सरणी कैसे पुनर्प्राप्त करें?

संपादित करें: क्षमा करें, बस देखा कि आपने कहा कि आपने सभी ड्राइव पर सुपरब्लॉक खो दिए हैं।

आपका बाद में LOOK सही है। सबसे सरल विकल्प हो सकता है कि आप प्रत्येक संभावित ऑर्डर के साथ क्रिएट्स को चलाएं, और फिर देखें कि क्या आप केवल रीड-ओनली पर फाइल सिस्टम को माउंट और एक्सेस कर सकते हैं।

Answer 3

यह प्रश्न पुराना है और मुझे यकीन है कि अब कोई भी आपकी मदद नहीं कर सकता है, लेकिन दूसरों के पढ़ने के लिए:

आपके द्वारा की गई सबसे खतरनाक गलती वह नहीं है, जिसे आपने चलाया था:

mdadm --create ...

मूल डिस्क पर, इससे पहले कि आप यह जानने के लिए तैयार थे कि क्या करना है। इसने मेटाडेटा को अधिलेखित कर दिया है, इसलिए आपके पास ड्राइव ऑर्डर, डेटा ऑफ़सेट, चंक साइज़ आदि का कोई रिकॉर्ड नहीं है।

इससे उबरने के लिए, आपको सही मानों के साथ फिर से लिखना होगा। यह जानने का सबसे आसान तरीका मेटाडेटा को देखना है, लेकिन आपने इसे पहले ही नष्ट कर दिया है। अगला तरीका अनुमान लगाना है। इस तरह के एक कमांड के विभिन्न संयोजनों पर अनुमान लगाएं, किसी भी विकल्प के लिए अलग-अलग मानों के अलावा जो आप जानते हैं (4 डिवाइस, स्तर 5), और अलग-अलग डिस्क क्रम:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

लेकिन जब से आप सही परिणाम नहीं जानते हैं, फिर से, आपको पुराने डिस्क पर उन्हें नष्ट नहीं करना चाहिए, वही घातक गलती कर सकता है। इसके बजाय, एक ओवरले का उपयोग करें; उदाहरण के लिए इस प्रक्रिया को मूल लोगों को सुरक्षित रखने के लिए काम करना चाहिए।

एक बार जब आपको कुछ ऐसे तर्क मिल जाते हैं जो एक कार्यशील सरणी का निर्माण करते हैं जिसे आप fsck या माउंट कर सकते हैं और सत्यापित कर सकते हैं (उदाहरण के लिए, किसी फ़ाइल के चेकसम को पर्याप्त रूप से सभी छापे वाले सदस्यों को एक आईएसओ की तरह फैला सकते हैं, जिसे आपको अपने चेकसम / ggp के साथ संग्रहित करना चाहिए। हस्ताक्षर, या अनज़िप -t या गनज़िप -टा बड़े संग्रह)

Comments

धन्यवाद। इस बीच, मैं ZFS (RAIDZ2) का उपयोग करने के लिए आगे बढ़ा हूं। हालांकि, अपने नोट्स पढ़ना बहुत दिलचस्प था। मुझे अब एहसास हुआ कि क्रिएट कमांड ने मेटाडेटा को अधिलेखित कर दिया, जबकि उस समय मैंने मान लिया था कि यह नहीं होगा। इसके अलावा, मैं ओवरले फ़ाइलों के बारे में नहीं जानता था। यह वास्तव में साफ है! धन्यवाद!

— पीटर बॉश