NAS에서는 디렉터리가 일반적인 로컬 스토리지일 수도 있고 다른 파일 시스템이 마운트되는 위치일 수도 있으므로, 디스크 사용량 도구가 오해를 일으킬 수 있습니다. 이 2026년 1월 스레드는 1TB ZimaOS 드라이브에서 사용자가 미디어가 약 450GB뿐이라고 생각했음에도 약 915GB가 사용 중으로 표시되면서 시작되었습니다. 처음에는 Docker 캐시가 원인이라고 추정했습니다. 그러나 명령 출력은 대신 다음을 가리켰습니다. /DATA/.media백업 및 원격 스토리지 마운트 지점이 관련된 경우입니다.
Docker를 정리하기 전에 사용량을 측정하세요
첫 번째 커뮤니티 답변에서는 다음 경로의 가장 큰 폴더를 확인하라고 제안했습니다 /DATA 그리고 Docker 자체의 사용량도 확인했습니다. 이는 합리적인 접근이었지만, 사용자가 확인한 결과 Docker 트리 아래에는 약 2.1GB, AppData에는 약 2GB만 있었습니다.
따라서 Docker만으로는 수백 GB의 누락된 용량을 설명할 수 없었습니다.
/DATA 파티션이 거의 가득 찼습니다.첫 번째 사용자는 /DATA/.media/UNTITLED 2 아래에서 424GB를 발견했습니다
용량 검사 결과 일반 미디어가 약 419GB였고, 그 아래에 약 424GB가 추가로 있었습니다 /DATA/.media/UNTITLED 2사용자는 그 이름이 이전에 ZimaOS 백업 대상으로 사용했던 SSD를 가리킨다는 것을 알아보았습니다.
혼란을 일으킨 부분은 실제 백업 드라이브가 더 이상 연결되어 있지 않았다는 점이었습니다.
마운트 지점이 일반적인 로컬 폴더가 될 수 있습니다
Linux의 마운트 지점은 디렉터리입니다. USB 드라이브나 SMB 공유가 마운트되면 해당 디렉터리에 접근할 때 외부 파일 시스템에 연결됩니다. 외부 파일 시스템이 사라진 뒤에도 애플리케이션이 같은 디렉터리에 계속 기록하면, 해당 기록은 그 아래의 로컬 파일 시스템에 저장될 수 있습니다.
이로 인해 “백업 대상은 외부에 있는데 왜 시스템 디스크가 가득 찼지?”라는 전형적인 문제가 발생합니다.
마운트 여부를 확인하기 전에는 .media 디렉터리를 삭제하지 마세요
문제 해결 안내에서는 마운트 상태를 확인한 후 삭제 명령을 실행하도록 제안했습니다. 이 순서가 중요합니다. 백업 대상이 실제로 마운트된 상태에서 파일을 삭제하면 로컬의 숨겨진 데이터를 회수하는 대신 외부 백업 자체가 지워질 수 있습니다.
삭제 명령은 IceWhale 지원팀의 지침이 아니라 커뮤니티 안내였으므로, 이 페이지에서는 이를 일반적인 정리 방법으로 제시하지 않습니다.
정전 후 두 번째 사용자도 동일한 패턴을 재현했습니다
스레드 후반에는 소형 ZimaOS 시스템/데이터 파티션을 사용하는 다른 사용자가 정전으로 백업 작업이 중단된 후 남아 있던 여유 공간을 모두 잃었습니다. 원시 du 출력에 마운트된 RAID와 그 아래의 SMB 데이터까지 포함되어 실제보다 훨씬 크게 표시되었습니다 /DATA/.media.
동일 파일 시스템 검사를 사용해 로컬 데이터와 마운트를 구분하세요
커뮤니티에서는 다음을 권장했습니다 du 마운트된 네트워크 공유를 제외하도록 동일한 파일 시스템에 머무르는 검사입니다. 두 번째 사례에서는 이를 통해 내부의 IP 이름 디렉터리 아래에 있는 약 30GB의 실제 로컬 데이터가 드러났습니다 /DATA/.media.
두 번째 사용자는 30GB를 확보했습니다
IP 이름의 디렉터리가 실제 SMB 마운트가 아님을 확인하고 마운트 지점 아래에 남아 있던 로컬 데이터임을 식별한 후, 사용자는 원치 않는 콘텐츠를 삭제하고 30GB를 확보했다고 보고했습니다.
이는 스레드에서 확인된 가장 확실한 결과입니다.
커뮤니티의 가설은 대상이 마운트 해제된 상태에서 백업이 기록을 수행했다는 것이었습니다
응답자는 공유가 올바르게 마운트되지 않았을 때에도 백업 프로세스가 예상한 SMB 경로에 계속 쓰기를 수행했고, 그 결과 Linux가 대신 로컬 디렉터리에 데이터를 썼다고 판단했습니다.
확인된 30GB 복구 사례는 마운트 지점 아래에 로컬 파일이 존재했음을 뒷받침하지만, 정확한 백업 경쟁 상태에 대한 설명은 이 스레드의 IceWhale 엔지니어 게시물이 아니라 커뮤니티의 진단이었습니다.
현재 ZimaOS의 백업 및 스토리지 처리 방식은 변경되었습니다
현재 ZimaOS 문서에서는 관리형 백업 작업과 더 폭넓은 스토리지 관리를 다룹니다. 새 작업에는 현재 ZimaOS 백업 워크플로를 사용하고, 대용량 쓰기를 시작하기 전에 의도한 대상이 실제로 마운트되어 있는지 확인하세요.
더 안전한 누락 공간 확인 절차
- 사용
df어느 로컬 파일 시스템이 가득 찼는지 확인하려면 - SMB, USB, RAID 마운트가 합계에 포함되지 않도록 해당 파일 시스템만 검사하세요.
- Docker와 AppData를 별도로 확인하세요.
- 검사
/DATA/.media실제 로컬 파일이 포함된 마운트 지점 디렉터리의 경우. - 마운트 지점 아래의 항목을 삭제하기 전에 대상이 마운트되어 있지 않은지 확인하세요.
- 정리 후 여유 공간을 확인하고 백업 대상에 다시 테스트 쓰기를 수행하세요.
첫 번째 사용자의 424GB 사례는 나중의 30GB 사례보다 더 모호했습니다
원 게시자는 연결이 끊긴 백업 SSD의 이름을 딴 디렉터리에서 약 424GB가 사용 중인 것을 보고 중복 데이터라고 생각했습니다. 이후 논의는 마운트 확인과 정리 제안으로 이어졌지만, 가장 명확하게 검증된 복구 결과는 나중에 참여한 사용자가 30GB를 확보한 사례였습니다.
이 구분이 중요한 이유는 다음 경로 아래의 디렉터리가 /DATA/.media 실제 마운트, 오래된 마운트 지점 또는 실제 로컬 파일을 나타낼 수 있습니다. 겉보기에 같은 경로라도 모든 시스템에서 동일하게 안전한 정리 작업을 의미하지는 않습니다.
df와 du는 서로 다른 질문에 사용하세요
df “실제로 어떤 파일 시스템이 가득 찼는가?”라는 질문에 답하는 반면 du “어떤 표시된 디렉터리에 파일이 들어 있는가?”라는 질문에 답합니다. 중첩 마운트가 있는 NAS에서는 두 도구가 서로 다른 결과를 보여 의견이 엇갈리는 것처럼 보일 수 있습니다. du 지정하지 않으면 다른 파일 시스템까지 탐색할 수 있습니다.
문제 해결 과정에서 로컬 ZimaOS-HD 파일 시스템과 마운트된 SMB 및 RAID 콘텐츠를 분리한 후에야 스레드의 상황이 훨씬 명확해졌습니다.
예기치 않은 전원 손실은 마운트 지점 문제를 더 위험하게 만듭니다
이후의 30GB 사례는 백업이 진행 중일 때 발생한 정전 이후 시작되었습니다. 부팅 후 원격 대상이 정상적으로 다시 마운트되지 않았는데 백업 작업이 재개되거나 다시 시작되면 해당 경로는 일반 로컬 디렉터리로 남아 있을 수 있습니다.
중요한 백업 작업의 경우, 이전 경로가 여전히 외부 대상 위치를 가리킨다고 가정하기 전에 재부팅 또는 전원 이벤트 후 대상이 마운트되어 있고 쓰기 가능한지 확인하세요.
공간을 확보하기 위해 Docker overlay2를 수동으로 삭제하지 마세요
스레드 초반에는 파일 시스템 출력에서 Docker overlay 경로가 시각적으로 두드러져 보였습니다. 커뮤니티에서는 임의의 파일을 삭제하지 말라고 특히 경고했습니다. overlay2Docker의 저장소 계층은 임의의 계층 디렉터리를 삭제하지 말고 Docker 또는 애플리케이션 수명 주기를 통해 관리해야 합니다.
현재 ZimaOS는 앱 저장 공간 사용량도 표시합니다
현재 ZimaOS 앱 설정에는 애플리케이션의 저장 공간 사용량이 표시되며, 지원되는 앱의 캐시를 정리할 수 있습니다. 터미널을 사용하기 전에 정상적인 애플리케이션 증가와 마운트 지점 데이터를 구분하는 데 유용합니다.
현재 ZimaOS 애플리케이션이 데이터를 저장하는 위치와 캐시 위치에 대한 설명은 파일 시스템을 확인할 때 더 안전한 첫 번째 기준을 제공합니다.
누락된 공간 FAQ
첫 번째 사용자의 수백 GB 누락 공간이 Docker overlay2 때문이었나요?
아니요. 게시된 출력에서 Docker가 차지한 공간은 사용된 공간의 작은 일부에 불과했습니다.
훨씬 작은 로컬 디스크에서 du가 테라바이트를 보고할 수 있는 이유는 무엇인가요?
스캔을 로컬 파일 시스템으로 제한하지 않으면 마운트된 원격 또는 RAID 파일 시스템을 재귀적으로 계산할 수 있습니다.
복구가 확인되었나요?
예. 이후 사용자는 SMB 마운트 지점 디렉터리 아래에 저장된 로컬 데이터에서 30GB를 복구했습니다.
