서버 모니터링 알림이 울렸다. "디스크 사용량 98%." 부랴부랴 접속해 df -h를 쳐 보니 정말 루트 파티션이 꽉 차 있다. 그런데 막상 du로 폴더 용량을 더해 보면 합이 영 맞지 않는다. 분명 어딘가 수십 기가가 사라졌는데 보이질 않는다. 리눅스를 운영하다 보면 한 번쯤 겪는 유령 디스크 미스터리다. 오늘은 이 범인을 차분히 찾는 순서를 정리한다.
1단계: 어디 파티션이 찼는지부터
당황하면 엉뚱한 곳을 판다. 먼저 전체 그림을 본다.
df -h/가 찼는지, /var나 /home이 따로 마운트돼 있다면 어디가 문제인지 구분한다. 로그가 쌓이는 /var가 범인인 경우가 가장 흔하다. 파티션을 특정했으면, 그 안에서 용량을 많이 먹는 디렉터리를 위에서부터 좁혀 들어간다.
du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20--max-depth=1로 한 단계씩 내려가며 가장 무거운 폴더를 따라가는 게 요령이다. 처음부터 전체를 훑으면 시간만 오래 걸린다. 무거운 폴더가 나오면 그 안으로 들어가 같은 명령을 반복한다.
2단계: du와 df가 안 맞을 때 — 삭제됐지만 안 풀린 파일
가장 헷갈리는 상황이 이것이다. du 합계는 멀쩡한데 df는 가득 찼다고 한다. 십중팔구 이미 삭제했지만 어떤 프로세스가 여전히 열어 둔 파일 때문이다. 리눅스는 파일을 rm 해도, 그 파일을 열고 있는 프로세스가 살아 있으면 실제 공간을 돌려주지 않는다.
로그 파일을 지웠는데 용량이 안 줄었다면, 그 로그를 쓰던 프로세스가 파일 핸들을 아직 쥐고 있는 것이다.
범인은 이렇게 찾는다.
lsof +L1 2>/dev/null | sort -k7 -hr | head+L1은 '링크 수가 1 미만'인, 즉 삭제됐지만 열려 있는 파일을 보여 준다. 해당 프로세스를 재시작하거나 정상적으로 종료하면 공간이 즉시 돌아온다. 흔히 웹서버나 애플리케이션을 재시작하면 수 기가가 한 번에 회수된다.
3단계: 자주 걸리는 단골 범인들
경험상 디스크를 잡아먹는 주범은 몇 가지로 정해져 있다.
| 위치 | 흔한 원인 | 대응 |
|---|---|---|
/var/log | 로그 무한 증식 | logrotate 설정 점검 |
/tmp | 임시파일 미정리 | 오래된 파일 정리 |
| 패키지 캐시 | apt·yum 캐시 누적 | apt clean 등 |
| 도커 환경 | 중지된 컨테이너·이미지 | docker system prune |
특히 로그와 도커가 압도적이다. 로그는 logrotate가 제대로 돌고 있는지 확인하고, 도커를 쓴다면 안 쓰는 이미지·볼륨이 쌓이지 않았는지 주기적으로 본다. 큰 파일만 콕 집어 찾고 싶다면 이 한 줄이 유용하다.
find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null | awk '{print $5, $9}'급한 불을 끈 다음에
용량을 회수했다면, 거기서 끝내지 말고 재발을 막는 장치를 둔다. 로그 로테이션 주기와 보관 개수를 점검하고, 디스크 사용량이 일정 수준을 넘으면 미리 알림이 오도록 모니터링 임계치를 80% 정도로 낮춰 잡는다. 98%에서 허둥대는 것과 80%에서 여유롭게 손보는 것은 하늘과 땅 차이다.
디스크가 꽉 찼다는 알림은 늘 가장 바쁜 순간에 온다. 그래도 순서만 지키면 어렵지 않다. df로 파티션을 좁히고, du로 폴더를 따라가고, 안 맞으면 lsof로 유령 파일을 찾는다. 이 세 걸음이면 사라진 용량의 정체는 대개 드러난다. 다음에 같은 알림을 만나도, 당황 대신 이 순서를 떠올려 보시길.
