이 ddrescue 명령이 무엇을하고 있습니까?

고장난 하드 드라이브에서 데이터 를 복구 하는 과정 에서 명령을 실행하고 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. 500000 MB장애가 발생한 디스크 드라이브의 크기 인 약 9 일이 걸렸습니다 . 그러나 그곳에 도착했을 때 다시 내려 와서 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

그래도 하드 드라이브에서 데이터를 추출하려고 시도했는지 또는 이미 성공했는지는 모르겠지만 성공하지 못한 경우 복구 할 수 있는지 확인하려는 경우 비트 코인이나 무엇이든 ddrescue명령 줄 매개 변수 를 약간 수정 했으며 다음을 추가했습니다.

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -ddrescue가 직접 디스크 액세스를 사용하도록 지시합니다.
• --force는 ddrescue가 로그 파일을 읽기 / 쓰기 목적으로 사용할 수없는 경우 로그 파일을 강제로 사용하고 읽거나 쓰도록 지시합니다.
• ddrescue정방향 모드에서 오류가 발생한 하드 드라이브를 읽는 대신 복구 작업을 반대로 수행하도록 지시 하는 -R (예, CAPITAL R 사용) . 문제가있는 경우 하드 드라이브의 캐시를 우회하므로 손상이 큰 경우에는 반대로 반대로 읽는 것이 도움이됩니다.

현재이 3명령을 사용 하고 있습니다 ([YET]이 ( ddrescue가) 불량 섹터를 다시 시도 하는 것을 원하지 않기 때문에 명령을 사용하지 않는 것을 제외하고 , 첫 번째 스윕이 완료된 후 마지막으로 그대로 두겠습니다. 내 1TB Seagate의 데이터가 고장 나서 2009 년부터 2010 년까지 마이닝 한 비트 코인 몇 개를 보유한 ASSUME 하드 드라이브에 장애가 발생했습니다. 아마도 각각 50 BTC의 1 ~ 3 블록을 찾았을 것입니다. 평균 634kbps의 읽기 속도로 작업을 완료하는 데 총 15 일이 걸립니다.

또한, 귀하는 하드 드라이브가 더 이상 읽기를 거부하는 상황에 직면하게 될 "마지막 읽기 활동"에 대한 9 일 이상의 이전 기록을 기반으로 할 가능성이 가장 높습니다. 상황이 발생하면 CTRL + C를 눌러 로그 파일을 사용하고 있기 때문에 취소하고 실패한 하드 드라이브에서 SATA 케이블을 제거하지만 USB 포트에서 USB 컨트롤러는 제거하지 마십시오 (예, USB SATA 컨트롤러를 연결하는 대신 USB SATA 컨트롤러 사용) 전체 컴퓨터를 잠그지 않아 하드 재부팅을하지 않은 다음 SATA 전원을 다시 연결하여 하드 드라이브를 다시 시작하고 10 초 정도 지난 다음 위 또는 아래 화살표를 눌러 이전 터미널을 다시로드하십시오. 명령을 다시 시작ddrescue이전 로그 덕분에 작업이 마지막으로 중단 된 곳에서 계속되고 읽기가 수행되고 "마지막으로 성공한 읽기"는 항상 "0s"(제로 초)에 머물러 있어야합니다 ddrescue. 하드 드라이브에서 읽기, 혹시 통지 초 카운트 시작은 "에서 마지막으로 읽은는"한 번만 다시 종료하는 것이 경우 ddrescue에 CTRL+ C, 전원을 껐다 하드 드라이브, 다시 시작ddrescue, "마지막 읽기"가 스스로 다시 0으로 다시 시작되는지 여부를 기다리지 않아도됩니다. 내 경험에 따르면 결코 일어나지 않을 것입니다. 영원을 기다릴 것입니다. 나는 나쁜 1TB 하드 드라이브를 총 약 20 배의 전원을 껐다 켜야했습니다 .7 일이 지났고 500GB 복구 된 마크에 거의 도달했습니다. 반쯤 갈 것입니다. 큰 오류가 발생하지 않기를 바랍니다. 지난 3 일 동안 634 kbps 이상으로 완벽하게 진행되어 왔으므로 100 % 가까이에 있습니다.

또한 많은 매개 변수와 다른 블록 크기를 시도하려는 시도로 인해 전원을 껐다 켠 후 1 초 이상 작동이 중단되는 완전히 죽은 하드 리브가 거의 생겼기 때문에 더 빠른 데이터 처리량 읽기 속도를 얻으려고 애 쓰지 마십시오. (5 일 전) 그러나 고맙게도 다시 한번 삶의 징조를 나타 내기 시작했으며 처음에는 2kbps보다 약간 작은 2,000 bs (초당 BYTES)로 읽었습니다. 매우 실망했지만 취소 후ddrescueCTRL + C를 사용하고 다시 한 번 다시 시작하면 (-R과 반대로) 매개 변수가 추가 된 다음 속도가 630으로 돌아갔습니다. 2kbps를 사용하지 않아도되므로 500kbps 범위 스틱과 같이 읽기 속도에서 성공하고 더 높은 속도를 누르려고 시도하지 않으면 마지막으로 성공한 시도 일 수 있습니다. 모든 읽기 속도.

또는 ddrescue어떤 매개 변수를 시도 하더라도 읽을 수 없기 때문에 좋지 않은 경우 논리 드라이브를 로직 보드로 사용하는 시간의 90 %로 하드 드라이브에서 논리 보드를 교체하는 것이 좋습니다 나쁘지만 먼저 논리 보드를 벗기고 하드 드라이브의 핀과 접촉하는 모든 접점을 청소하십시오. 때로는 이러한 접점에 검은 끈적 끈적한 끈적 끈적한 혼합물이 생겨서 고장의 원인이 될 수있는 접점을 끊습니다. 그러나 하드 드라이브의 로직 보드를 교체해야하는 경우 동일한 브랜드, 일련 번호 (가까운), 모델 번호, 개정 번호 중 하나를 원본과 비슷해야하므로주의해야합니다. 기증자 보드가 작동합니다.

ddrescue로그 파일을 사용하여 작업을 다시 시작 (닫기) 할 수 있도록 중지 할 수 있어야합니다 . 그러나 타임 스탬프를 보거나 수행하여 로그 파일이 최근에 업데이트되었는지 확인 tail -f /home/dave/recovery_usb500.logfile합니다.

이미지 파일이 여전히 작다는 것은 드라이브에서 아직 성공적으로 검색된 블록이없는 것과 관련이있을 수 있습니다. 그러나이 모든 시간을 실행 한 후에는 나쁜 결과가 될 것입니다. 장치에 불량 블록이 몇 개 있고 처음에 있지 않다고 가정하면 첫 번째 입력 상태는입니다 +. IIRC ddrescue는 오류가 발견 될 때까지 읽기를 시작한 다음 나머지 디스크를 분할하기 시작합니다. 디스크가 처음부터 제대로 작동하지 않는 것 같습니다.

+로그에 (여러) 항목 이 없으면 과 파일 크기 여전히 것 0내가 생각하지 않는 ddrescue잘못된 것입니다. 아니오 +는 드라이브에서 복구 할 수있는 것이 없음을 의미합니다. 일부 전자 부품에 결함이있는 경우 결과가 훨씬 빨라 졌기 때문에 전자 제품이 튀어 나오거나 머리가 나빠질 수 있습니다.

다른 일을하는 것과 관련하여. 나는 이미 정상적인 dd로 몇 블록을 읽으려고했다고 가정합니다. 이를 기반으로 syslog를 살펴보고 거기에서 찾은 메시지를 봤습니까?

"결과 : hostbyte = invalid driverbyte = DRIVER_SENSE"를 검색하면 몇 가지 제안과 함께 몇 가지 흥미로운 읽기 (일부 독일어)가 발생합니다.

• 2.0 대신 USB 1.1을 통해 연결해보십시오
• 드라이브가 뜨거워 지므로 플라스틱으로 싸서 냉장고에 10 분 동안 두십시오. 이렇게하면 드라이브가 다시 가열되기 전에 약간의 가독성 시간이 제공됩니다.
• BIOS에서 SMART 스위치 (SATA와 연결).
• USB 드라이브에 충분한 전원이 공급되는지 확인하십시오 (추가 전원 공급 장치)
• 일정 시간 후에 USB를 통한 읽기가 실패하면 원격으로 제어되는 USB 허브를 사용하여 프로그래밍 방식으로 USB 허브에서 드라이브로 전원을 몇 초 동안 전환하십시오.

읽을 수없는 디스크를 냉각시키는 것 (냉각 스프레이로) 외에는 직접 시도하지 않았습니다.