वर्तमान स्थिति का उपयोग करके GNU ddrescue (1.18.1) के पूरा होने के लिए छोरों / समय का अनुमान कैसे लगाया जाए?

Question

पृष्ठभूमि / प्रसंग:

मैं वर्तमान में एक USB से डेटा को पुनर्प्राप्त करने के लिए GNU ddresoscope 1.18.1 चला रहा हूं, जिसे मैंने डिस्क 2s1 विभाजन पर एक वर्चुअल डिस्क छवि लिखते समय एक केबल डिस्कनेक्ट का अनुभव किया था। प्रारंभ में मैं अपना दूसरा विभाजन (डिस्क 2 एस 2) ठीक कर रहा हूं और ध्यान देता हूं कि मैं तीसरे चरण (स्प्लिटिंग) में पहुंच गया हूं। मैं छवि को नेटवर्क स्टोरेज पर रख रहा हूं।

सवाल:

मैंने देखा है कि यह चरण लूप है। क्या मेरी वर्तमान स्थिति की जानकारी (मैं केवल दो त्रुटियां दिखा रहा हूं) को देखते हुए, मेरे द्वारा अनुभव की जा रही छोरों की संख्या की गणना करने का एक तरीका है?

स्थिति:

अपडेट / संपादित करें:

इसलिए मुझे अभी भी बहुत दिलचस्पी है कि कैसे ddrescue टूल का उपयोग करने के लिए छोरों / समय का अनुमान लगाया जा सकता है। टिप्पणियों के अनुसार, मैं अपने डिस्क2s1 विभाजन के लिए एक लॉग फ़ाइल का मूल्यांकन जोड़ रहा हूं क्योंकि वर्तमान में चल रहा है (डिस्क 2 एस 2 14.5 घंटे के बाद पूरा हो गया है, लगभग 6 घंटे के लिए एक उपयोगकर्ता रुकावट के साथ)।

पूर्ण विभाजन लॉग

विभाजन के लिए जो अभी पूरा हुआ है, यहां लॉग निरीक्षण का परिणाम है।

संदर्भ (ddrescue एल्गोरिथम नोट):

4 एल्गोरिथ्म

---

GNU ddrescue dd का व्युत्पन्न नहीं है, न ही dd से किसी भी तरह से संबंधित है, सिवाय इसके कि दोनों का उपयोग एक डिवाइस से दूसरे डिवाइस में डेटा कॉपी करने के लिए किया जा सकता है। मुख्य अंतर यह है कि ddresoscope विफल ड्राइव से डेटा को कॉपी करने के लिए एक परिष्कृत एल्गोरिथ्म का उपयोग करता है जिससे उन्हें यथासंभव कम अतिरिक्त नुकसान होता है।

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

मानक dd यूटिलिटी का उपयोग डेटा को एक फेलिंग ड्राइव से बचाने के लिए किया जा सकता है, लेकिन यह डेटा को क्रमिक रूप से पढ़ता है, जो ड्राइव की शुरुआत में त्रुटियां होने पर बिना किसी बचाव के ड्राइव को निकाल सकता है।

अन्य प्रोग्राम डेटा को क्रमिक रूप से पढ़ते हैं लेकिन जब वे त्रुटियां पाते हैं तो छोटे आकार के स्विच पर जाते हैं। यह एक बुरा विचार है क्योंकि इसका मतलब है कि त्रुटि क्षेत्रों में अधिक समय बिताना, जितना संभव हो उतनी तेजी से बाहर निकलने के बजाय, सतह, सिर और ड्राइव यांत्रिकी को नुकसान पहुंचाएं। यह व्यवहार शेष अच्छे डेटा को बचाने की संभावना को कम करता है।

Ddresoscope का एल्गोरिथ्म इस प्रकार है (उपयोगकर्ता किसी भी बिंदु पर प्रक्रिया को बाधित कर सकता है, लेकिन इस बात से अवगत रहें कि खराब ड्राइव लंबे समय तक ddresoscope को तब तक के लिए अवरुद्ध कर सकती है जब तक कि कर्नेल नहीं छोड़ देता):

1) वैकल्पिक रूप से एक बहुस्तरीय या पहले से बाधित बचाव की स्थिति का वर्णन करने वाला लॉगफ़ाइल पढ़ें। यदि कोई लॉगफाइल निर्दिष्ट नहीं है या खाली है या मौजूद नहीं है, तो सभी बचाव डोमेन को गैर-कोशिश के रूप में चिह्नित करें।

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

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

4) (तीसरा चरण; बंटवारा) सबसे बड़े गैर-विभाजित ब्लॉक के केंद्र से एक समय में एक सेक्टर को पढ़ें, जब तक कि एक खराब सेक्टर न मिल जाए। फिर, यदि पाया गया खराब सेक्टर पहले वाला नहीं है, तो एक ही ब्लॉक के केंद्र से एक समय में एक सेक्टर को पीछे की ओर पढ़ें, जब तक कि एक खराब सेक्टर न मिल जाए। यदि लॉगफाइल '--logfile- आकार' से बड़ा है, तो क्रमिक रूप से सबसे बड़ा गैर-विभाजन ब्लॉक पढ़ें जब तक कि लॉगफ़ाइल फाइल में प्रविष्टियों की संख्या '--logfile-size' से नीचे न हो जाए। तब तक दोहराएं जब तक कि सभी शेष गैर-विभाजित ब्लॉक में 7 से कम क्षेत्र न हों। फिर शेष गैर-विभाजन ब्लॉकों को क्रमिक रूप से पढ़ें।

5) (चौथा चरण; पुन: प्रयास) वैकल्पिक रूप से खराब क्षेत्रों को फिर से पढ़ने की कोशिश करें, जब तक कि रिट्री पास की निर्दिष्ट संख्या नहीं हो जाती। प्रत्येक खराब क्षेत्र को केवल एक बार पास करने की कोशिश की जाती है। Ddresoscope को पता नहीं चल सकता है कि क्या एक खराब क्षेत्र अप्राप्य है या यदि यह अंततः कुछ रिट्रीट के बाद पढ़ा जाएगा।

6) वैकल्पिक रूप से बाद में उपयोग के लिए एक लॉगफाइल लिखें।

कुल त्रुटि आकार ('त्रुटिपूर्ण') सभी गैर-छंटनी, गैर-विभाजित और खराब-क्षेत्र ब्लॉक के आकार का योग है। यह नकल के चरण के दौरान बढ़ता है और ट्रिमिंग, विभाजन और पुन: प्रयास के दौरान घट सकता है। ध्यान दें कि ddrescue विफल ब्लॉकों को विभाजित करता है, जिससे उन्हें छोटा बना दिया जाता है, त्रुटियों की संख्या बढ़ने पर कुल त्रुटि आकार घट सकता है।

लॉगफ़ाइल को समय-समय पर डिस्क में सहेजा जाता है, साथ ही साथ जब ddresoscope खत्म होता है या बाधित होता है। इसलिए दुर्घटना की स्थिति में आप बचाव को थोड़ा फिर से शुरू कर सकते हैं। सेवफ़ल के बीच का अंतराल 30 सेकंड से 5 मिनट तक भिन्न होता है जो लॉगफ़ाइल आकार पर निर्भर करता है (बड़े लॉगफ़ाइल्स लंबे अंतराल पर सहेजे जाते हैं)।

इसके अलावा, एक ही लॉगफ़ाइल का उपयोग कई कमांड के लिए किया जा सकता है जो इनपुट फ़ाइल के विभिन्न क्षेत्रों की प्रतिलिपि बनाते हैं, और विभिन्न सबसेट पर कई पुनर्प्राप्ति प्रयासों के लिए। इस उदाहरण को देखें:

सबसे पहले डिस्क के सबसे महत्वपूर्ण हिस्से को रेस्क्यू करें। ddrescue -i0 -s50MiB / dev / hdc hdimage logfile ddrescue -i0 -s1MiB -d3 / dev / hdc hdimage logfile

फिर कुछ प्रमुख डिस्क क्षेत्रों को बचाएं। ddrescue -i30GiB -s10GiB / dev / hdc hdimage logfile ddrescue -i230GiB -s5GiB / dev / hdc hdimage logfile

अब बाकी को बचा लें (जो पहले से हो चुका है, उसे दोबारा याद न करें)। ddrescue / dev / hdc hdimage logfile ddrescue -d3 -r3 / dev / hdc hdimage logfile

Comments

क्या डिस्क अभी भी एक ही डिवाइस के नाम से जुड़ी हुई है? इसके अलावा आपको ddrescueकेवल तभी डिस्क की आवश्यकता होगी जब डिस्क में खराब ब्लॉक हों, जो "केबल डिस्कनेक्ट" के कारण नहीं होगा। अगर आपको केबल की समस्या है, तो बस एक अलग केबल आज़माएं ...

— frostschutz

@TommieC। क्या आप ddrescuelog -t YourLog.txtदूसरे टर्मिनल में कोशिश कर सकते हैं ?

— बस_मेरे

@Simply_Me कृपया अपडेट किए गए प्रश्न को दो परिणामों को दर्शाते हुए देखें।

— टॉमी सी।

@frostschutz अधिक जानकारी के लिए कृपया अद्यतन प्रश्न देखें। डिस्क को लिखते समय खो केबल कनेक्शन हुआ और विभाजन तालिका के साथ समस्याएं पैदा हुईं। केबल स्वयं अनमैडेड है।

— टॉमी सी।

केबल डिस्कनेक्ट आमतौर पर तार्किक त्रुटियों का कारण होगा (यानी डिस्क पर डेटा 100% वैध नहीं है), लेकिन ड्राइव के साथ शारीरिक समस्याएं पैदा नहीं करेगा - जब तक कि आप इसे एक ही समय में नहीं गिराते। ddrescueकेवल शारीरिक समस्याओं को ठीक करने की कोशिश कर सकता है और तार्किक त्रुटियों के साथ बिल्कुल भी मदद नहीं करेगा। बाद के लिए, कोशिश करें fsckया एक जैसे ..

— Udo G

Answer 1

भले ही सवाल 10 महीने पहले पूछा गया था, जवाब प्रासंगिक हो सकता है क्योंकि वसूली चक्र अभी भी कुछ कारकों के आधार पर चल सकता है! मजाक नहीं।

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

"छोरों" के अनुमान से, यदि आप रिट्रीस की संख्या का मतलब है, तो यह कुछ ऐसा है जो आप निर्धारित मापदंडों द्वारा उपयोग करते हैं। यदि आप "कुल पास की संख्या" का मतलब है, जो आसानी से एल्गोरिथ्म के बारे में यहाँ पढ़कर निर्धारित किया जाता है .. > आदमी ddrescue </ एल्गोरिथ्म: कैसे ddresoscope डेटा को ठीक करता है

मैं विशेष रूप से आपके द्वारा प्रदत्त स्क्रीन कैप्चर के नंबरों से बात करूंगा। अन्य स्थितियों में लागू होने वाले अन्य कारक हो सकते हैं, इसलिए इस जानकारी को एक सामान्य दिशानिर्देश के रूप में लें।

आपके द्वारा प्रदान किए गए नमूने में ddresoscope की रनिंग स्टेटस स्क्रीन पर एक नज़र डालें। हमें समस्या (बचाव डोमेन) का कुल "अनुमान" "त्रुटिपूर्ण" मिलता है। यह डेटा की मात्रा है जो "पढ़ा जाना अभी बाकी है"। नमूने में यह 345GB है। दाईं ओर नीचे की अगली पंक्ति "औसत दर" है। नमूने में यह 583kb / s है

यदि "औसत दर" स्थिर रहने के करीब थी, तो इसका मतलब है कि आपके पास जाने के लिए 7 और दिन हैं। 345 GB / (583 kb * 60 * 60 * 24) = 7.18 हालाँकि समस्या यह है कि आप 583kb / s पर भरोसा नहीं कर सकते। वास्तव में गहराई से आप रिकवरी में जाते हैं, ड्राइव धीमी हो जाती है क्योंकि यह अधिक से अधिक कठिन क्षेत्रों को पढ़ रहा है और अधिक रिट्रीट कर रहा है। इसलिए तेजी से खत्म करने का समय बढ़ जाता है। यह सब इस बात पर निर्भर करता है कि ड्राइव कितनी बुरी तरह क्षतिग्रस्त है।

आपके द्वारा प्रदान किया गया नमूना 10 घंटे पहले "सफल रीड" दिखाता है। यह कह रहा है कि यह वास्तव में 10+ घंटे के लिए ड्राइव से कुछ भी नहीं मिल रहा है। इससे पता चलता है कि आपके ड्राइव में 345GB मूल्य (या एक हिस्सा) डेटा शॉट हो सकता है। यह आपके लिए बहुत बुरी खबर है।

इसके विपरीत, मेरी दूसरी 500GB ड्राइव जिसने मुझे "SMART" त्रुटियां देना शुरू कर दिया था, को डिस्क टू डिस्क (किसी अन्य ड्राइव पर लॉग फाइल के साथ) कॉपी किया गया और पूरे ऑपरेशन में लगभग 8-9 घंटे लगे। इसका पिछला हिस्सा धीमा पड़ गया। लेकिन यह अभी भी सहने योग्य है। जबकि बहुत खराब ड्राइव, जैसा कि ऊपर बताया गया है कि पिछले 2 सप्ताह 500GB पर काम कर रहे हैं और अभी भी लगभग 4-5% की रिकवरी बाकी है।

HTH और YMMV