คำสั่ง ddrescue นี้ทำอะไรหรือไม่?


9

ในหลักสูตรของการพยายามที่จะกู้คืนข้อมูลจากฮาร์ดไดรฟ์ความล้มเหลวที่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

คำตอบ:


8

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

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R
  • -d ซึ่งบอกให้ ddrescue ใช้การเข้าถึงดิสก์โดยตรง
  • - บังคับให้ ddrescue บังคับให้ใช้และอ่าน / เขียนล็อกไฟล์ของคุณอย่างแข็งขันในกรณีที่มันบ่นว่ามันไม่สามารถใช้เพื่อการอ่าน / เขียนได้
  • -R (ใช่ด้วย CAPITAL R) ซึ่งบอกddrescueให้ทำการกู้คืนแบบย้อนกลับแทนที่จะอ่านฮาร์ดไดรฟ์ที่ล้มเหลวในโหมดไปข้างหน้า บางครั้งการอ่านแบบย้อนกลับช่วยในกรณีที่เกิดความเสียหายอย่างมากเนื่องจากการทำเช่นนี้ผ่านแคชของฮาร์ดไดรฟ์ในกรณีที่มีปัญหาเกิดขึ้น

ขณะนี้ฉันกำลังใช้คำสั่งเหล่านี้ (ยกเว้นฉันไม่ได้ใช้3คำสั่งเนื่องจากฉันไม่ต้องการให้ [YET] ddrescueลองเซ็กเตอร์ที่ไม่ดีฉันจะปล่อยให้มันผ่านไปหลังจากการกวาดครั้งแรกของฉันเสร็จสิ้นและฉันก็ประสบความสำเร็จในการช่วยชีวิต ข้อมูลจาก 1TB Seagate ของฉันล้มเหลวฮาร์ดไดรฟ์ที่ฉัน ASSUME อาจถือ bitcoins ไม่กี่ที่ฉันอาจขุดมาตั้งแต่ปี 2009 ถึง 2010 ฉันอาจพบว่า 1 ถึง 3 บล็อก 50 BTC แต่ละฉันหวังว่ามันจะอยู่ในฮาร์ดไดรฟ์นี้ดี ฉันจะใช้เวลาทั้งหมดมากกว่า 15 วันในการดำเนินการให้เสร็จสมบูรณ์ด้วยอัตราการอ่าน 634 kbps เฉลี่ย

นอกจากนี้ฉันอยากจะเพิ่มว่าคุณอาจและน่าจะเป็นไปตามบันทึกการติดตามก่อนหน้าของ "กิจกรรมการอ่านครั้งล่าสุด" มากกว่า 9 วันที่คุณจะได้พบกับสถานการณ์ที่ฮาร์ดไดรฟ์จะปฏิเสธที่จะอ่านเพิ่มเติมใด ๆ สถานการณ์เพียงกด CTRL + C เพื่อยกเลิกเนื่องจากคุณใช้ล็อกไฟล์ถอดสาย SATA ออกจากฮาร์ดไดรฟ์ที่ล้มเหลว แต่ไม่ใช่คอนโทรลเลอร์ USB ปิดพอร์ต USB (ใช่ใช้คอนโทรลเลอร์ USB SATA แทนการเชื่อมต่อกับ เมนบอร์ดจะไม่ล็อคคอมพิวเตอร์ทั้งหมดของคุณบังคับให้คุณรีบูตฮาร์ดไดรฟ์จากนั้นเสียบปลั๊กไฟ SATA อีกครั้งเพื่อรีสตาร์ทฮาร์ดไดรฟ์ให้มันเหมือน 10 วินาทีจากนั้นกดลูกศรขึ้นหรือลงเพื่อโหลดเทอร์มินัลก่อนหน้า คำสั่งและรีสตาร์ทddrescueการดำเนินงานขอบคุณบันทึกก่อนหน้าของคุณจะยังคงที่เหลือสุดท้ายออกและจะมีการอ่านถูกทำและ "ที่ผ่านมาประสบความสำเร็จในการอ่าน" มักจะอยู่ที่ "0s" (ศูนย์วินาที) ที่มันควรจะแสดงให้เห็นว่าddrescueเป็นอยู่ในที่ประสบความสำเร็จ การอ่านจากฮาร์ดไดรฟ์และหากคุณสังเกตเห็นว่า "การอ่านครั้งล่าสุดจาก" เริ่มนับวินาทีให้ยกเลิกเพียงแค่อีกครั้งddrescueด้วยCTRL+ Cเปิดวงจรฮาร์ดไดรฟ์แล้วเริ่มต้นใหม่ddrescueไม่มีประเด็นที่จะรอดูว่า "การอ่านล่าสุดจาก" รีสตาร์ทกลับเป็น 0s ด้วยตัวเองหรือไม่ขึ้นอยู่กับประสบการณ์ของฉันมันจะไม่เกิดขึ้นคุณจะต้องรอคอยชั่วนิรันดร์ ฉันต้องใช้พลังงานกับฮาร์ดไดรฟ์ขนาด 1 TB ของฉันทั้งหมดประมาณ 20 ครั้งมันเหมือน 7 วันแล้วและฉันก็ใกล้จะถึงเครื่องหมายกู้ 500GB ครึ่งทางที่จะไปยังทางฉันหวังว่าฉันจะไม่พบความล้มเหลวที่สำคัญเช่น ฉันใกล้ 100% เพราะมันไร้ที่ติในช่วง 3 วันที่ผ่านมาอีกครั้งที่ความเร็วมากกว่า 634 kbps

นอกจากนี้อย่าโลภในการพยายามรับอัตราการอ่านปริมาณข้อมูลที่เร็วขึ้นเนื่องจากความพยายามของฉันในการลองใช้พารามิเตอร์จำนวนมากและขนาดบล็อกที่แตกต่างกันทำให้ฉันเกือบจะตายด้วยการตายอย่างหนักซึ่งจะหยุดทำงานในเวลา 1 วินาที (นั่นคือ 5 วันที่ผ่านมา) แต่โชคดีที่มันเพิ่งเริ่มแสดงสัญญาณของชีวิตอีกครั้งเริ่มอ่านที่ 2,000 bs (ใช่ BYTES ต่อวินาที) น้อยกว่า 2kbps เล็กน้อยฉันผิดหวังมาก แต่หลังจากยกเลิกddrescueด้วย CTRL + C และเพิ่งรีสตาร์ทอีกครั้ง (ย้อนกลับโดยเพิ่มพารามิเตอร์ -R) แล้วความเร็วก็กลับไปที่ 630 ก่อนที่ฉันจะอ่านไปข้างหน้าที่ 930 kbps อย่างน้อยฉันก็พอใจที่ฉันทำ 630 kbps ในสิ่งที่ตรงกันข้าม และไม่ต้องชะลอด้วย 2kbps ดังนั้นหากคุณประสบความสำเร็จในทุก ๆ ความเร็วในการอ่านเช่นในช่วง 500 kbps และไม่พยายามผลักดันความเร็วใด ๆ ให้สูงขึ้นอาจเป็นความพยายามครั้งสุดท้ายของคุณในการดึงดูด ความเร็วในการอ่านใด ๆ

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


2
คุณอาจต้องการแก้ไขผนังข้อความนั้นสักหน่อย
slm

4
จริงๆแล้วฉันคิดว่านั่นเป็นหนึ่งในโพสต์ที่สร้างสรรค์และละเอียดที่สุดเท่าที่ฉันเคยเห็นในหัวข้อ ฉันหวังว่าคุณจะไม่รังเกียจฉันเพิ่งเพิ่มคำถามที่คล้ายกันunix.stackexchange.com/q/219365/125662ที่กล่าวถึงการช่วยเหลือที่เป็นประโยชน์ของคุณจริงๆ
baroquedub

1
จากคู่มือ GNU ddrescue: "- บังคับให้เขียนทับไฟล์ outfile จำเป็นเมื่อไฟล์ outfile ไม่ใช่ไฟล์ปกติ แต่เป็นอุปกรณ์หรือพาร์ติชันตัวเลือกนี้เป็นเพียงการป้องกันเพื่อป้องกันการทำลายพาร์ทิชันโดยไม่ตั้งใจและไม่สนใจไฟล์ปกติ ." นี่ไม่ได้เกี่ยวกับ mapfile / logfile
Arch Linux Tux

โปรดแก้ไขคำอธิบายของ--forceตัวเลือกมันไม่ถูกต้อง
endolith

5

คุณควรจะสามารถหยุดได้ddrescueเนื่องจากมันใช้ไฟล์บันทึกเพื่อให้สามารถเริ่มการทำงานใหม่ (ปิด) ไปยังตำแหน่งที่เหลือ ฉันจะตรวจสอบ แต่ถ้า logfile ได้รับการปรับปรุงเมื่อเร็ว ๆ tail -f /home/dave/recovery_usb500.logfileนี้โดยดูที่ประทับเวลาหรือทำ

ไฟล์ภาพของคุณยังมีขนาดเล็กซึ่งอาจต้องทำโดยไม่มีการดึงบล็อกจากไดรฟ์สำเร็จ อย่างไรก็ตามนั่นจะเป็นผลลัพธ์ที่ไม่ดีหลังจากที่ทุกครั้งที่ทำงาน +สมมติว่ามีเพียงไม่กี่บล็อกเสียบนอุปกรณ์และว่าพวกเขาจะไม่ได้อยู่ที่จุดเริ่มต้นที่สถานะรายการแรกของคุณจะ IIRC ddrescueเริ่มอ่านจนกระทั่งพบข้อผิดพลาดจากนั้นเริ่มแยกส่วนที่เหลือของแผ่นดิสก์ แผ่นดิสก์ของคุณดูเหมือนจะล้มเหลวตั้งแต่เริ่มต้น

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

สำหรับการทำอย่างอื่น ฉันถือว่าคุณลองอ่านบล็อกสองสามตัวด้วย dd ปกติแล้ว คุณดู syslog ตามนั้นและ googled ข้อความใด ๆ ที่คุณพบว่ามี?


การค้นหา "ผลลัพธ์: hostbyte = driverbyte ไม่ถูกต้อง = DRIVER_SENSE" ผลลัพธ์ในการอ่านที่น่าสนใจ (ภาษาเยอรมันบางส่วน) พร้อมคำแนะนำเพิ่มเติม:

  • ลองเชื่อมต่อผ่าน USB 1.1 แทน 2.0
  • ไดรฟ์อาจร้อนจัดดังนั้นจึงนำไปห่อด้วยพลาสติกแล้วนำไปใส่ในตู้เย็นเป็นเวลา 10 นาทีซึ่งจะทำให้เวลาในการอ่านก่อนที่ไดรฟ์จะร้อนอีกครั้ง
  • สลับของ SMART ใน BIOS (และเชื่อมต่อกับ SATA)
  • ตรวจสอบให้แน่ใจว่าไดรฟ์ USB มีพลังงานเพียงพอ (แหล่งจ่ายไฟเพิ่มเติม)
  • หากการอ่านผ่าน USB ล้มเหลวในบางครั้งให้ใช้ USB Hub ที่ควบคุมจากระยะไกลโดยที่คุณสามารถสลับการใช้พลังงานจาก USB HUB ไปยังไดรฟ์เป็นเวลาสองสามวินาที

นอกเหนือจากการทำความเย็นดิสก์ที่อ่านไม่ได้ (ด้วยสเปรย์ระบายความร้อน) ฉันยังไม่ได้ลองสิ่งเหล่านี้เลย


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

คุณสามารถพิจารณาddrescueเป็นอนุพันธ์ของddที่ไม่หยุดเมื่อพบข้อผิดพลาด คุณตรวจสอบ+สัญญาณแล้วหรือยัง?
Anthon

ในล็อกไฟล์ไม่มี+สัญญาณ มีเพียงสัญญาณ-และ \
ถามคำถาม

นั่นหมายความว่ายังไม่มีการกู้คืนข้อมูลใด ๆ และฉันคิดว่ามันไม่น่าddrescueจะเกิดขึ้นหลังจากนี้ตลอดเวลา ถ้าคุณต้องการเราสามารถแชท (ลิงค์ด้านบนของหน้านี้) เกี่ยวกับเรื่องนี้
Anthon

ฉันได้เพิ่มเนื้อหาของ/var/log/syslogคำถาม
ถามคำถาม
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.