
과거에는 dd if=/dev/sda1 | gzip -5 > file.gz
. 얼마 후 파티션의 여유 공간이 작아졌을 때 동일한 명령으로 이미지 파일을 다시 만들었고 출력 파일이 조금 더 작아졌습니다.
두 경우 모두 동일한 버전의 dd 및 gzip, 동일한 매개변수, 동일한 하드웨어, 동일한 파티션을 사용했으며 dd에서 입출력 레코드 양과 복사된 바이트 수에 대해 동일한(시간 및 속도 제외) 출력을 얻었습니다.
그 원인은 무엇이고 어떻게 설명할 수 있나요? 그 중 하나가 유효하지 않다고 가정하여 어떤 이미지 파일이 유효하지 않은지 확인하는 방법은 무엇입니까? 더 가능성이 높은 것은 무엇입니까? 감지되지 않은 데이터 손실을 초래한 HDD 손상 또는 일부 압축 문제와 관련된 차이점이 있습니까?
답변1
압축의 특성입니다. 얼마나 효과적인지는 입력 데이터에 따라 다릅니다. 매번 다른 데이터를 압축했기 때문에 압축되지 않은 크기가 동일하더라도 압축된 크기가 달라집니다.
답변2
여유 공간이 더 잘 압축된다고 생각하는 것 같습니다. 그런 규칙은 없습니다.
일반적인 파일 시스템은 여유 공간을 여유 공간으로 표시할 뿐이며 0 등으로 덮어쓰지 않습니다. 새로운 데이터로 덮어쓰기 전까지 기존 데이터는 그대로 남아 있습니다. (참고: 삭제된 파일을 복구하는 것이 때때로 가능한 이유입니다.)
dd
모든 것을 읽습니다. 파일 시스템이나 여유 공간에 대해 아무것도 모릅니다. 그런 다음 gzip
잘 압축될 수도 있고 제대로 압축되지 않을 수도 있는 "여유 공간"의 이전 데이터를 포함하여 모든 것을 압축합니다. 이 맥락에서는 여유 공간이 없습니다. 처리할 데이터 스트림이 일부만 있습니다.
여유 공간으로 표시된 기존의 "압축률이 낮은" 데이터를 일부 새로운 "압축률이 높은" 파일로 대체할 수 있습니다. 그렇다면 새 아카이브에는 유용하거나 실제 또는 존재한다고 생각되는 데이터가 더 많이 포함되어 있음에도 불구하고 이전 아카이브보다 크기가 작아집니다. 이것이 당신이 경험한 일의 주요 원인일 수 있습니다.
참조하세요하드 디스크에서 사용 중인 공간만 복제, 그리고내 대답은 거기에 있어. "준비" 단계에서는 빈 공간을 0으로 덮어쓰므로 매우 잘 압축됩니다. 각 백업 전에 이 작업을 수행했다면 결과 아카이브의 크기는 아마도 사용자의 직관과 일치할 것입니다.
"아마도" 왜냐하면귀하의 질문에 대한 다른 답변일반적으로 옳습니다. 모두 입력 데이터에 따라 다릅니다. 여유 공간을 0으로 만든 후에도 내부 파일이 다른 경우 60%가 채워진 파일 시스템은 50%가 채워진 동일한 크기의 파일 시스템보다 더 작은 아카이브로 압축될 수 있습니다.