고장난 하드 드라이브의 데이터를 저장해야 합니다.
~처럼 들리다ddrescue 또는 myrescue(혹은 어쩌면크론질라? )는 여기서 가장 친한 친구가 될 것입니다. 하지만 무엇이 더 빠를지 궁금합니다.
- dd/ddrescue/myrescue/clonezilla를 사용하여 오류가 발생한 드라이브를 동일한 용량의 새 드라이브에 간단히 복제하세요.
- rsync/tar/cp를 사용하여 실패한 드라이브에서 새 드라이브로 파일 이동
?
dd-ish는 커널 공간과 사용자 공간 사이에서 데이터가 앞뒤로 이동하는 것을 방지하기로 선택했습니다. 그렇죠? 하지만 rsync 등은 빈 공간 이동을 피하는군요.
dd-ish 솔루션을 사용하면 또 다른 이상한 축복은 다음과 같습니다. 실패한 드라이브는 현재 읽기 전용으로 마운트되어 있으므로(실패 프로세스의 일부라고 가정), 도중에 데이터가 변경되는 것에 대해 걱정할 필요가 없습니다. 하고 있어요.
이것은 루트 파티션이므로 완료되면 새 드라이브를 부팅할 수 있어야 하므로 dd가 편리할 것입니다.
답변1
rsync가 더 빨라질 것이라는 데는 의심의 여지가 없습니다. dd는 전체 1.5TB를 읽고 써야 하며 모든 불량 블록에 도달하여 여러 번의 읽기 재시도를 트리거하므로 이미 긴 프로세스의 속도가 더욱 느려집니다. rsync는 중요한 블록만 읽으며 각 불량 블록이 기존 파일이나 디렉터리에서 발생할 가능성이 적기 때문에 rsync에서 발생하는 불량 블록이 더 적습니다.
디스크 복구를 위해 rsync를 사용할 때의 단점은 불량 블록이 발견되면 불량 블록이 포함된 파일이나 디렉터리를 포기한다는 것입니다. 디렉터리에 많은 하위 디렉터리가 포함되어 있고 rsync가 해당 디렉터리 읽기를 포기하는 경우 복사본에 저장하려는 콘텐츠가 많이 누락되었을 수 있습니다. 문제는 rsync가 파일 시스템 구조에 의존하여 복사할 내용을 알려주고 파일 시스템 자체는 더 이상 신뢰할 수 없다는 것입니다.
그래서 먼저 rsync를 사용하여 드라이브에서 파일을 복사했지만, 내가 놓친 내용을 확인하기 위해 출력을 매우 주의 깊게 살펴보았습니다. rsync가 복사할 수 없는 것을 참을 수 없다면 dd 또는 다른 저수준 블록 복사 방법 중 하나를 사용하십시오. 그런 다음 복사본을 fsck하고 마운트한 후 더 많은 파일을 복구할 수 있는지 확인할 수 있습니다.