그래서 최근에 우리는 하드 드라이브가 죽어가면서 사용 중인 모든 데이터를 복사하려고 했습니다 safecopy. 내가 찾을 수 있는 모든 가이드와 문서에는 safecopy출력이 이미지 파일이어야 한다고 명시되어 있습니다. 명령이 처리되었지만 XXX수백, 수천 개의 블록 읽기가 실패했음을 나타내는 출력으로만 생성되었습니다. 분명히 이는 드라이브가 여전히 마운트 가능하고 대부분의 파일을 읽을 수 있으므로 잘못된 것입니다. 다음으로 누군가 제안한 대로 HDD 파티션( /dev/sdb2)을 출력으로 지정하여 다시 시도했습니다(해당 스레드를 더 이상 찾을 수 없습니다. 일주일이 넘었습니다). 명령이 실행되고 출력이 성공적으로 읽혀지며 5일이 조금 넘게 완료될 것으로 예상됩니다.
이제 드라이브에 복구된 데이터가 모두 있지만 파티션을 읽을 수 없게 되었습니다. 손상된 드라이브가 빨리 죽기 때문에 복구를 반복할 수 없으며(헤드 크래시, 이는 매우 폭력적인 상황입니다) 명령이 완료되고 기록된 이후 실행 중이었던 다른 HDD에서 데이터를 어떻게든 가져와야 합니다. 파티션 바로 위에 있어주세요. 어떻게든 회수할 수 있나요? 의도한 대상이 .img파일인 경우 장치 파일의 원시 데이터를 with로 복사하면 명령이 시작되도록 하는 "예상 결과"를 얻을 .img수 있다고 생각합니다 (예: 파일 형식 이 아닌 파일 형식) . 장치), 그러나 몇 퍼센트의 작동 후에는 작동이 멈추고 몇 시간이 지나도 복구되지 않았습니다.ddsafecopy.imgdd
휘발성 시스템에서의 실행으로 인해 정확한 복사본과 출력이 손실되었지만 장치와 매개변수를 기반으로 기억하면 sudo safecopy --stage1 -b 4096 -R 2 /dev/sda2 /dev/sdb21단계 복사를 수행하고 /dev/sda2(손상된)에서 (백업)까지dev/sdb2 추가하는 두 번의 재시도가 있었습니다. 블록 크기는 4096바이트입니다. ...내가 알 수 있는 한, 블록 읽기가 성공했음을 나타내는 출력이 대부분 생성됩니다. safecopy약 3TB의 데이터가 기록되어 성공적으로 완료되었음을 알리는 출력이 종료됩니다 .
sudo file -s /dev/sdb2오류 메시지만 생성되며 재시도를 통해 기기에 있는 내용에 대해 더 많은 정보를 얻을 /dev/sdb2: ASCII text, with very long lines, with no line terminators수 있습니다 .hexdump -C /dev/sdb2
00000000 42 61 44 62 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |BaDbLoCkBaDbLoCk|
*
01000030 42 61 44 62 4c 6f 43 6b 10 00 00 00 4c 6f 43 6b |BaDbLoCk....LoCk|
01000040 c4 7b 00 00 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |.{..LoCkBaDbLoCk|
01000050 42 61 44 62 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |BaDbLoCkBaDbLoCk|
*
0101ef10 c8 7b 00 00 4c 6f 43 6b 42 61 44 62 4c 6f 43 6b |.{..LoCkBaDbLoCk|
0101ef20 c9 7b 00 00 ca 7b 00 00 cb 7b 00 00 cc 7b 00 00 |.{...{...{...{..|
0101ef30 cd 7b 00 00 ce 7b 00 00 cf 7b 00 00 d0 7b 00 00 |.{...{...{...{..|
0101ef40 d1 7b 00 00 d2 7b 00 00 d3 7b 00 00 d4 7b 00 00 |.{...{...{...{..|
나머지 줄은 일반 디스크 데이터처럼 보이지만, 이상하게도 hexdump처음 몇 천 개의 블록을 성공적으로 읽었음에도 불구하고 첫 번째 줄에는 불량 블록이 표시됩니다.safecopy