क्या यह ddrescue कमांड कुछ भी कर रहा है?

Question

असफल हार्ड ड्राइव से डेटा को पुनर्प्राप्त करने की कोशिश के दौरान , मैं कमांड चला रहा हूं ddrescue।

कमांड 9 दिनों से चल रहा है, और मैंने डिस्क गतिविधि की आवाज़ से सोचा कि शायद यह कुछ कर रहा था। कमांड लाइन आउटपुट इस समय अधिक या कम स्थिर दिख रहा है:

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

एक हिस्सा जो बदलता रहा है, वह है जहां वह कहता है iposऔर opos। चारों ओर उठने में 9 दिन लगे 500000 MB, जो कि फेल डिस्क ड्राइव का आकार है। जब यह वहां 0पहुंच गया, हालांकि, यह फिर से नीचे गिर गया और फिर से बढ़ने लगा। जैसा कि मैंने यह लिखा है, इसके बारे में 2580 MBऔर गिनती में है।

बनाई जा रही छवि फ़ाइल लंबाई में 0 बाइट्स है।

लॉग फ़ाइल लगभग 3MB आकार की है और इस तरह दिखती है:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

मैं चिंतित होना शुरू कर रहा हूं कि यह केवल समय की बर्बादी है और कोई डेटा बिल्कुल भी पुनर्प्राप्त नहीं किया जा रहा है।

क्या इस आउटपुट से कोई संकेत मिलता है कि कुछ उपयोगी हो रहा है?

क्या ddrescueकमांड को जारी रखने का कोई कारण है या क्या मुझे इसे रोकना चाहिए और कुछ और करना चाहिए?

---

यह सबसे हाल की सामग्री है /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

Answer 1

मुझे नहीं पता कि क्या आप अभी भी उस हार्ड ड्राइव से डेटा निकालने की कोशिश कर रहे हैं या यदि आप पहले से ही सफल थे, लेकिन अगर आप सफल नहीं हुए हैं और यह देखने की कोशिश करना चाहते हैं कि क्या आप ठीक हो सकते हैं, शायद, खो गए बिटकॉइन या जो भी हो, मैंने आपके ddrescueकमांड लाइन मापदंडों में कुछ संशोधन किए हैं , मैंने निम्नलिखित जोड़े हैं:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d जो ddresoscope को डायरेक्ट डिस्क एक्सेस का उपयोग करने के लिए कहता है,
• --फोर्स जो ddrescue को जबरदस्ती इस्तेमाल करने और पढ़ने / लिखने के बारे में बताता है, अगर वह शिकायत करता है कि वह इसे पढ़ने / लिखने के उद्देश्यों के लिए उपयोग नहीं कर सकता है
• -R (हाँ, CAPITAL R के साथ) जो ddrescueआगे की मोड में विफल हार्ड ड्राइव को पढ़ने के बजाय रिवर्स में रिकवरी ऑपरेशन करने के लिए कहता है। कभी-कभी रिवर्स में पढ़ने से मदद मिलती है जब नुकसान पर्याप्त होता है क्योंकि यह हार्ड ड्राइव के कैश को बायपास कर देता है यदि समस्या होती है।

वर्तमान में मैं इन आदेशों का उपयोग कर रहा हूं (इसके अलावा मैं 3कमांड का उपयोग नहीं कर रहा हूं क्योंकि मैं नहीं चाहता कि [YET] ddrescueखराब क्षेत्रों को फिर से प्रयास करूं, मैं इसे छोड़ दूंगा, आखिरकार, मेरे पहले स्वीप के बाद, और मुझे एक बड़ी सफलता मिल रही है मेरे 1TB सीगेट का डेटा हार्ड ड्राइव में विफल रहा, जहां मैं ASSUME कुछ बिटकॉइन धारण कर सकता हूं, जो कि मैं 2009 से 2010 तक वापस खनन कर रहा हूं, शायद मुझे 50 बीटीसी प्रत्येक में से 1 से 3 ब्लॉक मिले, मुझे आशा है कि यह इस हार्ड ड्राइव पर है, ठीक है, 634 केबीपीएस औसत की रीड रेट पर ऑपरेशन को पूरा करने में मुझे कुल 15 दिनों का समय लगेगा।

इसके अलावा, मैं "अंतिम पठन गतिविधि" के 9 DAYS से अधिक के अपने पिछले ट्रैक रिकॉर्ड के आधार पर आपको और सबसे अधिक संभावना यह जोड़ना चाहूंगा कि आप ऐसी स्थिति का सामना करेंगे जहां हार्ड ड्राइव बस किसी भी आगे पढ़ने से इनकार कर देगी, उसमें स्थिति, बस CTRL + C दबाएं क्योंकि आप लॉग फ़ाइल का उपयोग कर रहे हैं, असफल हार्ड ड्राइव से SATA केबल को हटा दें, लेकिन USB पोर्ट से USB नियंत्रक को बंद नहीं करें (हाँ, इसे कनेक्ट करने के बजाय USB SATA नियंत्रक का उपयोग करें एक मदरबोर्ड तो यह आपके पूरे कंप्यूटर को लॉक नहीं करेगा जिससे आपको हार्ड रिबूट करने के लिए मजबूर होना पड़े, और फिर हार्ड ड्राइव को पुनः आरंभ करने के लिए SATA पावर में प्लग करें, इसे 10 सेकंड तक दें और फिर अपने पिछले टर्मिनल को पुनः लोड करने के लिए ऊपर या नीचे तीर दबाएं। कमान और पुनः आरंभ करेंddrescueऑपरेशन, आपके पिछले लॉग के लिए धन्यवाद, यह जारी रहेगा जहां यह अंतिम छोड़ दिया गया है और वहां रीडिंग की जा रही है और "अंतिम सफल रीड" हमेशा "0s" (शून्य सेकंड) पर रहेगा जहां यह होना चाहिए, यह दर्शाता है कि ddrescueसफल हो रहा है हार्ड ड्राइव से पढ़ने, और आप कभी भी सूचना है कि सेकंड गिनती शुरू होता है "से पिछले पढ़ने", बस एक बार फिर से समाप्त कर ddrescueके साथ CTRL+ C, शक्ति चक्र हार्ड ड्राइव, और पुन: प्रारंभddrescue, यह देखने के लिए प्रतीक्षा करने का कोई मतलब नहीं है कि क्या "आखिरी बार पढ़ा गया" अपने दम पर फिर से 0s पर लौटता है, मेरे अनुभव के आधार पर यह कभी नहीं होने वाला है, आप अनंत काल की प्रतीक्षा कर रहे होंगे। मुझे अपनी खराब 1 टीबी हार्ड ड्राइव को लगभग 20 बार साइकिल चलाना था, यह 7 दिनों की तरह है और मैं 500 जीबी पुनर्प्राप्त निशान तक पहुंचने के बहुत करीब हूं, आधा रास्ता अभी भी जाना है, आशा है कि मैं किसी भी बड़ी असफलता का सामना नहीं करूंगा मैं 100% के पास हूं क्योंकि यह पिछले 3 दिनों से दोषपूर्ण तरीके से चल रहा है, फिर से 634 केबीपीएस से अधिक।

इसके अलावा, तेज डेटा थ्रूपुट रीड रेट प्राप्त करने की कोशिश में लालची मत बनो, क्योंकि कई मापदंडों और अलग-अलग ब्लॉक आकारों की कोशिश करने के मेरे प्रयास ने मुझे लगभग पूरी तरह से मृत हार्ड राइव के साथ छोड़ दिया, जो पावर साइकलिंग के बाद 1 सेकंड से अधिक काम करना बंद कर देगा। (यह 5 दिन पहले था) लेकिन शुक्र है कि यह सिर्फ एक बार फिर से जीवन का संकेत दिखाते हुए शुरू हुआ, शुरू में 2,000 bs (हाँ प्रति सेकंड BYTES) 2kbps से थोड़ा कम पढ़ा, मैं बहुत निराश था, लेकिन रद्द करने के बादddrescueCTRL + C के साथ और बस इसे एक बार फिर से (-R के साथ रिवर्स में) पैरामीटर को जोड़ा गया, फिर गति 630 हो गई, इससे पहले कि मैं 930 केबीपीएस पर आगे पढ़ रहा था, कम से कम मैं सामग्री हूं कि मैं रिवर्स में 630 केबीपीएस कर रहा हूं और 2kbps के साथ नहीं डालना है, इसलिए यदि आप किसी भी पढ़ने की गति पर सफलता प्राप्त करते हैं, जैसे कि 500 ​​kbps की सीमा इसके साथ रहती है और किसी भी उच्च गति को पुश करने के लिए कुछ भी प्रयास न करें, तो यह लाभ प्राप्त करने का आपका अंतिम सफल प्रयास हो सकता है कोई भी पढ़ने की गति।

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

Comments

आप पाठ की उस दीवार को थोड़ा नीचे संपादित करना चाह सकते हैं।

— स्लम

वास्तव में मुझे लगा कि मैं इस विषय पर सबसे रचनात्मक और विस्तृत पोस्टों में से एक था। मुझे आशा है कि आपको कोई आपत्ति नहीं है, मैंने अभी एक ऐसा ही सवाल unix.stackexchange.com/q/219365/125662 में जोड़ा है जिसमें आपके वास्तव में सहायक योगदान का उल्लेख है

— baroquedub

GNU ddrescue मैनुअल से: "--फोर्स फोर्स ने आउटफिट को ओवरराइट कर दिया। जरूरत तब पड़ती है जब आउटफिट एक रेगुलर फाइल नहीं, बल्कि डिवाइस या पार्टीशन हो। यह ऑप्शन सिर्फ पार्टीशन के अनजाने विनाश को रोकने के लिए एक सेफगार्ड है, और रेगुलर फाइल्स के लिए नजरअंदाज कर दिया जाता है। । " यह मैपफाइल / लॉगफाइल के बारे में नहीं है ।

— आर्क लिनक्स टक्स

कृपया का वर्णन ठीक --forceविकल्प है, यह सही नहीं है

— endolith

Answer 2

आपको ddrescueइसे रोकने में सक्षम होना चाहिए क्योंकि यह लॉग फ़ाइल का उपयोग करता है ताकि इसके संचालन (पास) को फिर से शुरू करने में सक्षम हो जहां से इसे छोड़ा था। मैं जाँच करूँगा कि क्या लॉगफ़ाइल को हाल ही में टाइमस्टैम्प या कर के अपडेट किया गया है tail -f /home/dave/recovery_usb500.logfile।

आपकी छवि फ़ाइल अभी भी है कि छोटे को अभी तक ड्राइव से सफलतापूर्वक पुनर्प्राप्त किए जाने वाले ब्लॉक के साथ करना पड़ सकता है। हालांकि यह सब चलने के बाद बुरा परिणाम होगा। यह मानते हुए कि डिवाइस पर कुछ ख़राब ब्लॉक हैं, और यह कि वे शुरुआत में नहीं हैं, आपकी पहली प्रविष्टियाँ स्थिति होंगी +। IIRC ddrescueतब तक पढ़ना शुरू करता है जब तक कि उसे कोई त्रुटि नहीं मिल जाती है और फिर वह शेष डिस्क को विभाजित करना शुरू कर देता है। आपकी डिस्क शुरू से ही सही नहीं लगती है।

जब तक +लॉग में (कई) प्रविष्टियाँ नहीं होती हैं और आपकी फ़ाइल का आकार अभी भी होगा 0मुझे नहीं लगता कि ddrescueयह गलत है। कोई +रों मतलब अपने ड्राइव से कि कुछ भी नहीं वसूली योग्य था। इसका मतलब हो सकता है कि तले हुए इलेक्ट्रॉनिक्स या एक बुरा सिर, जैसा कि सिर्फ कुछ क्षेत्रों के दोषपूर्ण होने के कारण आपके परिणाम बहुत जल्दी आए होंगे।

जैसा कि कुछ और करने के लिए। मुझे लगता है कि आप पहले से ही सामान्य dd के साथ कुछ ब्लॉकों को पढ़ने की कोशिश कर रहे हैं। क्या आपने उस पर आधारित syslog को देखा है और आपने वहां पाए गए किसी भी संदेश को देखा है?

---

"परिणाम: hostbyte = अमान्य ड्राइवर के लिए खोज = DRIVER_SENSE" के परिणाम कुछ और सुझावों के साथ कुछ दिलचस्प पढ़े (आंशिक रूप से जर्मन) हैं:

• 2.0 के बजाय USB 1.1 के माध्यम से कनेक्ट करने का प्रयास करें
• ड्राइव गर्म हो सकती है, इसलिए इसे प्लास्टिक में लपेटें और इसे 10 मिनट के लिए फ्रिज में रख दें, इससे ड्राइव को दोबारा गर्म होने से पहले कुछ पठनीयता का समय मिल जाता है।
• BIOS में SMART का स्विच (और SATA से कनेक्ट करें)।
• सुनिश्चित करें कि USB ड्राइव में पर्याप्त शक्ति (अतिरिक्त बिजली की आपूर्ति) है
• यदि कुछ समय के बाद USB पर पढ़ना विफल हो जाता है, तो दूरस्थ रूप से नियंत्रित USB हब का उपयोग करें जहां आप प्रोग्राम को USB HUB से कुछ सेकंड के लिए ड्राइव करने के लिए पावर टॉगल करते हैं।

एक अपठनीय डिस्क (कूलिंग स्प्रे के साथ) को ठंडा करने के अलावा मैंने इनमें से किसी को भी आज़माया नहीं है।

Comments

प्रतिक्रिया देने के लिये धन्यवाद। मैंने "सामान्य" कोशिश नहीं की है dd, क्योंकि मुझे नहीं पता कि वह क्या है। मेरी आंत महसूस करती है कि अधिकांश ड्राइव और डेटा बरकरार है, लेकिन डिस्क के कुछ महत्वपूर्ण क्षेत्र में कुछ दोष है जहां अनुक्रमण या फाइलों को सूचीबद्ध करना होता है।

— प्रश्नकर्ता

आप इस बात पर विचार कर सकते ddrescueहैं ddकि जब कोई त्रुटि सामने आती है तो उसका व्युत्पन्न नहीं होता है। क्या आपने +संकेतों की जांच की ?

— एंथन

लॉग फ़ाइल में, कोई +संकेत नहीं हैं । केवल -और \ संकेत हैं।

— प्रश्नकर्ता

इसका मतलब है कि अभी तक कुछ भी बरामद नहीं हुआ है, और मुझे लगता है कि इसकी संभावना कम है जो ddrescueइस समय के बाद शुरू होगी। यदि आप चाहें तो हम इस बारे में (इस पृष्ठ के शीर्ष लिंक) चैट कर सकते हैं

— एंथन

मैंने /var/log/syslogप्रश्न की सामग्री जोड़ दी है ।

— प्रश्नकर्ता