dd 명령을 사용한 것은 이번이 처음입니다. 나는 다음을 실행한다:
dd if=/dev/sdb2 of=/mnt/sdc1/Hdd1.img bs=512 conv=noerror,sync
여기서 sdb는 손상된 하드 드라이브(크기: 500GB)입니다. sdb2 파티션을 이미지에 복사했습니다. 나는 이것을 6(!!)일 동안 하고 있다. img 크기는 약 640GB이며 아직 계산 중입니다(예: 아직 완료되지 않았습니다...). 6일 후에는 복사된 데이터 세부 정보(바이트가 복사된 대상)를 인쇄하고 중지되지 않습니다.
정상인가요? img 크기가 손상된 하드 드라이브 전체 크기보다 어떻게 더 클 수 있습니까? 언제 완료될 것으로 예상되나요?
답변1
한 번에 512바이트를 복사하면 많은 수의 읽기 및 쓰기가 수행됩니다. 계산해보면 실제로는 1000억 정도 됩니다. 또한 동기화를 요청하고 있습니다. [편집: oflag=sync다음 문이 유효하지 않은 것은 아닙니다.] 이는 반환하기 전에 각 쓰기가 실제로 디스크에 기록될 때까지 기다리는 것을 의미합니다. 디스크 속도가 매우 빠르므로 각 쓰기에 2밀리초가 걸린다고 가정해 보겠습니다.
500GB / 512바이트 * 2밀리초 = 22.6일.
와, 수조 밀리 초의 시간이 빨리 합쳐지네요, 그렇죠?
[편집: 이것은 실제로 흥미로운 수학이지만 oflag=sync사용되지 않기 때문에 정확하지 않습니다. 불량 섹터의 반복 읽기 및 관련 시간 초과로 인해 지연이 발생할 가능성이 높습니다. 아래의 dd_rescue 방법이 큰 도움이 될 것입니다. 더 큰 블록 크기의 일반 dd를 사용하면 도움이 될 수 있지만 읽기 크기를 조정할 수 없고 큰 손상을 건너뛸 수 없기 때문에 그다지 많지 않습니다. ]
더 큰 블록 크기를 사용하거나 동기화를 건너뛰면 더 빠르게 실행됩니다.
# dd if=/dev/sdb2 of=/sdb2-image.img bs=1024k
sdb2 이미지에서 읽을 때 읽기 오류가 우려되는 경우 -A 옵션과 함께 dd_rescue를 사용하여 쓰기를 건너뛰는 대신 0 블록을 씁니다. 잘못된 블록을 완전히 건너뛰면 일부 파일 시스템 구조가 원래와 다른 오프셋에 나타날 때 문제가 발생할 수 있습니다. 예상치 못한 0이 있는 것이 더 좋습니다. 예를 들어:
# dd_rescue -A /dev/sdb2 /sdb2-image.img
그러면 한 번에 많은 양의 데이터를 읽기 시작하고 오류가 발생하기 시작할 때만 청크가 줄어듭니다.
편집: Micheal Johnson이 제안한 것처럼 질문에 직접 답하기 위해 conv=noerror,syncon dd또는 -Aoff 을 사용하면 dd_rescue이미지가 소스와 정확히 같은 크기가 됩니다. 이는 모든 읽기가 동일한 크기의 쓰기를 생성하기 때문입니다. 일부 버전은 dd요청 시 파일 끝 "오류"를 무시하기 때문에 장치가 종료된 후에도 오랫동안 실행될 수 있습니다 conv=noerror. 나는 Linux가 이 작업을 수행한다고 생각하지 않지만 이미지가 소스 파일보다 크게 보이는 경우 알아야 할 사항입니다.
답변2
이미지의 크기는 이미지를 생성한 파티션의 크기와 동일합니다. 파티션의 크기는 말씀하지 않으셨지만 전체 하드 드라이브 용량의 절반이라면 하드 드라이브의 크기에 따라 말씀하신 크기가 무리한 것은 아닙니다. 이미지를 저장하는 파티션에는 적어도 이미지를 생성하려는 파티션만큼의 여유 공간이 있어야 합니다. 그렇지 않으면 "장치에 남은 공간이 없습니다" 오류와 함께 작업이 실패합니다. 또한 sdc"깨진" 경우 이미지를 sdc1(이미지 파일 경로에서 알 수 있듯이) 저장하는 것은 좋지 않은 생각일 수 있습니다. "깨졌다"는 것이 무엇을 의미하는지 명확히 할 수 있습니까?
어쨌든, 스티브 본즈의 대답은 왜 그렇게 오래 걸렸는지 설명하지만, 그것은 당신이 묻는 질문이 아닙니다.