노력하는 과정에서고장난 하드 드라이브에서 데이터 복구, 나는 명령을 실행하고 있습니다 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
답변1
아직도 해당 하드 드라이브에서 데이터를 추출하려고 하는지, 아니면 이미 성공했는지는 모르겠지만, 성공하지 못했고 비트코인에서 손실된 데이터를 복구할 수 있는지 확인하고 싶다면 시도해 보세요. 어쨌든 내 생각은 당신과 같습니다. ddrescue명령줄 매개변수가 약간 수정되어 다음을 추가했습니다.
$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
/home/dave/recovery_usb500.logfile --force -R
- -d는 ddrescue에게 직접 디스크 액세스를 사용하도록 지시합니다.
- --force는 읽기/쓰기 목적으로 사용할 수 없다고 불평하는 경우 로그 파일을 강제로 사용하고 읽기/쓰기하도록 ddrescue에 지시합니다.
- -R(예, 대문자 R)은
ddrescue정방향 모드에서 고장난 하드 드라이브를 읽는 대신 역방향으로 복구 작업을 수행하도록 지시합니다. 때로는 손상이 심각한 경우 문제가 발생할 경우 하드 드라이브의 캐시를 우회하므로 역방향으로 읽는 것이 도움이 될 수 있습니다.
3현재 저는 이 명령을 사용하고 있습니다. (단, 불량 섹터를 [아직] 재시도하고 싶지 않기 때문에 사용하지 않고 있습니다. ddrescue첫 번째 스캔이 완료된 후 끝까지 그대로 놔두고 아주 잘 지내고 있습니다. 구조 성공 내 고장난 1TB Seagate 하드 드라이브에 있는 데이터는 내가 2009~2010년에 채굴했을 수 있는 비트코인을 담고 있을 것으로 추정됩니다. 각각 50BTC로 구성된 블록 1~3개를 찾았을 수도 있습니다. 이 드라이브에 있었으면 좋겠습니다. , 음, 평균 읽기 속도가 634kbps인 경우 작업을 완료하는 데 총 15일 이상이 걸립니다.
또한 9일 이상 된 "마지막 읽기 활동"의 이전 기록을 바탕으로 하드 드라이브가 추가 읽기를 거부하는 상황에 직면할 가능성이 높다는 점을 덧붙이고 싶습니다. 취소하려면 CTRL + C를 누르십시오. 로그 파일 작업 중이므로 오류가 발생한 하드 드라이브에서 SATA 케이블을 뽑으십시오. 그러나 USB 포트에서 USB 컨트롤러는 뽑지 마십시오(예, USB SATA 컨트롤러를 사용하십시오. 마더보드가 전체 컴퓨터를 잠그고 강제로 재부팅하지 않도록 한 다음 SATA 전원을 다시 연결하여 약 10초 동안 하드 드라이브를 재부팅한 다음 위쪽 또는 아래쪽 화살표를 눌러 이전 터미널 명령을 다시 로드하고 다시 시작합니다. ddrescue이전 로그로 인해 중단된 위치에서 작업이 계속되고 읽기가 완료되며 "마지막 성공 읽기"는 항상 "0s"(0초) 위치에 있어야 하며 데이터 ddrescue가 하드 드라이브에서 성공적으로 읽힌 후 "마지막 읽기"가 초를 세기 시작한다는 것을 알게 되면 +를 ddrescue사용하여 다시 종료하고 하드 드라이브를 다시 시작한 다음 재부팅하면 "마지막 읽기"가 0으로 재부팅되는지 확인하기 위해 기다릴 필요가 없습니다. 내 경험으로는 결코 일어나지 않을 일이며 영원히 기다리게 될 것입니다. 불량한 1TB 하드 드라이브에서 총 20번 정도 재부팅해야 했고, 이 작업에는 약 7일이 걸렸습니다. 며칠 동안 500GB에 도달할 뻔했습니다. 복구 표시, 아직 절반 정도 남았습니다. 지난 3일 동안 다시 634kbps 이상으로 완벽했기 때문에 100%에 가까워지면 큰 문제가 발생하지 않기를 바랍니다.CTRLCddrescue
또한 더 빠른 데이터 처리량 읽기 속도를 얻으려는 욕심을 부리지 마십시오. 많은 매개 변수와 다양한 블록 크기를 실험하려고 시도한 결과 재부팅 후 1초 이상 걸리는 완전히 죽은 하드 드라이브가 생길 뻔했습니다. 작동이 중지되었습니다(즉, 5일 전) 하지만 다행스럽게도 다시 생명의 조짐이 보이기 시작했습니다. 처음에는 2kbps 미만인 2,000bs(예, 초당 바이트)로 읽기 시작했습니다. 매우 실망했지만 ddrescueCTRL + C로 취소하고 다시 시작했습니다. 다시 (-R과 반대로) 매개변수를 추가하면 속도가 630으로 되돌아간 다음 930kbps로 앞으로 읽었습니다. 적어도 630kbps에 만족합니다. 속도는 뒤로 읽으므로 그럴 필요는 없습니다. 2kbps만큼 지연되므로 어떤 읽기 속도(예: 500kbps 범위)에서 성공했다면 이를 고수하고 속도를 높이기 위해 아무것도 시도하지 마십시오. 이것이 아마도 마지막 성공적인 시도의 읽기 속도를 얻는 방법일 것입니다.
또는 ddrescue어떤 매개변수를 시도해도 아무 것도 읽을 수 없어서 작동하지 않는다면 하드 드라이브의 로직 보드를 교체하는 것을 고려해 볼 수도 있습니다. 고장난 로직 보드는 90%의 경우 좋지 않기 때문입니다. , 하지만 먼저 로직 보드를 제거하고 하드 드라이브 핀과 접촉하는 모든 접점을 청소하십시오. 때로는 이러한 접점에 검은색 끈끈한 혼합물이 있어 접점을 차단하며 이것이 고장의 원인이 될 수 있습니다. . 그러나 하드 드라이브의 로직 보드를 교체해야 하는 경우 원래 드라이브와 최대한 유사해야 하므로 동일한 제조업체, 일련 번호(닫기), 모델 번호, 개정 번호 중 하나를 받아야 합니다. 기부위원회가 일을 시작합니다.
답변2
ddrescue로그 파일을 사용하여 중단된 위치에서 작업(종료)을 다시 시작할 수 있으므로 중지할 수 있어야 합니다 . 그러나 타임스탬프를 확인하거나 다음을 수행하여 최근에 로그 파일이 업데이트되었는지 확인합니다 tail -f /home/dave/recovery_usb500.logfile.
이미지 파일이 여전히 너무 작다는 사실은 아직 드라이브에서 성공적으로 검색되지 않은 청크와 관련이 있을 수 있습니다. 그러나 그렇게 장기적으로 보면 이는 나쁜 결과가 될 것입니다. 장치에 불량 블록이 몇 개만 있고 처음에는 없다고 가정하면 첫 번째 항목 상태는 입니다 +. IIRC ddrescue는 오류가 발견될 때까지 읽기를 시작한 다음 디스크의 나머지 부분을 분할하기 시작합니다. 디스크가 처음부터 제대로 작동하지 않는 것 같습니다.
+로그에 (여러) 항목이 없는 경우그리고귀하의 파일 크기는 여전히 잘못 0되었다고 생각하지 않는 크기입니다 ddrescue. 아니요는 +드라이브에 있는 어떤 것도 복구할 수 없다는 의미입니다. 이는 전자 장치가 파손되었거나 마음이 좋지 않음을 의미할 수 있습니다. 몇 가지 부품에만 결함이 있는 경우에도 더 빨리 결과를 얻을 수 있기 때문입니다.
다른 일을 하는 것에 관해서는. 나는 당신이 일반 dd를 사용하여 몇 개의 블록을 읽으려고 시도했다고 가정합니다. 이를 기반으로 시스템 로그를 살펴보고 거기에서 발견된 메시지를 Google에서 검색해 보셨나요?
"결과: 호스트바이트=잘못된 드라이버바이트=DRIVER_SENSE"를 검색하면 흥미로운 내용(일부 독일어)과 더 많은 제안 사항이 표시됩니다.
- 2.0 대신 USB 1.1을 통해 연결해 보세요.
- 드라이브가 뜨거워질 수 있으므로 비닐로 싸서 드라이브가 다시 뜨거워지기 전에 읽을 수 있는 시간을 갖도록 10분 동안 냉장고에 넣어 두십시오.
- BIOS의 SMART 스위치(및 SATA 연결)
- USB 플래시 드라이브의 전원이 충분한지 확인하세요(추가 전원 공급 장치)
- 잠시 후 USB를 통한 읽기가 실패하면 원격으로 제어되는 USB 허브를 사용하여 몇 초 동안 프로그래밍 방식으로 USB 허브에서 드라이브로 전원을 전환하십시오.
읽을 수 없는 디스크를 냉각하는 것(냉각 스프레이 사용) 외에는 직접 시도한 적이 없습니다.