ddrescue는 파일이 포함되지 않은 블록을 포함하여 디스크나 파티션의 모든 블록을 복구하려고 시도하는 것 같습니다. 파일 시스템(예: NTFS의 마스터 파일 테이블)을 살펴봄으로써 어떤 블록이 실제로 파일을 보유하고 있는지 알아내는 것이 가능하지 않습니까?
편집하다: partclone과 함께 사용하면 가능할 것 같습니다.
http://partclone.org/features/
복구 상황의 경우 Partclone의 복구 모드는 불량 블록을 건너뛰고 파티션의 모든 양호한 블록을 백업하려고 시도합니다. ddrescue 프로그램은 불량 디스크를 저장하는 또 다른 더 나은 솔루션이며, 사용된 모든 블록을 도메인 파일로 나열하는 partclone의 도움으로 파티션을 덤프할 때 ddrescue를 더 스마트하고 빠르게 만들 수 있습니다.
또한보십시오: http://sourceforge.net/p/partclone/mailman/partclone-user/thread/[이메일 보호됨]/
답변1
짧은 대답: 그것이 목적이 아니기 때문입니다. Ddrescue는 한 가지 작업(고장난 HDD를 1:1 복사)을 수행하며 이를 잘 수행합니다.
답변2
dd 자체와 마찬가지로 ddrescue도 모든 블록 장치, 심지어 파일 시스템이 없거나 손상된 장치에서도 작동하도록 되어 있기 때문에 이것이 가능하다고 생각하지 않습니다. 파일 시스템이 존재한다면 그것을 살펴보면 복잡해질 뿐입니다.
답변3
오래된 스레드이지만 다른 사람들에게 도움이 될 수 있습니다 ...
입력이 NTFS 형식 볼륨인 경우 ddrutility의 ddru_ntfsbitmap을 사용하여 $Bitmap 시스템 파일을 사용하여 ddrescue에 대한 맵 파일을 생성할 수 있습니다. 이는 정확히 NTFS 파티션에서 사용되거나 사용되지 않은 클러스터의 맵입니다. 물론 제대로 작동하려면 $Bitmap 파일이 완전히 읽을 수 있는 영역에 그대로 있어야 합니다(일반적으로 파티션의 시작 부분에 위치함). 그렇다면 작업은 빠르게 진행됩니다(처음이자 지금까지의 경험에서는 1TB 파티션에서 맵 파일을 생성하는 데 약 2분이 걸렸습니다). 그런 다음 다음 기본 명령을 사용하여 ddrescue를 실행합니다.
ddrescue [options] [input path] [output path] [logfile] -m [mapfile]
최근 버전의 ddrescue에서는 복구 중에 입력 볼륨의 복구된/시도되지 않은/불량 영역이 저장되는 파일인 "logfile"이라는 용어가 "mapfile"로 대체되어 상당히 혼란스럽습니다. . 따라서 예를 들어 ddru_ntfsbitmap에서 생성한 Recovery_bitmap.log라는 맵 파일을 사용하여 /dev/sdc라는 HDD를 Recovery라는 /media/sdd1의 이미지로 복구하려는 경우 명령은 다음과 같아야 합니다.
ddrescue [options] /dev/sdc /dev/sdd1/Recovery /dev/sdd1/Recovery.log -m /dev/sdd1/Recovery_bitmap.log
답변4
ddrescue주된 이유는 아마도 다양한 파일 시스템에 대한 정보를 통합하고 내부 구조를 구문 분석해야 하므로 의 코드를 훨씬 더 복잡하게 만들기 때문일 것입니다 .
그러나 추가적인 개발 노력을 무시하더라도 어떤 블록에 데이터가 있는지 알아내는 것은 일반적으로 어렵습니다. ddrescue일반적으로 데이터가 이미 손상되어 일관성이 없는 상황에서 사용됩니다. 이러한 상황에서 사용된 블록을 찾으려고 시도하는 것은 위험합니다. 사용 가능한 블록 목록 자체가 손상되었지만 여전히 읽을 수 있는 경우에는 어떻게 되나요? 또는 파일의 현재 버전을 더 이상 복구할 수 없지만 파일의 이전 버전이 여전히 사용 가능한 블록에 존재할 수도 있습니다(파일 시스템이 제자리에서 덮어쓰지 않았기 때문).
이 경우 유일한 안전한 옵션은 모든 것을 파악하고 세부 사항을 나중에 정리하는 것입니다.