실패한 Windows / NTFS 드라이브가 있습니다. USB-to-IDE 케이블을 통해 다른 PC에 연결하고 Knoppix 7.2 LiveUSB 및 ddrescue/를 사용하여 대부분의 드라이브를 복구 할 수있었습니다 ddrutitliy. 가장 중요한 데이터를 복구했습니다. 이제 학습 연습으로 사용하고 있으며 프로세스를 더 쉽게 만들 수 있었는지, 하드웨어를 망칠 필요없이 얼마나 많은 시간을 되돌릴 수 있는지 확인했습니다.
아래의 전체 설명은 있지만 누군가가 구조 중 간헐적으로 또는 알려진 이유로 드라이브 (USB 또는 기타)의 상황을 처리하기 위해 스크립트를 성공적으로 작성했는지 궁금합니다.
를 사용 ddru_ntfsbitmap하면 부트 섹터와 MBR 비트 맵을 끌어서 사용 된 파일 공간 (60GB 드라이브의 16GB)으로 복구 범위를 좁힐 수있었습니다. 사용 된 명령은 다음과 같습니다.
ddru_ntfsbitmap -i 32256 -m MFTDomainFile.txt /dev/sdc filelocations.txt
합니다 ( -i용도는 63*512 = 32256드라이브가 FDISK에서 63을 찾기 위해 탑재되지 않습니다 때문에 때까지., 나는 생각했다 ddru_ntfsbitmap가 부트 섹터를 찾을 수있는 나에게 말했다. 분명히 그것은 보통 63 또는 2048입니다)
이 드라이브는 자주 끊어지며 단일 섹터 읽기 오류 후에 잘릴 드라이브 섹션 (처음 950MB)이 하나 있습니다. 계속하려면 USB-IDE 케이블을 뽑았다가 다시 연결하여 / dev에 드라이브를 다시 표시해야합니다. 드라이브가 끊어지면이 PC (또는 Knoppix와 관련이있을 수 있음)에서 ddrescue추가 읽기 시도를 계속 오류로 표시하여 '실제'섹터 읽기 문제를 추적하기가 어렵습니다. (우분투가있는 다른 오래된 PC에서는 어떻게 든 이것을 감지하고 끝내는 ddrescue기능이지만 다른 동작을 담당 한 것이 무엇인지 모르겠습니다.) 몇 번의 시작과 재시작으로 ddrescue큰 읽기 / 복사 에 사용할 수있었습니다. 한 번에 섹션을 만들고 디스크의 대부분을 가져옵니다. (더 나은 행동의 95 % 이상). 사용 -i및-s 옵션 문제를 해결하고 '모든 것을 나쁜 것으로 표시'문제의 영향을 제한합니다.
일반적으로 내가 사용한 명령은 다음과 같습니다.
ddrescue -S -m filelocations.txt /dev/sdc HDImage.img HDRecoverlog.txt -r2 -d -i5GB -s1GB
컷 아웃하면 1GB 섹션을 불량으로 표시하고 추가를 다시 시도하여 -AM복사를 차단하거나으로 실행할 수 있습니다 -r5. 느린 부분에서는 복사 속도가 그다지 중요하지 않은 것으로 보였으며 블록 복사를 수행 할 때 더 자주 끊어졌습니다.
시도하지 않은 모든 큰 섹션을 가져온 후 ddrescue드라이브의보다 안정적인 부분에서 밤새 실행할 수 있도록 허용 하면 해당 섹션에서 대부분의 섹터 오류가 발생했습니다. ddru_ntfsfindbad(오류가있는 파일을 찾기 위해) $ MFT에서 20 개의 섹터 오류를보고 했으므로 다음을 사용하여 밤새 다시 실행합니다.
ddrescue -S -m MFTDomainFile.txt /dev/sdc HDImage.img HDRecoverlog.txt -r-1 -d
이것은 모든 $MFT오류를 포착 했으므로 ddru_ntfsfindbad나머지 드라이브에서 여전히 오류가있는 파일을 찾기 위해 실행 되었습니다.
ddru_ntfsfindbad -i 32256 -DD -HDImage.img HDRecoverlog.txt
( -DD각 inode의 섹터 위치를 가진 디버그 로그 파일을 생성하며, 정상과 결합 ntfsfindbad.log하여 오류가있는 모든 파일을 찾을 수 있습니다 .)
그냥시키는 ddrescue전체 주말 안정된 부분에 실행, 그것은 (1112 오류에서 금요일에) 해당 섹션에 두 부문 오류 제외하고 모두를 집어 들었다. 다시 실행 ddru_ntfsfindbad하면 파일 크기가 훨씬 작아집니다.
드라이브의 어려운 전면 부분에는 여전히 '불량'으로 표시된 ~ 150MB가있었습니다. 많은 부분을 건너 뛰거나 수행하지 않았지만 드라이브 컷 아웃만큼 나쁜 것으로 표시되었습니다. ntfsfindbad 로그를 사용하면 다음과 같은 고통스러운 프로세스로 파일을 수동으로 대상으로 지정할 수 있습니다.
- USB 커넥터를 연결하십시오.
- 문제
ddrescue스핀 업 후 명령을. CTRL-C내가 나쁜 섹터를 잡는 소리가 들리면 맞지 않으면 위에서 언급 한 것처럼 위치를 잃습니다.- 와
CTRL-C그 다음 섹터에 정지하고이 다음에 시작됩니다. -X옵션은이에 대한 필요성을 제거하는 것이지만, 대신 발전의 문제 분야에 유지하고, 정말 불량 섹터를지나 이동하지 않을 것입니다.
- 와
- 드라이브를 분리하여 전원을 차단하십시오
- 고토 (1)
관심있는 대부분의 파일은이 방법으로 완전히 복구 할 수있었습니다. 시도하지 않은 큰 섹션을 수동으로 타겟팅 / 분할하면 오류없이 전체 섹션을 가져올 수 있습니다. 그러나 때로는 특정 오류를 10-20 회 다시 시도해야합니다. 이 프로세스를 사용하면 ~ 150kB의 오류를 제외한 모든 오류가 '빠르게'정리되었습니다. 그 이후로 수동 재 시도는 총 ~ 55 개의 단일 섹터 오류와 31kB로 감소했습니다. 나머지 드라이브의 동작에 따라 실제로 불량 섹터 몇 개를 모두 긁어 내고 소수의 파일을 교체 한 후 전체 이미지가 작동 할 수 있다는 사실에 놀라지 않을 것입니다 (물론 Windows / system32는 앉아 있습니다) 해당 섹션에서).
나는 이것이 데이터를 복구 할 수있는 다소 운이 좋은 경우에 해당한다는 것을 알고 있습니다. 그러나 내가 구한 마지막 디스크는 매우 비슷한 "단일 읽기 오류로 인해 드라이브가 끊어졌습니다"라는 문제가있었습니다. 디스크 및 / 또는 USB 포트를 재설정하거나 전원을 껐다 켜는 방법에 대한 여러 게시물을 읽었습니다. 내가 본 것에서 USB 전원을 차단하는 기능은 하드웨어와 Linux 커널 모두에 크게 의존합니다. 또한 비용 / 혜택이 다른 경우 가치가있는 하드웨어 및 서비스 솔루션이 있다는 것을 알고 있습니다.
그렇다면 위의 5 단계 프로세스를 처리하는 더 좋은 방법이 있습니까? 그것은 또한 '좋은'섹션에서 초기 데이터 스크랩을 더 빨리 만들었습니다 (수동이 적음). 전체 프로세스를 다루는 더 좋은 방법 (여전히 DIY)이 있습니까?
the -X option would remove the need for this, but it stays on the problem sector instead of advancing, and would never move past a really bad sector.$ timeout 후에 이동해야한다고 생각합니다. TLER를 사용하지 않는 소비자 드라이버에서는 시간이 오래 걸릴 수 있습니다.