มีวิธีใดที่จะเร่งความเร็ว ddrescue?

ฉันมี HDD 500GB ไดรฟ์ล่มเมื่อประมาณ 5 วันที่แล้ว ฉันใช้ 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 ชั่วโมง Yikes

แก้ไข # 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...

ฉันสังเกตเห็นว่าการใช้ -n ตัวเลือก (ไม่แยก) พร้อมกับ -r 1 (ลองอีกครั้งหนึ่ง) และตั้งค่า -c (ขนาดคลัสเตอร์) เป็นค่าที่น้อยลงสามารถช่วยได้

ความประทับใจของฉันคือขั้นตอนการแยกนั้นช้ามาก ddrescue แยกและแยกพื้นที่ที่เสียหายอีกครั้ง ใช้เวลามากเพราะ ddrescue พยายามคืนค่าส่วนข้อมูลที่น้อยมาก ดังนั้นฉันชอบที่จะใช้ -n (ไม่แยก) พร้อมกับ -c 64, -c 32, -c 16, a.s.o.

น่าจะเป็น -n (ไม่แยก) ควรใช้สำหรับการส่งผ่านครั้งแรกในทิศทางไปข้างหน้าและย้อนกลับ ดูเหมือนว่ายิ่งมีการแบ่งข้อมูลมากเท่าไรการโคลนนิ่งก็ยิ่งช้าลง แต่ฉันก็ไม่แน่ใจ ฉันถือว่าพื้นที่ที่ไม่ได้รับการรักษาที่ใหญ่กว่าดีที่สุดเมื่อทำงาน ddrescue อีกครั้งเพราะภาคที่ต่อเนื่องกันจะต้องทำการโคลน

ขณะที่ฉันใช้ไฟล์บันทึกข้อมูลฉันไม่ลังเลที่จะยกเลิกคำสั่งด้วย Ctrl + C เมื่อความเร็วในการอ่านข้อมูลลดลงสองระดับ

ฉันยังใช้ -R โหมด (ย้อนกลับ) และหลังจากผ่านครั้งแรกบ่อยครั้งที่ฉันให้ความเร็วสูงกว่าการอ่านไปข้างหลังมากกว่าไปข้างหน้า

ยังไม่ชัดเจนสำหรับฉันว่าภาคที่ลองใหม่อยู่แล้ว ( -r N ) ได้รับการจัดการเมื่อเรียกใช้ ddrescue คำสั่งอีกครั้งโดยเฉพาะอย่างยิ่งเมื่อสลับไปข้างหน้า (ค่าเริ่มต้น) และย้อนกลับ ( -R ) คำสั่งการโคลน ฉันไม่แน่ใจว่าจำนวนครั้งที่พวกเขาพยายามจะถูกเก็บไว้ใน logfile และอาจทำงานได้อีกครั้งไร้ประโยชน์

น่าจะเป็น -i ธง (ตำแหน่งอินพุต) สามารถช่วยเร่งความเร็วของสิ่งต่าง ๆ ได้เช่นกัน

มันยากมากที่จะเห็นความคืบหน้าของ ddrescueแต่มีคำสั่งอื่นรวมถึงเรียกว่า ddrescuelog.

คำสั่งง่ายๆ ddrescuelog -t YourLog.txt จะส่งออกข่าวสารที่ดีเหล่านี้:

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 กำลังวิ่ง...

อีกวิธีหนึ่งในการติดตามความคืบหน้าของ ddrescue (บน Linux อย่างน้อย) คือการใช้ strace

ก่อนอื่นค้นหา PID สำหรับกระบวนการ ddrescue โดยใช้ "ps aux | grep ddrescue"

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

จากนั้นเรียกใช้ "strace" กับกระบวนการนั้น คุณจะเห็นสิ่งที่ชอบ:

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 Tb นั้นที่คุณพยายามกู้ (ใช่แล้ว Ouch.) ddrescue กำลังคายหมายเลขที่คล้ายกัน - แม้ว่าจะเป็น "1720 GB" - ในเอาต์พุตของหน้าจอ

strace ให้สตรีมข้อมูลที่ละเอียดยิ่งขึ้นจำนวนมากเพื่อให้คุณตรวจสอบ เป็นอีกวิธีหนึ่งในการประเมินความเร็วของวันที่และประเมินวันที่เสร็จสมบูรณ์

การรันอย่างต่อเนื่องอาจเป็นแผนที่ไม่ดีเนื่องจากจะแข่งขันกับ ddrescue สำหรับเวลา CPU ฉันใช้ไปป์ไลน์ที่ "หัว" เพื่อให้ฉันสามารถคว้า 10 ค่าแรก:

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

หวังว่านี่จะช่วยใครซักคน

หากเป้าหมายของคุณคือการได้รับข้อมูลจำนวนมากเหมือนเดิมคุณสามารถเพิ่มความเร็วในการแตกไฟล์ได้ แต่ถ้าคุณต้องการช่วยชีวิตข้อมูลให้มากที่สุดเท่าที่จะเป็นไปได้การปล่อยให้ ddrecue ตอดที่แต่ละคนเป็นเส้นทาง

ฉันพบว่าการเล่นด้วยพารามิเตอร์ -K คุณสามารถเร่งความเร็วได้ จากสิ่งที่ฉันเห็นถ้า ddrescue พบข้อผิดพลาดเมื่อทำงานด้วยอ็อพชัน -n พยายามข้ามเซกเตอร์จำนวนคงที่ ถ้ามันยังอ่านไม่ออกมันจะกระโดดสองเท่าของขนาด หากคุณมีพื้นที่เสียหายขนาดใหญ่คุณสามารถระบุค่า K ขนาดใหญ่ (เช่น 100M) ดังนั้นการกระโดดบนข้อผิดพลาดจะใหญ่ขึ้นในครั้งแรกและจะง่ายขึ้นในการหลีกเลี่ยงพื้นที่ที่มีปัญหาอย่างรวดเร็วในอดีต

โดยวิธีการที่มีโปรแกรมกราฟิกที่ยอดเยี่ยมในการวิเคราะห์บันทึก

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

ระบบไฟล์ของฮาร์ดดิสก์ที่คุณบันทึกอิมเมจการกู้คืนและล็อกไฟล์คืออะไร ฉันเพิ่งสร้างประสบการณ์ที่ช่วยฮาร์ดไดรฟ์ภายในขนาด 500GB (เชื่อมต่อผ่าน SATA) บนแล็ปท็อปที่ใช้ Linux Mint จาก USB Stick บันทึกภาพช่วยเหลือและบันทึกไฟล์ exFat ฟอร์แมตฮาร์ดไดรฟ์ USB เริ่มต้นค่อนข้างช้า (1-2MB / วินาที) แต่หลังจากประมาณ 250GB จะมีการรวบรวมข้อมูลที่ & lt; 100KB / วินาทีเท่านั้น ดูเหมือนว่าไฟล์ภาพกู้ภัยจะใหญ่ขึ้นช้าลง

จากนั้นฉันย้ายอิมเมจการช่วยเหลือและไฟล์บันทึกไปยังที่อื่นชั่วคราวฟอร์แมตฮาร์ดไดรฟ์ USB ใหม่ด้วย ext4 ระบบไฟล์ย้ายไฟล์กลับมาและเริ่มกระบวนการ ddrescue ต่อและตอนนี้มันทำงานด้วย 1-20MB / วินาทีอีกครั้ง (ผันผวน แต่ประมาณ 7MB / วินาทีโดยเฉลี่ย)!

ดูเหมือนว่า exFat เล่นได้ไม่ดีกับไฟล์ที่มีขนาดใหญ่มาก (หลายร้อยกิกะไบต์)

สำหรับตัวเลือกที่รวดเร็วและรวดเร็วในการช่วยเหลือดิสก์คุณสามารถใช้ไฟล์ sh sh แล้วเรียกใช้ไฟล์ด้วย "sh filename.sh" มันมีบรรทัดนี้แสดงให้เห็นเพียงแค่ทำซ้ำ "sudo ddrescue" และ "sleep 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 สำหรับ direct และ -n สำหรับ scrape ที่ไม่เร่งความเร็ว

คุณสามารถใช้ -R หลังจากเสร็จสิ้นด้วยตัวเลือก -A หนึ่งครั้งซึ่งจะย้อนกลับและลบข้อผิดพลาดทั้งหมดและเริ่มต้นใหม่อีกครั้ง หมายความว่ามันจะอ่านข้อผิดพลาดแตกต่างกัน

dd_rhelp เป็นเชลล์สคริปต์ที่ใช้ dd_rescue "[... ] บนแผ่นดิสก์ทั้งหมดของคุณ แต่จะพยายามรวบรวมข้อมูลที่ถูกต้องสูงสุดก่อนที่จะลองใช้กับกลุ่ม badsectors นานหลายปี"

มันค่อนข้างเก่า (2012) แต่ก็ยังใช้งานได้ ยังไม่ได้ลองวัน