리눅스 서버를 운영하다 보면 어느 날 갑자기 No space left on device 오류를 만나게 된다.
이때 무작정 큰 파일부터 지우기 시작하면 원인을 놓치거나 서비스 장애를 더 키울 수 있다.
이번 글에서는 리눅스에서 디스크 용량이 갑자기 부족해졌을 때 어떤 순서로 점검하면 좋은지 실전 기준으로 정리해본다.
1. 먼저 전체 파일시스템 사용량부터 확인하기
가장 먼저 해야 할 일은 어떤 마운트 지점이 꽉 찼는지 보는 것이다.
df -h
여기서 확인할 포인트는 다음과 같다.
- / 루트 파티션이 가득 찼는지
- /var 또는 /home 같은 별도 파티션이 문제인지
- tmpfs 같은 메모리 기반 파일시스템이 아닌 실제 디스크가 찬 것인지
- inode 부족인지 용량 부족인지 구분이 필요한지
예를 들어 /var가 꽉 찼다면 로그, 패키지 캐시, 컨테이너 데이터 쪽을 먼저 의심해볼 수 있다.
2. inode가 다 찬 상황인지 같이 확인하기
용량은 남았는데도 파일 생성이 안 되는 경우가 있다. 이럴 때는 inode 부족 여부를 같이 봐야 한다.
df -i
작은 파일이 엄청나게 많이 쌓인 환경에서는 용량보다 inode가 먼저 고갈될 수 있다.
대표적인 예:
- 캐시 디렉터리에 임시 파일이 폭증한 경우
- 메일 큐나 로그 스풀 파일이 많이 쌓인 경우
- 애플리케이션이 작은 파일을 과도하게 생성한 경우
3. 어느 디렉터리가 큰지 상위부터 좁혀가기
문제 파일시스템이 확인되면 그 안에서 어떤 디렉터리가 큰지 순서대로 좁혀가면 된다.
sudo du -xh /var --max-depth=1 | sort -h
또는 루트 전체를 볼 때는 이런 방식이 유용하다.
sudo du -xh / --max-depth=1 2>/dev/null | sort -h
여기서 중요한 건 한 번에 전체를 다 뒤지기보다, 큰 디렉터리부터 단계적으로 내려가는 것이다.
예를 들어 /var가 크다면 다시 아래처럼 좁힌다.
sudo du -xh /var --max-depth=1 2>/dev/null | sort -h sudo du -xh /var/log --max-depth=1 2>/dev/null | sort -h
4. 리눅스에서 자주 용량을 잡아먹는 위치들
디스크 부족 상황에서 자주 확인하는 대표 위치는 아래와 같다.
4-1. 로그 디렉터리
sudo du -sh /var/log/* 2>/dev/null | sort -h
자주 발생하는 문제:
- 애플리케이션 에러 로그 폭증
- journalctl 로그 누적
- 로그 로테이션 미설정 또는 실패
systemd 저널이 큰 경우에는 다음으로 확인할 수 있다.
journalctl --disk-usage
정리가 필요하면 보존 기간 또는 용량 제한을 걸 수 있다.
sudo journalctl --vacuum-time=7d
sudo journalctl --vacuum-size=500M
4-2. 패키지 캐시
우분투/데비안 계열에서는 패키지 캐시가 쌓일 수 있다.
sudo du -sh /var/cache/apt sudo apt clean
4-3. Docker/컨테이너 데이터
컨테이너 환경이라면 이쪽을 꼭 확인해야 한다.
docker system df
sudo du -sh /var/lib/docker 2>/dev/null
자주 쌓이는 항목:
- 사용하지 않는 이미지
- 중지된 컨테이너
- 오래된 볼륨
- 과도한 컨테이너 로그
정리 전에는 반드시 실제 운영 중인 리소스인지 확인해야 한다.
docker ps -a
docker images
4-4. 임시 디렉터리
sudo du -sh /tmp /var/tmp 2>/dev/null
배치 작업, 압축 해제, 애플리케이션 임시 파일 때문에 용량이 순간적으로 커지는 경우가 있다.
4-5. 백업 파일과 코어 덤프
운영 중 실수로 만든 압축 백업, DB dump, 코어 덤프가 용량을 크게 먹기도 한다.
sudo find / -xdev -type f \( -name "*.log" -o -name "*.gz" -o -name "*.sql" -o -name "core.*" \) -size +100M 2>/dev/null | head -50
5. 삭제보다 먼저 "지워도 되는 파일인지" 확인하기
디스크가 꽉 찼다고 바로 삭제부터 하면 위험하다. 특히 아래는 무심코 지우면 장애가 날 수 있다.
- 현재 서비스가 사용 중인 데이터 파일
- 데이터베이스 파일
- 활성 컨테이너 볼륨
- 애플리케이션이 열어둔 로그 파일
- 운영 중인 백업 체인의 일부 파일
로그 파일은 삭제보다 로테이션 또는 truncate가 더 안전할 때가 많다.
예를 들어 서비스가 파일 핸들을 쥔 상태라면 파일을 삭제해도 실제 공간이 바로 안 돌아올 수 있다.
sudo lsof | grep deleted
이 명령으로 삭제됐지만 프로세스가 아직 잡고 있는 파일을 찾을 수 있다.
6. 삭제했는데도 공간이 안 늘어난다면
이 경우는 꽤 자주 나온다. 대표 원인은 아래와 같다.
- 프로세스가 삭제된 파일을 계속 열고 있는 경우
- 다른 파일시스템을 보고 있었던 경우
- inode 부족 문제였던 경우
- 예약 블록 때문에 일반 사용자 기준 공간이 부족해 보이는 경우
삭제 후 공간이 안 돌아오면 아래를 다시 확인한다.
df -h df -i sudo lsof | grep deleted
필요하면 문제 프로세스를 재시작해야 공간이 실제 반영된다.
7. 응급조치 후에는 재발 방지까지 같이 해야 한다
한 번 정리하고 끝내면 같은 문제가 다시 반복되기 쉽다. 원인을 찾았다면 재발 방지 설정까지 같이 보는 것이 좋다.
로그가 원인이었다면
- logrotate 설정 점검
- 애플리케이션 로그 레벨 조정
- journalctl 보존 용량 제한
Docker가 원인이었다면
- 이미지/볼륨 정리 정책 수립
- 컨테이너 로그 옵션 제한
- 주기적인 점검 자동화
예를 들어 JSON 로그 크기를 제한할 수 있다.
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }
임시 파일이나 배치 작업이 원인이었다면
- 작업 후 정리 스크립트 추가
- 임시 경로 사용량 모니터링
- 실패 시 파일이 남는 로직 수정
8. 실전에서 추천하는 점검 순서 요약
디스크 부족 상황에서는 아래 순서로 보면 대부분 빠르게 원인을 좁힐 수 있다.
- df -h 로 어느 파일시스템이 찼는지 확인
- df -i 로 inode 부족 여부 확인
- du -xh --max-depth=1 로 큰 디렉터리 찾기
- /var/log, /var/lib/docker, /tmp, 패키지 캐시, 백업 파일 우선 점검
- lsof | grep deleted 로 삭제 후에도 남은 공간 점검
- 원인별로 재발 방지 설정까지 반영
마무리
리눅스 디스크 부족 문제는 단순히 파일 몇 개 지운다고 끝나는 일이 아니다.
중요한 건 어디가 찼는지, 왜 찼는지, 지워도 안전한지를 순서 있게 확인하는 것이다.
특히 운영 서버에서는 응급정리보다 원인 파악과 재발 방지가 더 중요하다.
다음에 같은 상황이 와도 당황하지 않도록, df, du, lsof, 로그와 컨테이너 저장소
점검 흐름 정도는 익혀두면 꽤 강력하다.