NAS는 큰 파일이 사라진 후에도 자유 공간을 회복하지 못할 수 있습니다. 보이는 이름 삭제는 저장 공간 회수의 한 부분일 뿐입니다. 휴지통, 파일 시스템 스냅샷, 백업 버전 또는 실행 중인 프로세스가 여전히 파일의 기본 블록을 보유할 수 있습니다.
올바른 해결책은 여전히 블록을 참조하는 대상을 확인하는 데 달려 있습니다. 공유, 스냅샷 계층, 실행 중인 서비스, 풀 회계를 순서대로 점검하세요. 누락된 공간을 소유한 계층을 식별하기 전에는 모든 스냅샷을 삭제하거나 NAS 전체를 재시작하지 마세요.
핵심 원인: 파일은 사라졌지만 블록은 여전히 참조 중
파일은 보이는 디렉터리 항목과 데이터를 포함하는 저장 블록을 가집니다. 항목을 제거하면 폴더에서 파일이 사라지지만, 파일 시스템은 모든 남은 참조가 해제된 후에야 블록을 재사용할 수 있습니다. 이 차이가 성공적인 삭제가 항상 자유 공간 증가로 이어지지 않는 이유를 설명합니다.
리눅스 기반 NAS에서는 서비스가 이미 삭제된 파일을 열어둘 수 있습니다. 커널은 최종 파일 디스크립터가 닫힐 때까지 데이터를 보존하며, 파일 탐색기와 일반 디렉터리 스캔에서는 더 이상 볼 수 없습니다. Red Hat의 삭제된 파일 공간 보존 설명은 보유 프로세스를 중지하거나 정상적으로 재시작하면 삭제만으로는 해제되지 않은 공간이 해제되는 이유를 보여줍니다.
다른 점유자는 열린 파일 계층 위에서 작동합니다. 네트워크 휴지통 서비스는 파일을 unlink하지 않고 이동할 수 있으며, 복사-쓰기 스냅샷은 복구를 위해 이전 블록을 의도적으로 보존합니다. 보이는 결과는 비슷하지만—회수된 용량이 거의 없거나 전혀 없지만—안전한 수정 조치는 다릅니다.
어느 NAS 계층이 삭제된 데이터를 여전히 보유하고 있나요?
삭제 후 변경된 내용을 비교하는 것부터 시작하세요. 파일 이름이 숨겨진 휴지통 디렉터리로 이동했거나, 실시간 데이터셋은 줄었지만 스냅샷 사용량이 증가했거나, 풀 총합이 디렉터리 도구가 계산할 수 있는 파일보다 높게 유지될 수 있습니다. 이러한 패턴은 파괴적 정리 없이 점유자를 좁히는 데 도움이 됩니다.
| 관찰한 내용 | 가능한 공간 점유자 | 확인할 사항 | 안전한 다음 조치 |
|---|---|---|---|
| 파일은 사라지지만 휴지통 폴더가 커짐 | 공유 휴지통 | 같은 공유 및 사용자의 휴지통 | 올바른 휴지통 위치를 검토하고 비우기 |
| 실시간 데이터셋 사용량은 감소하지만 풀 사용량은 거의 변하지 않음 | 스냅샷 또는 보존된 버전 | 스냅샷 공간 및 보존 날짜 | 복구 정책 외 버전만 만료 처리 |
| 파일 시스템 사용량이 보이는 디렉터리 총합보다 높습니다 | 삭제된 파일이 열려 있음 | 연결이 끊긴 열린 파일을 가진 프로세스 | 보유 서비스를 정상적으로 재시작하거나 다시 불러오기 |
| 한 공유는 줄었지만 전체 풀의 여유 공간은 줄지 않음 | 하위 데이터셋, 예약 또는 다른 작업 부하 | 데이터셋, 애플리케이션 및 백업 작업별 사용량 | 공유가 아닌 실제 소비자를 수정하세요. |
| 삭제 직후의 여유 공간 변화 | 대기 중인 회계 또는 백그라운드 정리 | 활동이 안정된 후의 최신 풀 지표 | 다른 변경을 하기 전에 기다리고 새로 고치세요. |
휴지통은 가장 단순한 경우입니다. Samba의 VFS recycle-bin 동작은 삭제 요청을 가로채 파일을 즉시 제거하지 않고 저장소로 이동합니다. 따라서 SMB 공유를 통해 삭제된 파일은 원래 폴더에서 사라졌더라도 동일한 저장 풀에 남아 있을 수 있습니다.
스냅샷은 라이브 디렉터리에 다른 일반 파일을 유지하지 않고 블록을 보존할 수 있기 때문에 덜 명확합니다. 스냅샷이 삭제 전 상태를 참조할 때 라이브 파일을 제거하면 현재 참조만 제거됩니다. 이 스냅샷 공간 회계 예시는 다른 스냅샷이 동일한 블록을 참조할 때 한 스냅샷이 적은 공간만 회수하는 이유를 보여줍니다.
풀과 공유 값은 서로 다른 범위를 측정할 수도 있습니다. 공유는 데이터셋 또는 할당량을 보고할 수 있지만, 저장 대시보드에는 하위 데이터셋, 애플리케이션 데이터, 백업 버전, 예약 및 스냅샷 보유 블록이 포함됩니다. 삭제 실패를 결론 내리기 전에 유사한 항목끼리 비교하세요.
복구 기록을 파괴하지 않고 공간 회수하기
회수는 되돌릴 수 있는 검사에서 영구 삭제로 전환되어야 합니다. 먼저 용량 보기를 새로 고치고 올바른 풀, 데이터셋 및 공유를 읽고 있는지 확인하세요. 짧은 회계 지연은 정상일 수 있으며, 활동이 안정된 후에도 지속적인 차이가 있으면 다른 참조나 저장 범위를 조사해야 함을 나타냅니다.
- 삭제된 파일이 원래 공유에 없으며 애플리케이션에 의해 이동되거나 이름이 변경되지 않았는지 확인하세요.
- 해당 공유 및 사용자 계정과 연결된 휴지통을 검사하세요.
- 날짜, 데이터셋 및 추정 가능한 회수 공간별로 스냅샷과 백업 보존을 검토하세요.
- 숨겨진 할당을 식별하기 위해 파일시스템 사용량과 표시된 디렉터리 총합을 비교하세요.
- 풀을 변경하기 전에 하위 데이터셋, 애플리케이션 볼륨, 할당량 및 예약을 확인하세요.
- 확인된 보유자는 정상적인 보존, 서비스 또는 관리 제어를 통해 해제하세요.
파일시스템 사용량이 보이는 디렉터리 총합보다 높으면 여전히 열린 삭제된 파일을 점검하세요. lsof 열린 파일 확인은 lsof +L1을 사용해 남은 디렉터리 링크가 없는 파일을 나열합니다. 프로세스를 식별하고 정상적인 재로드 또는 우아한 재시작 경로를 사용하세요; 공간 회복만을 위해 알 수 없는 데이터베이스나 스토리지 서비스를 종료하지 마세요.
스냅샷이 보유한 데이터의 경우, 복구 지점을 삭제하기 전에 각 보존 변경이 실제로 회수할 공간을 추정하세요. 여러 스냅샷이 공유하는 블록은 마지막 참조 스냅샷이 만료될 때까지 할당된 상태로 남을 수 있으므로, 하나의 스냅샷을 제거해도 그 기록 크기만큼 공간이 돌아오지 않을 수 있습니다. 복구 가치를 우선 보존하고 보존 기간을 신중히 조정하세요.
일상적인 삭제가 반복적으로 풀을 거의 가득 채우면 용량 계획에도 문제가 있습니다. 휴지통 보존, 스냅샷, 애플리케이션, 백업 기록은 라이브 파일 크기 이상으로 여유 공간이 필요하므로 사용 가능한 NAS 용량 계획에는 이러한 덜 눈에 띄는 소비자도 포함되어야 합니다.
자주 묻는 질문
NAS 휴지통을 비웠는데 왜 공간 일부만 회복되었나요?
동일한 블록이 여전히 스냅샷, 백업 버전 또는 열린 프로세스에서 참조될 수 있습니다. 휴지통 비우기는 해당 보유자만 제거하며, 다른 참조를 무시하거나 다른 데이터셋이 예약한 공간을 해제하지 않습니다.
NAS가 새로 확보된 공간을 표시하는 데 얼마나 걸리나요?
스토리지 회계 및 백그라운드 작업이 정리되는 동안 짧은 지연은 정상일 수 있습니다. 대시보드와 파일시스템 통계가 새로 고쳐진 후에도 값이 변하지 않으면 스냅샷, 삭제된 열린 파일, 할당량, 표시된 숫자가 공유인지 전체 풀인지 확인하세요.
RAID가 삭제된 파일의 공간 해제를 방지하나요?
RAID는 일반적으로 활성 배열 전체에 삭제를 적용하며, 이전 파일을 복구 기록으로 보존하지 않습니다. 휴지통과 스냅샷은 별도의 계층이며, RAID 보호 한계는 삭제된 파일 복구나 공간 유지보다는 가용성에 관한 것입니다.
지원 및 팁
더 읽어보기

전원 손실 후 RAID 어레이가 비활성화되는 이유는 무엇인가요?
비활성 배열은 종종 메타데이터가 발견되었지만 시스템이 비정상 종료 후 안전하게 시작할 만큼 충분한 신뢰도나 구성원이 없음을 의미합니다.

누락된 RAID 멤버를 강제로 온라인 상태로 전환할 때의 위험은 무엇인가요?
강제 옵션은 오래된 메타데이터, 손상된 패리티, 누락된 쓰기 또는 활성 풀에 대한 안전 검사 우회를 허용하므로 사용하기 전에 증거를 확인하고 보존하세요.

불량 SATA 케이블과 고장 나는 NAS 드라이브를 구별하는 방법
오류가 디스크에 따라 발생하는지 아니면 SATA 경로에 남아 있는지 추적하고, 하드웨어를 교체하기 전에 전송 카운터와 미디어 상태 증거를 구분하세요.

