이전 스냅샷이 라이브 파일 시스템에서 더 이상 필요로 하지 않는 블록에 대한 참조를 유지하기 때문에, 파일을 삭제한 후 스냅샷 전용 공간이 늘어날 수 있습니다.
이러한 동작은 기록 중 복사(Copy-on-Write) 스냅샷에서 정상입니다. 하지만 NAS에 표시되는 “스냅샷 크기”, “스냅샷 전용 공간”, “참조된 공간”, “회수 가능 공간”은 서로 같은 의미가 아니므로 혼동될 수 있습니다. 대용량 라이브 파일을 삭제하면 현재 데이터세트 사용량은 줄어드는 동시에, 이전 블록이 하나 이상의 보존된 스냅샷에만 속하게 될 수 있습니다. 스냅샷을 삭제하거나 스냅샷 폴더가 또 하나의 전체 복사본을 만들었다고 판단하기 전에 정확한 지표와 보존 체인을 확인하세요.
실제로 증가한 스냅샷 지표 확인하기
풀 사용량, 라이브 데이터세트 사용량, 전체 스냅샷 사용량, 스냅샷별 고유 사용량, 삭제한 파일의 크기를 기록하세요. 동일한 데이터세트와 동일한 시간 범위에서 측정한 값을 사용해야 합니다.
Synology의 Snapshot Replication 안내에서는 표시되는 스냅샷과 스냅샷이 사용하는 공간을 구분하고, 회수 가능 공간을 계산하는 기능을 제공합니다. Synology Snapshot Replication의 스냅샷 공간 제어 기능은 스냅샷 목록과 볼륨의 회수 가능 용량을 함께 확인해야 하는 이유를 보여 줍니다.
라이브 사용량은 줄었는데 스냅샷 전용 사용량만 증가했다면, 파일 삭제로 새 콘텐츠가 생성된 것이 아니라 기존 블록의 소유 관계가 바뀌었을 가능성이 큽니다. 전체 풀 사용량도 증가했다면 같은 기간에 생성된 새 스냅샷, 복제 준비 영역, 애플리케이션 버전 또는 기타 쓰기 작업을 확인하세요.
삭제로 인해 이전 블록이 스냅샷에만 남게 되는 이유 이해하기
스냅샷은 처음 생성될 때 대부분의 블록을 라이브 파일 시스템과 공유합니다. 라이브 파일 시스템이 데이터를 덮어쓰거나 삭제하면, 스냅샷은 특정 시점의 상태를 유지하기 위해 이전 블록에 대한 참조를 계속 보유합니다.
Oracle의 ZFS 관리 안내에서는 활성 데이터세트가 변경된 후 이전에 공유되던 블록이 스냅샷에만 속하게 되면 스냅샷 사용 공간이 증가한다고 설명합니다.
따라서 삭제된 파일은 라이브 디렉터리에서는 사라지지만 이전 스냅샷에서는 계속 읽을 수 있습니다. 삭제 시점에 저장 공간이 복제된 것이 아니라, 라이브 파일 시스템이 참조를 해제하고 스냅샷이 참조를 유지하면서 공간 계산 방식이 바뀐 것입니다.
여러 스냅샷이 삭제된 데이터를 계속 공유하는지 확인하기
삭제 전후에 생성된 스냅샷을 나열하세요. 삭제된 파일을 계속 탐색하거나 복원할 수 있는 가장 오래된 복구 지점과 가장 최신 복구 지점을 확인합니다.
NetApp 기술 자료에서는 이전 스냅샷이 삭제된 블록을 유지한다고 설명합니다. 따라서 다른 스냅샷이 동일한 데이터를 계속 참조하고 있다면 복구 지점 하나를 삭제해도 회수되는 공간이 거의 없을 수 있습니다.
표시된 각 스냅샷의 크기를 합산해 그 전체가 독립적으로 할당되었다고 판단하지 마세요. 공유 블록은 여러 스냅샷 보기에서 나타날 수 있지만, 마지막 참조가 제거될 때까지 실제 저장 공간은 한 번만 사용합니다.
스냅샷 폴더 보기와 실제 저장 공간 사용량 구분하기
스냅샷 폴더를 탐색하면 모든 과거 파일이 일반 복사본으로 존재하는 것처럼 보일 수 있습니다. 해당 디렉터리 보기는 복구 인터페이스이지, 바이트 단위로 두 번째 폴더 트리를 그대로 할당한 것이 아닙니다.
FreeBSD ZFS 핸드북에서는 스냅샷을 특정 시점의 데이터세트 상태로 설명하며, 변경된 데이터를 보존해야 할 때까지 저장 공간을 공유한다고 안내합니다. 이 스냅샷 모델을 통해 스냅샷 경로에서 보이는 파일과 실제로 스냅샷에만 속한 블록을 구분할 수 있습니다.
숨겨진 스냅샷 관리 디렉터리 안에서 파일을 수동으로 삭제하지 마세요. 보존 메타데이터와 복제 상태가 일관되게 유지되도록 NAS 스냅샷 관리자나 파일 시스템에서 지원하는 스냅샷 명령을 사용하세요.
ZFS와 Btrfs의 스냅샷 공간 계산을 신중하게 비교하기
ZFS와 Btrfs는 모두 기록 중 복사 참조를 사용하지만, 대시보드와 명령줄 도구에서 독점 공간, 참조 공간, 공유 공간 또는 예상 공간을 서로 다르게 표시할 수 있습니다. 현재 사용 중인 파일 시스템에 대해 문서화된 지표를 사용하세요.
Fedora Magazine의 Btrfs 안내에서는 라이브 파일이 서로 달라짐에 따라 Btrfs 스냅샷이 이전 참조를 유지한다고 설명합니다. 이것이 삭제된 원본 파일이 스냅샷 저장 공간에 계속 표시될 수 있는 핵심 이유입니다.
플랫폼 간 호환성을 고려한 NAS 대시보드는 이러한 값을 하나의 “스냅샷 크기”로 단순화할 수 있습니다. 표시된 수치가 불가능해 보인다면 보존 정책을 변경하기 전에 파일 시스템 자체의 사용량 및 스냅샷 명령으로 확인하세요.
복구 지점을 제거하기 전에 회수 가능 공간 예상하기
플랫폼에서 지원한다면 만료된 스냅샷 하나 또는 범위가 제한된 스냅샷 그룹을 선택하고, 삭제 시 예상되는 공간 회수량을 미리 확인하세요. 예상값을 삭제된 파일이 여전히 포함된 스냅샷 타임라인과 비교합니다.
Klara Systems에서는 스냅샷 저장 공간이 데이터 변경량에 따라 증가한다고 설명합니다. 따라서 스냅샷 개수만 보는 것보다 스냅샷의 생성 시점과 변경률이 보존 정책을 결정하는 데 더 유용한 지표입니다.
복구 정책의 범위를 벗어난 스냅샷만 삭제하세요. 가장 최신 스냅샷을 먼저 삭제해도 공간이 거의 회수되지 않을 수 있으며, 오래된 체인을 삭제하면 최신 증분 백업이나 복제 작업에 필요한 복구 지점이 사라질 수 있습니다.
NAS 전체 점검을 반복하지 않고 공간 회수 확인하기
승인된 스냅샷 범위 하나를 정리한 후 백그라운드 공간 회수가 완료될 때까지 기다리고, 동일한 라이브 사용량, 스냅샷 전용 사용량 및 풀 수준 측정값을 새로 고치세요. 애플리케이션과 복제 작업이 정상적으로 유지되는지도 확인합니다.
ZimaSpace의 스냅샷 및 휴지통 확인 안내에서는 NAS 용량을 사용하는 보존 계층을 구분하는 더 넓은 범위를 다룹니다. 이 문서는 삭제 후 스냅샷 전용 사용량이 증가하는 이유에만 초점을 맞춥니다.
삭제된 파일이 라이브 데이터에서 사라지고, 예상한 스냅샷에서 여전히 복원되며, 스냅샷 전용 사용량이 보존 타임라인과 일치하고, 승인된 정리를 통해 복제 또는 복구 목표를 훼손하지 않으면서 예상한 만큼 공간이 회수되면 진단이 완료된 것입니다.
지원 및 팁
더 읽어보기

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

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

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

