วิธีการประมาณลูป / เวลาสำหรับ GNU ddrescue (1.18.1) เสร็จสมบูรณ์โดยใช้สถานะปัจจุบัน


9

พื้นหลัง / บริบท:

ขณะนี้ฉันกำลังใช้ GNU ddrescue 1.18.1 เพื่อกู้คืนข้อมูลจาก USB ที่ประสบปัญหาการถอดสายเคเบิลในขณะที่ฉันกำลังเขียนอิมเมจดิสก์เสมือนลงบนพาร์ติชัน disk2s1 เริ่มแรกฉันจะกู้คืนพาร์ติชั่นที่สองของฉัน (disk2s2) และสังเกตว่าฉันได้มาถึงขั้นตอนที่สาม (การแยก) ฉันวางภาพลงบนที่เก็บข้อมูลเครือข่าย

คำถาม:

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

สถานะ:

สถานะ

การปรับปรุง / แก้ไข:

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

part1 เข้าสู่ระบบ

บันทึกพาร์ติชันเสร็จสมบูรณ์

สำหรับพาร์ติชันที่เพิ่งเสร็จสิ้นนี่คือผลลัพธ์ของการตรวจสอบบันทึก

ภาพที่บันทึก

การอ้างอิง (หมายเหตุขั้นตอนวิธี ddrescue):

4 อัลกอริทึม


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

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

ยูทิลิตี dd มาตรฐานสามารถใช้บันทึกข้อมูลจากไดรฟ์ที่ล้มเหลวได้ แต่จะอ่านข้อมูลตามลำดับซึ่งอาจทำให้ไดรฟ์เสื่อมสภาพโดยไม่ต้องช่วยอะไรเลยหากเกิดข้อผิดพลาดที่จุดเริ่มต้นของไดรฟ์

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

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

1) เลือกอ่านไฟล์บันทึกที่อธิบายสถานะของการช่วยเหลือหลายส่วนหรือถูกขัดจังหวะก่อนหน้านี้ หากไม่มีการระบุล็อกไฟล์หรือว่างเปล่าหรือไม่มีอยู่ให้ทำเครื่องหมายโดเมนกู้ภัยทั้งหมดว่าไม่ได้ลอง

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

3) (ระยะที่สอง; การตัดแต่ง) อ่านส่วนต่อไปทีละหนึ่งส่วนจากขอบนำของบล็อกที่ไม่ได้ถูกเล็มขนาดเล็กจนพบเซกเตอร์ที่ไม่ดี จากนั้นอ่านย้อนกลับทีละส่วนจากขอบต่อท้ายของบล็อกเดียวกันจนกว่าจะพบเซกเตอร์เสีย สำหรับแต่ละบล็อกที่ไม่มีการตัดแต่งให้ทำเครื่องหมายเซกเตอร์ที่ไม่ดีที่พบว่าเป็นเซกเตอร์ที่ไม่ดีและทำเครื่องหมายส่วนที่เหลือของบล็อกนั้นว่าเป็นแบบไม่แบ่งโดยไม่พยายามอ่าน ทำซ้ำจนกว่าจะไม่มีบล็อกที่ไม่มีการตัดแต่งอีกต่อไป (บล็อกที่ไม่มีการขลิบขนาดใหญ่เกิดจากการต่อกันของบล็อกที่เล็กกว่าและเศษส่วนของข้อมูลที่ดีที่ขอบจึงมีขนาดเล็กลง)

4) (เฟสที่สาม; การแยก) อ่านต่อไปหนึ่งเซกเตอร์ต่อครั้งจากศูนย์กลางของบล็อกที่ไม่แบ่งที่ใหญ่ที่สุดจนกว่าจะพบเซกเตอร์ที่ไม่ดี จากนั้นหากเซกเตอร์ที่พบไม่ได้เป็นภาคแรกที่พยายามอ่านย้อนกลับทีละเซกเตอร์จากจุดศูนย์กลางของบล็อกเดียวกันจนกว่าจะพบเซกเตอร์ที่ไม่ดี หาก logfile มีขนาดใหญ่กว่า '--logfile-size' ให้อ่านบล็อกที่ไม่แบ่งที่ใหญ่ที่สุดตามลำดับจนกระทั่งจำนวนรายการใน logfile ลดลงต่ำกว่า '--logfile-size' ทำซ้ำจนกระทั่งบล็อกที่ไม่ได้แยกส่วนที่เหลือทั้งหมดมีน้อยกว่า 7 ส่วน จากนั้นอ่านบล็อกที่ไม่มีการแยกที่เหลือตามลำดับ

5) (ระยะที่สี่; ลองใหม่) หรือลองอ่านเซกเตอร์เสียอีกครั้งจนกว่าจะถึงจำนวนการลองส่งซ้ำที่ระบุ ทุกภาคส่วนที่ไม่ดีจะถูกทดลองเพียงครั้งเดียวในแต่ละรอบ Ddrescue ไม่สามารถทราบได้ว่าเซกเตอร์ที่ไม่ดีนั้นไม่สามารถกู้คืนได้หรือในที่สุดจะอ่านหลังจากลองใหม่

6) เลือกเขียน logfile เพื่อใช้ในภายหลัง

ขนาดข้อผิดพลาดทั้งหมด ('errsize') คือผลรวมของขนาดของบล็อกทั้งหมดที่ไม่ได้ถูกตัด, ไม่แบ่งส่วนและไม่ดี มันจะเพิ่มขึ้นในระหว่างขั้นตอนการคัดลอกและอาจลดลงในระหว่างการตัด, แยกและลองใหม่ โปรดทราบว่าเมื่อ ddrescue แยกบล็อกที่ล้มเหลวทำให้มีขนาดเล็กลงขนาดข้อผิดพลาดทั้งหมดอาจลดลงในขณะที่จำนวนข้อผิดพลาดเพิ่มขึ้น

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

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

ช่วยเหลือส่วนที่สำคัญที่สุดของแผ่นดิสก์ก่อน ddrescue -i0 -s50MiB / dev / hdc ล็อกไฟล์ hdimage ddrescue -i0 -s1MiB -d -r3 / dev / hdc ล็อกไฟล์ hdimage

จากนั้นช่วยเหลือพื้นที่ดิสก์ที่สำคัญบางอย่าง ddrescue -i30GiB -s10GiB / dev / hdc ล็อกไฟล์ hdimage ddrescue -i230GiB -s5GiB / dev / hdc ล็อกไฟล์ hdimage

ตอนนี้ช่วยเหลือส่วนที่เหลือ (ไม่ recopy สิ่งที่ทำไปแล้ว) ddrescue / dev / hdc ล็อกไฟล์ hdimage ddrescue -d -r3 / dev / hdc ล็อกไฟล์ hdimage


ดิสก์ยังคงเชื่อมต่อภายใต้ชื่ออุปกรณ์เดียวกันหรือไม่ นอกจากนี้คุณควรต้องการddrescueเฉพาะเมื่อดิสก์มีบล็อกที่ไม่ดีซึ่งจะไม่เกิดจาก "สายเคเบิลถอด" หากคุณมีปัญหาสายเคเบิลเพียงแค่พยายามที่สายเคเบิลที่แตกต่างกัน ...
frostschutz

@TommieC คุณลองddrescuelog -t YourLog.txtในเทอร์มินัลอื่นได้ไหม
Simply_Me

@Simply_Me โปรดดูคำถามที่อัปเดตซึ่งสะท้อนถึงผลลัพธ์สองรายการ
Tommie C.

@frostschutz โปรดดูคำถามล่าสุดสำหรับรายละเอียดเพิ่มเติม การเชื่อมต่อสายเคเบิลที่หายไปเกิดขึ้นขณะที่ดิสก์กำลังเขียนและทำให้เกิดปัญหากับตารางพาร์ติชัน สายเคเบิลตัวเองไม่เสียหาย
Tommie C.

การถอดสายเคเบิลมักจะทำให้เกิดข้อผิดพลาดเชิงตรรกะ (เช่นข้อมูลในดิสก์ไม่ถูกต้อง 100%) แต่จะไม่ทำให้เกิดปัญหาทางกายภาพกับไดรฟ์ - เว้นแต่คุณจะทำมันตกในเวลาเดียวกัน ddrescueสามารถลองกู้คืนปัญหาทางกายภาพและจะไม่ช่วยให้มีข้อผิดพลาดเชิงตรรกะเลย สำหรับอันหลังลองfsckหรือเหมือนกัน ..
Udo G

คำตอบ:


6

แม้ว่าคำถามจะถูกถามเมื่อ 10 เดือนที่แล้วคำตอบอาจจะเกี่ยวข้องเนื่องจากรอบการกู้คืนอาจยังคงทำงานอยู่โดยขึ้นอยู่กับปัจจัยบางประการ! เล่นสำนวนไม่มีเจตนา

เหตุผลก็คือการประมาณเวลาแทบจะเป็นไปไม่ได้อย่างไรก็ตามบางครั้งคุณอาจได้แนวคิดคร่าวๆดังนี้ หนึ่งในเหตุผลที่ชัดเจนที่สุดคือคุณไม่สามารถคาดการณ์ได้ว่าจะใช้เวลานานเท่าใดในการอ่านเซกเตอร์เสียและถ้าคุณต้องการให้ ddrescue อ่านและลองใหม่ทุก ๆ ครั้งมันอาจใช้เวลานานมาก ตัวอย่างเช่นขณะนี้ฉันกำลังกู้คืนบนไดรฟ์ขนาดเล็ก 500GB ที่เกิดขึ้นนานกว่า 2 สัปดาห์และอาจเหลืออีกสองสามวัน แต่ฉันเป็นสถานการณ์ที่ซับซ้อนมากขึ้นเพราะไดรฟ์นั้นได้รับการเข้ารหัสและเพื่ออ่านสิ่งใดสำเร็จฉันได้ตรวจสอบให้แน่ใจว่าได้รับเซ็กเมนต์ทั้งหมดที่มีตารางพาร์ติชันบูตเซกเตอร์และส่วนสำคัญอื่น ๆ ของดิสก์ ฉันใช้เทคนิคนอกเหนือจาก ddrescue เพื่อปรับปรุงโอกาสของฉันสำหรับภาคที่ไม่ดีทั้งหมด IOW,

โดยประมาณว่า "ลูป" ถ้าคุณหมายถึงจำนวนการลองใหม่นั่นเป็นสิ่งที่คุณกำหนดโดยพารามิเตอร์ที่คุณใช้ หากคุณหมายถึง "จำนวนการส่งผ่านทั้งหมด" นั่นจะถูกกำหนดโดยการอ่านเกี่ยวกับอัลกอริทึมที่นี่ .. > man ddrescue </ อัลกอริทึม: วิธีที่ ddrescue กู้คืนข้อมูล

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

ในตัวอย่างที่คุณให้ดูที่หน้าจอสถานะการทำงานของ ddrescue เราได้รับ "ประมาณการ" ทั้งหมดของปัญหา (โดเมนกู้ภัย) โดย "errsize" นี่คือปริมาณข้อมูลที่ "ยังไม่ได้อ่าน" ในตัวอย่างมันเป็น 345GB บรรทัดถัดไปด้านล่างทางขวาคือ "อัตราเฉลี่ย" ในตัวอย่างมันคือ 583kb / s

หาก "อัตราเฉลี่ย" ยังคงใกล้เคียงกับที่มั่นคงหมายความว่าคุณมีเวลาอีก 7 วัน 345 GB / (583 kb * 60 * 60 * 24) = 7.18 อย่างไรก็ตามปัญหาคือคุณไม่สามารถพึ่งพา 583kb / s ได้ ในความเป็นจริงแล้วคุณจะต้องกู้คืนมากขึ้นไดรฟ์จะช้าลงเนื่องจากอ่านพื้นที่ที่ยากขึ้นและพยายามทำซ้ำมากขึ้น ดังนั้นเวลาที่จะเสร็จสิ้นชี้แจงเพิ่มขึ้น ทั้งหมดนี้ขึ้นอยู่กับความเสียหายของไดรฟ์

ตัวอย่างที่คุณให้ไว้แสดงว่า "การอ่านที่สำเร็จ" มากกว่า 10 ชั่วโมงที่ผ่านมา กำลังบอกว่าไม่ได้รับอะไรจากการขับรถเป็นเวลา 10+ ชั่วโมง นี่แสดงให้เห็นว่าไดรฟ์ของคุณอาจมีข้อมูลที่ถ่ายได้ 345GB (หรือบางส่วน) นี่เป็นข่าวร้ายสำหรับคุณ

ในทางตรงกันข้ามไดรฟ์ 500GB ตัวที่สองที่เพิ่งเริ่มให้ข้อผิดพลาด "สมาร์ท" ของฉันถูกคัดลอกดิสก์ไปยังดิสก์ (ด้วยล็อกไฟล์บนไดรฟ์อื่น) และการดำเนินการทั้งหมดใช้เวลาประมาณ 8-9 ชั่วโมง ส่วนสุดท้ายของมันช้าลง แต่ก็ยังสามารถรับได้ ในขณะที่ไดรฟ์ที่แย่มากดังที่กล่าวไว้ข้างต้นนั้นดีใน 2 สัปดาห์ที่ผ่านมาทำงานบน 500GB และยังมีเหลืออีกประมาณ 4-5% ในการกู้คืน

HTH และ YMMV

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