희소 가상 디스크는 복원 과정에서 0으로 채워진 영역이 실제 블록으로 기록되거나 이미지를 씩(thick) 형식으로 다시 만들면 전체가 할당됩니다.
희소 VHD, VHDX, raw 및 QCOW2 이미지는 할당된 영역에 대해서만 스토리지를 사용하면서도 큰 논리적 용량을 보고할 수 있습니다. 백업은 파일 내용을 완벽하게 보존하더라도 홀(hole) 맵, 할당되지 않은 클러스터, 폐기 상태 또는 씬 프로비저닝 메타데이터를 잃을 수 있습니다. 복원된 게스트는 정상적으로 부팅되지만 호스트 파일은 이제 가상 크기 전체를 차지할 수 있습니다. 유일한 복원본을 압축하거나 변환하기 전에 형식과 할당 상태를 진단하세요.
논리적 크기와 실제 할당 크기 비교
이미지 형식, 가상 크기, 표시되는 파일 크기, 할당된 호스트 블록, 대상 파일 시스템, 그리고 복원된 이미지가 희소 또는 사전 할당으로 표시되는지 기록하세요.
Microsoft는 희소 파일이 할당되지 않은 영역에 대해 0을 반환하면서 더 큰 명목 파일 크기를 유지한다고 설명합니다. 따라서 가상 크기와 실제 물리적 사용량은 별도로 측정해야 합니다.
파일 브라우저에만 의존하지 말고 할당 상태를 인식하는 도구를 사용하세요. 가상 크기와 할당 크기가 이제 같다면 복원 과정에서 홀이 실제 블록으로 변환되었거나 고정 형식이 선택되었을 가능성이 높습니다.
백업에서 희소 홀을 보존했는지 확인
백업 작업의 파일 복사, 블록 복사, 아카이브, 압축 및 희소 파일 옵션을 검토하세요. 할당된 익스텐트만 저장했는지, 아니면 논리 디스크 전체를 연속된 바이트 스트림으로 읽었는지 확인하세요.
GNU Coreutils는 복사 도구가 대상에서 희소 홀을 다시 만들어야 한다고 설명합니다. 그렇지 않으면 긴 0 시퀀스가 일반 할당 블록으로 기록될 수 있습니다.
콘텐츠가 정상적으로 복원되었다고 해서 할당 메타데이터까지 보존되었다는 뜻은 아닙니다. 동일한 백업 및 복원 경로를 통해 알려진 홀이 있는 작은 테스트 이미지를 비교하세요.
이미지 변환으로 희소화가 비활성화되었는지 확인
백업 객체와 복원된 이미지 사이의 모든 변환 단계를 점검하세요. 입력 형식, 출력 형식, 사전 할당 옵션, 희소 임계값 및 복사 오프로딩 사용 여부를 기록하세요.
QEMU는 qemu-img 변환이 0 섹터를 감지하고 이를 생략할 수 있다고 설명합니다. 반면 희소 임계값이 0이거나 복사 오프로딩 경로가 지원되지 않으면 대상이 전체 할당될 수 있습니다.
가상 머신이 실행 중일 때는 이미지를 다시 변환하지 마세요. 검증된 복사본에서 작업하고 복원된 이미지를 교체하기 전에 가상 디스크 콘텐츠를 비교하세요.
대상 파일 시스템이 희소 파일을 지원하는지 확인
대상 NAS 파일 시스템과 모든 중간 스테이징 볼륨에서 희소 파일 지원 여부를 확인하세요. 호환되지 않는 파일 시스템에 먼저 복원을 수행하면 최종 스토리지에 도달하기 전에 홀이 사라질 수 있습니다.
씬 할당은 논리적 크기뿐 아니라 스토리지 객체의 프로비저닝 속성에도 좌우됩니다. 대상이 대용량 파일을 지원하더라도 백업 애플리케이션이 홀을 다시 만들지 않으면 이미지가 전체 할당 객체로 복원될 수 있습니다.
스테이징 또는 대상 파일 시스템이 홀을 보존하지 못하면 최종 VM 데이터스토어에 도달하기 전에 파일이 전체 할당될 수 있습니다. 먼저 폐기 가능한 이미지로 희소 지원을 테스트하세요.
씩 복원 형식과 게스트 여유 공간 구분
복원된 디스크가 사전 할당 raw, 희소 raw, 고정 VHD, 동적 VHDX 또는 QCOW2인지 확인하세요. 게스트의 여유 공간이 자동으로 호스트 측 홀로 변환되는 것은 아닙니다.
Red Hat은 사전 할당 가상 디스크와 희소 가상 디스크를 구분합니다. 사전 할당 디스크는 전체 크기를 즉시 예약하는 반면, 희소 디스크는 데이터가 기록될 때 스토리지를 할당합니다.
복원 대상이 의도적으로 씩 형식이었다면 전체 할당은 손상의 증거가 아니라 예상된 동작입니다. 성능과 용량 간의 절충을 고려해 다시 씬 형식으로 변환할지 결정하세요.
지원되는 오프라인 방법으로 0으로 초기화된 공간 회수
가상 머신을 종료하고 별도의 백업이 있는지 확인한 다음, 삭제된 게스트 블록이 0으로 초기화되었거나 폐기되었는지 확인하세요. 게스트 파일 시스템의 여유 공간에 이전의 0이 아닌 데이터가 여전히 남아 있을 수 있습니다.
Red Hat의 virt-sparsify 워크플로는 인식된 여유 공간을 호스트 측 희소 영역으로 변환하며 실행 중인 디스크 이미지에는 작업하지 말라고 경고합니다.
중복 이미지에서만 압축을 실행하고 이후 게스트 파일 시스템을 확인하세요. 애플리케이션 수준의 테스트가 통과할 때까지 원래 복원 이미지를 보관하세요.
사전 할당 및 홀 펀칭 동작 확인
복원 애플리케이션이 안정성이나 성능을 위해 대상을 사전 할당했는지, 그리고 대상이 이후 범위 할당 해제를 지원하는지 확인하세요.
Linux의 fallocate 인터페이스는 실제 블록을 할당하는 작업과 홀을 만드는 작업을 구분합니다. 이는 0을 기록하는 것과 공간을 할당 해제하는 것이 서로 다른 작업인 이유를 보여 줍니다.
알 수 없는 가상 디스크 형식에 직접 홀 펀칭을 수행하지 마세요. 메타데이터와 클러스터 레이아웃을 이해하는 하이퍼바이저 또는 이미지 유틸리티를 사용하세요.
교체하기 전에 복원된 디스크 검증
압축된 복사본을 격리된 환경에서 부팅하고 파일 시스템, 애플리케이션, 스냅샷 및 게스트 여유 공간을 확인하세요. 그런 다음 대표 파일의 해시와 가상 디스크에서 보고하는 구조를 비교하세요.
ZimaSpace의 홈 서버 복구 체크리스트는 이전 복사본을 제거하기 전에 스토리지와 애플리케이션 복구를 입증해야 한다는 관련 요구 사항을 제공합니다.
복원된 디스크가 의도한 씬 형식을 유지하고, 할당된 호스트 공간이 실제 게스트 데이터를 반영하며, 가상 머신이 부팅, 워크로드, 백업 및 복원 검증을 모두 통과하면 문제가 해결된 것입니다. 변환 중 오류가 발생하거나 플랫폼에 씩 프로비저닝이 필요한 경우에는 전체 할당 이미지를 유지하세요.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

