Là lệnh ddresTHER này làm bất cứ điều gì?


9

Trong quá trình cố gắng khôi phục dữ liệu từ một ổ cứng bị lỗi , tôi đang chạy lệnh ddrescue.

Lệnh đã chạy được 9 ngày và tôi nghĩ từ âm thanh của hoạt động đĩa có lẽ nó đang làm gì đó. Đầu ra dòng lệnh đã nhìn ít nhiều tĩnh mọi lúc:

$ 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... 

Một phần đã được thay đổi là nơi nó nói iposopos. Phải mất 9 ngày để có được xung quanh 500000 MB, đó là kích thước của ổ đĩa bị lỗi. Tuy nhiên, khi nó đến đó, nó lại rơi xuống 0và bắt đầu tăng trở lại. Khi tôi viết điều này, đó là về 2580 MBvà đếm.

Tệp hình ảnh được tạo có độ dài 0 byte.

Tệp nhật ký có kích thước khoảng 3 MB và trông như thế này:

# 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  -

Tôi bắt đầu lo ngại rằng đây chỉ là một sự lãng phí thời gian và không có dữ liệu nào được phục hồi cả.

Có bất kỳ dấu hiệu nào từ đầu ra này rằng bất cứ điều gì hữu ích đang xảy ra?

Có bất kỳ lý do để để cho ddrescuelệnh tiếp tục như vậy, hoặc tôi nên dừng nó và làm một cái gì đó khác?


Đây là nội dung gần đây nhất của /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

Câu trả lời:


8

Tôi không biết nếu bạn vẫn đang cố trích xuất dữ liệu khỏi ổ cứng đó hay bạn đã thành công chưa, nhưng trong trường hợp nếu bạn không thành công và muốn thử xem bạn có thể khôi phục được không, có lẽ, đã mất Bitcoin hoặc bất cứ điều gì, tôi đã thực hiện một vài sửa đổi cho các ddrescuetham số dòng lệnh của bạn , tôi đã thêm vào như sau:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R
  • -d cho biết ddresTHER sử dụng truy cập đĩa trực tiếp,
  • - Force yêu cầu ddresTHER sử dụng mạnh mẽ và đọc / ghi vào logfile của bạn trong trường hợp nếu nó phàn nàn rằng nó không thể sử dụng nó cho mục đích đọc / ghi
  • -R (có, với VỐN R) yêu ddrescuecầu thực hiện các thao tác khôi phục theo chiều ngược lại thay vì đọc ổ cứng bị lỗi ở chế độ chuyển tiếp. Đôi khi đọc ngược lại giúp ích khi thiệt hại là đáng kể vì điều này bỏ qua bộ nhớ cache của ổ cứng trong trường hợp có vấn đề ở đó.

Hiện tại tôi đang sử dụng các lệnh này (ngoại trừ tôi không sử dụng 3lệnh vì tôi không muốn [YET] ddrescuethử lại các thành phần xấu, tôi sẽ để nó cuối cùng, sau khi quá trình quét đầu tiên của tôi được thực hiện và tôi đã giải cứu thành công dữ liệu tắt ổ cứng Seagate 1TB của tôi không thành công trong đó tôi ASSUME có thể đang giữ một vài bitcoin mà tôi có thể đã khai thác từ năm 2009 đến 2010, có lẽ tôi đã tìm thấy 1 đến 3 khối 50 BTC mỗi cái, tôi hy vọng nó có trên ổ cứng này, tốt, tôi sẽ mất tổng cộng hơn 15 ngày để hoàn thành thao tác với tốc độ đọc trung bình 634 kbps.

Ngoài ra, tôi muốn nói thêm rằng bạn có thể và rất có thể, dựa trên hồ sơ theo dõi trước đó của bạn trên 9 NGÀY của "hoạt động đọc lần cuối" mà bạn sẽ gặp phải tình huống ổ cứng sẽ từ chối đọc thêm, trong đó trong trường hợp này, chỉ cần nhấn CTRL + C để hủy vì bạn đang sử dụng tệp nhật ký, rút ​​cáp SATA ra khỏi ổ cứng bị lỗi, nhưng không phải bộ điều khiển USB tắt cổng USB (vâng, sử dụng bộ điều khiển USB SATA thay vì kết nối với một bo mạch chủ để nó không khóa toàn bộ máy tính của bạn buộc bạn phải khởi động lại cứng, sau đó cắm lại nguồn điện SATA để khởi động lại ổ cứng, cho nó trong 10 giây và sau đó nhấn mũi tên lên hoặc xuống để tải lại thiết bị đầu cuối trước đó của bạn ra lệnh và khởi động lạiddrescuehoạt động, nhờ vào nhật ký trước của bạn, nó sẽ tiếp tục ở nơi cuối cùng còn lại và sẽ có việc đọc được thực hiện và "lần đọc thành công cuối cùng" sẽ luôn ở mức "0s" (0 giây), cho thấy nó ddrescueđang thành công đọc từ ổ đĩa cứng và nếu bạn nhận thấy rằng "lần đọc cuối cùng" bắt đầu đếm giây, chỉ cần chấm dứt một lần nữa ddrescuevới CTRL+ C, cấp nguồn cho ổ cứng và khởi động lạiddrescue, không có lý do gì để chờ đợi nếu "lần đọc cuối cùng" tự khởi động trở về 0, dựa trên kinh nghiệm của tôi, điều đó sẽ không bao giờ xảy ra, bạn sẽ chờ đợi mãi mãi. Tôi đã phải cấp nguồn cho ổ cứng 1 TB tồi tệ của mình tổng cộng khoảng 20 lần, nó đã được 7 ngày và tôi đã gần đạt được mốc 500GB, một nửa để đi, hy vọng tôi sẽ không gặp phải bất kỳ thất bại lớn nào như Tôi gần 100% vì nó đã diễn ra hoàn hảo trong 3 ngày qua, một lần nữa với tốc độ hơn 634 kbps.

Ngoài ra, đừng tham lam khi cố gắng có được tốc độ đọc thông lượng dữ liệu nhanh hơn, vì nỗ lực của tôi trong việc thử nhiều tham số và kích thước khối khác nhau gần như khiến tôi bị rive hoàn toàn chết người sẽ ngừng hoạt động trong hơn 1 giây sau khi đạp điện (đó là 5 ngày trước) nhưng may mắn thay, nó chỉ bắt đầu một lần nữa cho thấy dấu hiệu của sự sống, ban đầu đọc ở mức 2.000 bs (có BYTES mỗi giây) ít hơn 2kb / giây, tôi đã rất thất vọng, nhưng sau khi hủyddrescuevới CTRL + C và chỉ cần khởi động lại một lần nữa (ngược lại với tham số -R), sau đó tốc độ quay trở lại 630, trước khi tôi đọc về phía trước với tốc độ 930 kbps, ít nhất là tôi đang làm ngược lại 630 kbps và không phải tắt với 2kb / giây, vì vậy nếu bạn đạt được thành công ở bất kỳ tốc độ đọc nào, như trong phạm vi 500 kbps với nó và đừng thử bất cứ điều gì để tăng tốc độ cao hơn nữa, đó có thể là nỗ lực thành công cuối cùng của bạn để đạt được bất kỳ tốc độ đọc.

Ngoài ra, nếu ddrescueđiều đó không tốt cho bạn vì bạn không thể đọc bất cứ thứ gì bất kể bạn thử tham số nào, bạn có thể muốn xem xét thay thế bảng logic khỏi ổ cứng, vì 90% đó là bảng logic đi xấu, nhưng trước tiên, hãy tháo bo mạch logic và làm sạch tất cả các tiếp điểm tạo các tiếp điểm bằng các chân của ổ cứng, đôi khi các liên hệ này có một hỗn hợp màu đen trong đó, cắt đứt liên lạc có thể là nguồn gốc của sự thất bại của bạn. Nhưng lưu ý rằng nếu bạn phải thay thế bảng logic của ổ cứng, bạn sẽ phải lấy một trong cùng một nhãn hiệu, số sê-ri (gần với), số kiểu, số sửa đổi vì nó phải gần giống với bản gốc cho hội đồng tài trợ để làm việc.


2
Bạn có thể muốn chỉnh sửa bức tường văn bản đó một chút.
slm

4
Trên thực tế tôi nghĩ rằng đó là một trong những bài viết chi tiết và mang tính xây dựng nhất mà tôi đã thấy về chủ đề này. Tôi hy vọng bạn không phiền, tôi vừa thêm một câu hỏi tương tự unix.stackexchange.com/q/219365/125662 đề cập đến đóng góp thực sự hữu ích của bạn
baroquedub

1
Từ hướng dẫn sử dụng GNU ddresTHER: "- Force Force ghi đè lên outfile. Cần thiết khi outfile không phải là một tệp thông thường, mà là một thiết bị hoặc phân vùng. Tùy chọn này chỉ là một biện pháp bảo vệ để ngăn chặn sự phá hủy vô tình của các phân vùng và bị bỏ qua cho các tệp thông thường . " Đây không phải là về mapfile / logfile.
Arch Linux tu

Vui lòng sửa mô tả --forcetùy chọn, nó không chính xác
endolith

5

Bạn sẽ có thể dừng lại ddrescuevì nó sử dụng tệp nhật ký để có thể khởi động lại hoạt động của nó (đóng) về nơi nó rời đi. Tuy nhiên, tôi sẽ kiểm tra xem logfile có được cập nhật gần đây hay không bằng cách xem dấu thời gian hoặc thực hiện tail -f /home/dave/recovery_usb500.logfile.

Rằng tập tin hình ảnh của bạn vẫn còn nhỏ đến mức không có khối nào được lấy thành công từ ổ đĩa. Tuy nhiên, đó sẽ là kết quả tồi tệ sau tất cả thời gian này. Giả sử chỉ có một vài khối xấu trên thiết bị và chúng không ở đầu, trạng thái mục nhập đầu tiên của bạn sẽ là +. IIRC ddrescuebắt đầu đọc cho đến khi tìm thấy lỗi và sau đó bắt đầu chia phần còn lại của đĩa. Đĩa của bạn dường như thất bại ngay từ đầu.

Trừ khi có (nhiều) +mục trong nhật ký kích thước tệp của bạn vẫn là 0tôi không nghĩ ddrescuelà sai. Không +có nghĩa là không có gì từ ổ đĩa của bạn có thể phục hồi. Điều đó có thể có nghĩa là đồ điện tử chiên hoặc đầu xấu, vì trong trường hợp chỉ một vài lĩnh vực bị lỗi, bạn sẽ có kết quả nhanh hơn nhiều.

Đối với việc làm một cái gì đó khác. Tôi giả sử bạn đã thử đọc một vài khối với dd bình thường. Bạn đã xem syslog dựa trên đó và googled bất kỳ tin nhắn bạn tìm thấy ở đó?


Tìm kiếm "Kết quả: hostbyte = driverbyte không hợp lệ = DRIVER_SENSE" dẫn đến một vài lần đọc thú vị (một phần tiếng Đức) với một vài gợi ý khác:

  • Hãy thử kết nối qua USB 1.1 thay vì 2.0
  • Ổ đĩa có thể bị nóng, do đó bọc nó bằng nhựa và đặt trong tủ lạnh trong 10 phút, điều này mang lại một số thời gian dễ đọc trước khi ổ đĩa nóng lên trở lại.
  • chuyển đổi SMART trong BIOS (và kết nối với SATA).
  • Đảm bảo ổ USB có đủ năng lượng (cung cấp thêm năng lượng)
  • Nếu đọc qua USB không thành công sau một thời gian, hãy sử dụng USB Hub được điều khiển từ xa, nơi bạn lập trình chuyển nguồn điện từ USB HUB sang ổ đĩa trong vài giây.

Ngoài việc làm mát một đĩa không thể đọc được (với bình xịt làm mát) tôi chưa từng thử bất kỳ thứ nào trong số này.


Cảm ơn vì đã phản hồi. Tôi chưa thử "bình thường" dd, vì tôi không biết đó là gì. Cảm giác ruột của tôi là hầu hết các ổ đĩa và dữ liệu vẫn còn nguyên vẹn, nhưng có một số lỗi trong một số khu vực quan trọng của đĩa nơi diễn ra các tệp lập chỉ mục hoặc liệt kê.
hỏi

Bạn có thể xem xét ddrescuelà một dẫn xuất ddkhông dừng lại khi gặp lỗi. Bạn đã kiểm tra các +dấu hiệu?
Anthon

Trong tệp nhật ký, không có +dấu hiệu. Chỉ có -\ dấu hiệu.
hỏi

Điều đó có nghĩa là chưa có gì được phục hồi và tôi nghĩ không có khả năng nó ddrescuesẽ bắt đầu sau tất cả thời gian này. Nếu bạn muốn chúng tôi có thể trò chuyện (liên kết trên cùng của trang này) về điều này
Anthon

Tôi đã thêm nội dung của /var/log/syslogcâu hỏi.
hỏi
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.