क्या ddresoscope को गति देने का कोई तरीका है?

26

मैंने 5 दिन पहले 500GB ड्राइव HDD क्रैश किया था। मैंने ddrescueकुछ दिनों पहले महत्वपूर्ण विभाजन पर उपयोग किया था, और यह लगभग 2 दिनों के लिए "ट्रिमिंग विफल ब्लॉकों" पर रहा है।

मूल आदेश:

ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log

मौजूदा उत्पादन:

Initial status (read from logfile)
rescued:   248992 MB,  errsize:   1007 MB,  errors:   15867
Current status
rescued:   249021 MB,  errsize:    978 MB,  current rate:    17408 B/s
   ipos:    44405 MB,   errors:   15866,    average rate:     2784 B/s
   opos:    44405 MB,     time from last successful read:       0 s
Trimming failed blocks...

मूल कमांड ने ddrescue -nपैरामीटर का उपयोग किया है, और मैंने आवश्यकतानुसार प्रक्रिया को कुछ बार फिर से शुरू किया है (और यह सही लग रहा था कि हर बार इसे छोड़ दिया गया था)।

क्या इस प्रक्रिया को गति देने का कोई तरीका है?

संपादित करें: छह घंटे बाद, यह वर्तमान स्थिति है:

rescued:   249079 MB,  errsize:    920 MB,  current rate:      409 B/s
   ipos:    39908 MB,   errors:   15851,    average rate:     2698 B/s
   opos:    39908 MB,     time from last successful read:       0 s
Trimming failed blocks...

ऐसा प्रतीत होता है कि जबकि "त्रुटियां" धीरे-धीरे धीरे-धीरे गिना जा रहा है, ipos / opos यह गिन रहा है कि इसके माध्यम से कितना डेटा मंथन करना है, और यह 750MB / घंटा की दर से काम कर रहा है। इस दर पर, यह ~ 53 घंटे में पूरा होगा। ओह।

# 2 संपादित करें: दो दिन बाद, अभी भी चल रहा है। हालाँकि, उम्मीद है। यह "ट्रिमिंग विफल ब्लॉक" भाग को पारित कर चुका है, और अगले चरण में "विभाजन विफल हुए"। यदि कुछ भी हो, तो इस प्रश्न को देखने से क्या लिया जाना चाहिए, यह निश्चित रूप से एक लंबा समय लगता है जब डेटा / त्रुटियों की एक अच्छी मात्रा शामिल होती है। मेरी एकमात्र आशा यह है कि मैं कुछ महत्वपूर्ण डेटा को सफलतापूर्वक प्राप्त कर सकता हूं जब सभी कहा और किया जाता है।

rescued:   249311 MB,  errsize:    688 MB,  current rate:        0 B/s
ipos:    26727 MB,   errors:   15905,    average rate:     1331 B/s
opos:    26727 MB,     time from last successful read:      20 s
Splitting failed blocks...

hard-drive-recovery ddrescue

— मैट बेकमैन
स्रोत

2

इसकी डिजाइन द्वारा, सबसे अधिक संभावना है। यह संभव के रूप में बाहर ज्यादा डेटा के रूप में निकालने के लिए कई गुजरता करता है

— जर्नीमैन गीक

17

अगली बार एक छोटी हार्ड ड्राइव क्रैश ;-)

— जॉय

मेरे 4TB को ट्रिमिंग चरण में आने के लिए 3 सप्ताह का समय लगा है ... (मुझे पूरा यकीन है कि यह सब समर्थित है, लेकिन बचाव के लिए कोई चोट नहीं है;) ... और धन्यवाद @nza, मैं बस उम्मीद कर रहा हूं मैं क्रिसमस

— स्टीफन

खैर ... आज सुबह मैंने गणना की कि ट्रिमिंग, और वॉइला की गति के आधार पर लगभग एक सप्ताह का समय था! हॊ गया! इसलिए ~ 3 सप्ताह ट्रिमिंग के लिए और ~ 3 सप्ताह ट्रिमिंग के लिए। स्क्रैपिंग वास्तव में तेज़ था, भले ही यह 1.93% डेटा था - मुझे लगता है कि अच्छा और बुरा डेटा तेज है ... बस बीच में धीमी गति से धीमा है? (मैं -Mआज सुबह सिर्फ रिबूट और डिस्ट-अपग्रेड के मामले में फिर से साथ चल रहा हूं )

— स्टीफन

14

मैंने देखा कि -n(नो-स्प्लिट) विकल्प को एक साथ -r 1(एक बार रिट्री) और सेटिंग -c(क्लस्टर आकार) का उपयोग करके छोटे मूल्य में मदद मिल सकती है।

मेरी धारणा यह है कि बंटवारे का कदम ddrescueविभाजन के रूप में बहुत धीमा है और क्षतिग्रस्त क्षेत्रों को फिर से विभाजित करता है। इसमें बहुत समय लगता है क्योंकि ddrescueडेटा के बहुत छोटे हिस्से को पुनर्स्थापित करने की कोशिश करता है। तो, मैं का उपयोग करना पसंद -nएक साथ (कोई विभाजित) के साथ -c 64, -c 32, -c 16, आसो

संभवतः -n(नो-स्प्लिट) हमेशा आगे और पीछे की दिशा में एक पहले पास के लिए इस्तेमाल किया जाना चाहिए। ऐसा लगता है कि डेटा जितना अधिक विभाजित किया गया था, क्लोनिंग को धीमा कर देता है, हालांकि मुझे इस बारे में निश्चित नहीं है। मैं बड़े गैर-इलाज वाले क्षेत्रों को मानता हूं, ddrescueफिर से चलाने के दौरान सबसे अच्छा है , क्योंकि अधिक सन्निहित क्षेत्र क्लोन करने के लिए हैं।

जब मैं लॉगफ़ाइल का उपयोग कर रहा होता हूं, तो डेटा के पढ़ने की गति दो कम हो जाने पर मैं Ctrl+ के साथ कमांड को रद्द करने में संकोच नहीं करता C।

मैं -R(रिवर्स) मोड का भी उपयोग करता हूं और पहली बार पास होने के बाद यह अक्सर मुझे आगे की तुलना में पीछे पढ़ने की उच्च गति देता है।

यह मेरे लिए स्पष्ट नहीं है कि कैसे पहले से ही रिटायर्ड सेक्टर ( -r N) को ddrescueफिर से कमांड चलाते समय संभाला जाता है , खासकर जब आगे (डिफ़ॉल्ट) और रिवर्स ( -R) क्लोनिंग कमांड को अल्टरनेट कर रहा हो । मुझे यकीन नहीं है कि अगर उनकी कोशिश की गई समय की संख्या को लॉगफ़ाइल में संग्रहीत किया जाता है और शायद काम फिर से बेकार हो जाता है।

संभवतः -i(इनपुट पोजिशन) ध्वज चीजों को गति देने में भी मदद कर सकता है।

— user208233
स्रोत

8

की प्रगति को देखना बहुत कठिन हो सकता है ddrescue, लेकिन इसमें एक और कमांड भी शामिल है जिसे कहा जाता है ddrescuelog।

एक साधारण आदेश ddrescuelog -t YourLog.txtइन अच्छे infos का उत्पादन करेगा:

current pos:     2016 GB,  current status: trimming
domain size:     3000 GB,  in    1 area(s)
rescued:     2998 GB,  in 12802 area(s)  ( 99.91%)
non-tried:         0 B,  in    0 area(s)  (  0%)

errsize:     2452 MB,  errors:   12801  (  0.08%)
non-trimmed:   178896 kB,  in 3395 area(s)  (  0.00%)
non-split:     2262 MB,  in 9803 area(s)  (  0.07%)
bad-sector:    10451 kB,  in 19613 area(s)  (  0.00%)

आप भी इसे ddrescueचल रहा है जबकि उपयोग कर सकते हैं ...

— nza
स्रोत

ट्रिमिंग के लिए मेरे 4TB प्राप्त करने के लिए 3 सप्ताह:

errsize:   289420 MB,  errors:   34926  (  7.23%) non-trimmed:   288130 MB,  in 105407 area(s)  (  7.20%)   non-split:     1243 MB,  in  185 area(s)  (  0.03%)  bad-sector:    47490 kB,  in 92728 area(s)  (  0.00%)

(... लेकिन धन्यवाद कमांड के लिए!

— स्टीफन

4

Ddresoscope की प्रगति (लिनक्स पर, कम से कम) की निगरानी करने का एक और तरीका स्ट्रेस के उपयोग के माध्यम से है।

सबसे पहले, "ps aux | grep ddrescue" का उपयोग करके ddrescue प्रक्रिया के लिए PID ढूंढें

root@mojo:~# ps aux | grep ddrescue
root     12083  0.2  0.0  15764  3248 pts/1    D+   17:15   0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root     12637  0.0  0.0  13588   940 pts/4    S+   17:46   0:00 grep --color=auto ddrescue

फिर उस प्रक्रिया के खिलाफ "स्ट्रेस" चलाएं। आप कुछ इस तरह देखेंगे:

root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET)       = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET)       = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET)       = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C

...और इसी तरह। आउटपुट तेज और बदसूरत है, इसलिए मैं इसके बाद "grep" के माध्यम से पाइप करता हूं ताकि मैं उस सामान को फ़िल्टर कर सकूं जिसकी मुझे परवाह है:

root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET)       = 1702212679168
lseek(3, 1702212678656, SEEK_SET)       = 1702212678656
lseek(4, 1702212678656, SEEK_SET)       = 1702212678656
lseek(3, 1702212678144, SEEK_SET)       = 1702212678144
lseek(4, 1702212678144, SEEK_SET)       = 1702212678144
lseek(3, 1702212677632, SEEK_SET)       = 1702212677632
lseek(4, 1702212677632, SEEK_SET)       = 1702212677632
lseek(3, 1702212677120, SEEK_SET)       = 1702212677120
lseek(4, 1702212677120, SEEK_SET)       = 1702212677120
lseek(3, 1702212676608, SEEK_SET)       = 1702212676608
^C

उस उदाहरण में, "1702212676608" "उस डेटा की मात्रा के बराबर है जिसे अभी भी उस 2 टीबी डिस्क पर संसाधित करने की आवश्यकता है जिसे आप उबारने की कोशिश कर रहे हैं।" (हाँ। आउच।) ddrescue अपने स्क्रीन आउटपुट में "1720 जीबी" के रूप में एक समान संख्या - यद्यपि बाहर थूक रहा है।

स्ट्रेस आपको जांच करने के लिए एक उच्च ग्रैन्युलैरिटी डेटा स्ट्रीम देता है; यह ddresoscope की गति का मूल्यांकन करने और एक पूरा होने की तारीख का अनुमान लगाने का एक और तरीका है।

इसे लगातार चलाना शायद एक बुरा प्लान है क्योंकि यह CPU समय के लिए ddrescue के साथ प्रतिस्पर्धा करेगा। मैंने इसे "सिर" से पाइप करने के लिए लिया है, इसलिए मैं पहले 10 मूल्यों को पकड़ सकता हूं:

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

आशा है कि यह किसी की मदद करता है।

— पीटर के
स्रोत

वहाँ strace -e lseek …है कि के लिए - हालांकि pv -d <pid>सुंदर हो सकता है।

— ग्रिटिटी

3

यदि आपका उद्देश्य डेटा के थोक प्राप्त करना है, तो आप इसके निष्कर्षण को गति दे सकते हैं। लेकिन अगर आप वास्तव में जितना संभव हो उतना डेटा बचाव करना चाहते हैं, तो प्रत्येक पर ddreoscope को कुतरने देना और लेने का मार्ग है।

— MVG
स्रोत

2

वास्तव में ऐसा कैसे करें?

— विलियम एंट्रीकेन

3

मैंने पाया है कि -के पैरामीटर के साथ खेलने से आप चीजों को गति दे सकते हैं। अगर मैंने देखा है कि अगर ddresoscope को कोई त्रुटि मिलती है तो -n विकल्प के साथ चलने से सेक्टर की एक निश्चित राशि को कूदने की कोशिश की जाती है। अगर यह अभी भी नहीं पढ़ सकता है तो यह आकार दोगुना हो जाता है। यदि आपके पास बड़े क्षतिग्रस्त क्षेत्र हैं, तो आप एक बड़े K मान (उदाहरण के लिए 100M) का संकेत दे सकते हैं और इसलिए किसी त्रुटि पर कूदना पहली बार बड़ा होगा और पहले वाले क्षेत्रों में समस्याग्रस्त क्षेत्रों से जल्दी से बचना आसान होगा।

वैसे, लॉग का विश्लेषण करने के लिए एक अद्भुत चित्रमय अनुप्रयोग है।

http://sourceforge.net/projects/ddrescueview/

— जोसफ
स्रोत

0

हार्ड डिस्क की फ़ाइल प्रणाली क्या है जहाँ आप बचाव छवि और लॉगफ़ाइल को बचाते हैं? मैंने अभी अनुभव किया है कि USB स्टिक से लिनक्स मिंट पर चलने वाले लैपटॉप पर 500GB की आंतरिक हार्ड ड्राइव (SATA के माध्यम से जुड़ा हुआ) को बचाया, एक exFatफॉर्मेट किए गए USB हार्ड ड्राइव पर बचाव छवि और लॉगफाइल को बचाने के बजाय धीरे-धीरे शुरू हो रहा था (1-2MB / 1-2) सेकंड) लेकिन लगभग 250GB के बाद यह केवल <100KB / सेकंड पर रेंग रहा था। ऐसा लग रहा था कि बचाव की फाइल बड़ी होने से धीमी हो रही थी।

फिर मैंने बचाव चित्र और लॉगफ़ाइल को एक अन्य अस्थायी स्थान ext4पर स्थानांतरित कर दिया, फ़ाइल सिस्टम के साथ USB हार्ड ड्राइव को पुन: स्वरूपित किया , उस पर फ़ाइलों को वापस ले आया और ddrescue प्रक्रिया को फिर से शुरू किया - और अब यह 1-20MB / सेकंड के साथ फिर से चलता है (उतार-चढ़ाव) लेकिन लगभग 7MB / सेकंड औसत पर)!

लगता है जैसे exFatबहुत बड़ी फ़ाइलों (कई सौ गीगाबाइट) के साथ बहुत अच्छा नहीं खेलता है।

— एक प्रकार की कटार
स्रोत

0

डिस्क को बचाने के लिए एक तेज और त्वरित विकल्प के लिए आप एक श स्क्रिप्ट फ़ाइल का उपयोग कर सकते हैं और फ़ाइल को "sh filename.sh" के साथ चला सकते हैं। इसमें इस लाइन को दिखाया गया है, बस "sudo ddrescue" और "नींद 3" को कुछ और बार दोहराएं, नींद का उपयोग ड्राइव को कुछ सेकंड आराम करने के लिए किया जाता है, यह कुछ कारणों से अच्छा हो सकता है:

#! /bin/sh -e  
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

-R0 कोई उत्तर नहीं है। -E +0 1 त्रुटि पर बाहर निकलने के लिए है। -T 1s 1 सेकंड के असफल पढ़ने के साथ बाहर निकलता है। ऐसे विकल्प हैं जिनका उपयोग -d के रूप में किया जा सकता है, प्रत्यक्ष और -n के लिए कोई परिमार्जन नहीं है जो गति प्रदान कर सकता है।

आप विकल्प के साथ खत्म होने के बाद -R का उपयोग कर सकते हैं-एक बार, जो सभी त्रुटियों को उल्टा और हटा देगा और फिर से पीछे की ओर शुरू होगा। इसका मतलब है कि यह त्रुटियों को अलग तरीके से पढ़ेगा।

— Dealazer
स्रोत

-1

dd_rhelp एक शेल स्क्रिप्ट है जो आपके संपूर्ण डिस्क पर dd_rescue "[...] का उपयोग करता है, लेकिन क्या यह बैडसेक्टर्स के गुच्छों पर उम्र के लिए प्रयास करने से पहले अधिकतम वैध डेटा इकट्ठा करने की कोशिश करेगा"

यह काफी पुराना है (2012) लेकिन फिर भी काम करता है। अभी तक ddrescue की कोशिश नहीं की है।

— कोस्टिन गुआ
स्रोत

सवाल GNU ddresoscope (नहीं dd_rescue) के बारे में है, जो वास्तव में इस स्क्रिप्ट का एक बेहतर प्रतिस्थापन है।

— kinokijuf