Ubuntu 서버에서 디스크가 꽉 찼을 때 급하게 지우지 않은 이유

알림보다 먼저 온 500 에러

작은 VPS에서 갑자기 업로드가 실패하고 관리자 페이지가 500을 냈다. CPU나 메모리 문제라고 생각했는데 SSH로 들어가 보니 디스크가 100%였다. 급해서 아무 로그나 지우고 싶었지만, 어떤 디렉터리가 커졌는지 확인하지 않으면 같은 문제가 반복된다.

그날 제일 헷갈렸던 건 df와 du의 결과가 다르게 보인 점이다. 마운트 단위의 사용량과 디렉터리별 사용량은 보는 기준이 다르다.

1단계: 어느 파티션이 찼는지 보기

먼저 파일시스템 단위로 봤다.

df -h

루트(/)가 꽉 찼다면 다음은 상위 디렉터리별 크기를 확인한다.

sudo du -h --max-depth=1 / 2>/dev/null | sort -h

내 경우에는 /var가 컸고, 다시 내려가 보니 Docker와 journal 로그가 대부분이었다.

sudo du -h --max-depth=1 /var 2>/dev/null | sort -h

2단계: 로그는 보관 기준을 정하고 줄이기

systemd journal이 큰 경우에는 무작정 파일을 삭제하지 않고 journalctl로 줄였다.

sudo journalctl --disk-usage
sudo journalctl --vacuum-time=7d

서비스별 로그 파일은 최근 에러를 먼저 확인한 뒤 크기를 줄였다.

sudo du -h --max-depth=1 /var/log | sort -h
sudo cp /var/log/myapp/app.log /var/log/myapp/app.log.bak
: > /var/log/myapp/app.log

3단계: Docker는 삭제 범위를 확인하기

Docker가 원인이면 사용하지 않는 이미지와 빌드 캐시를 확인했다.

docker system df

전체 정리 명령을 바로 쓰기보다 중지된 컨테이너와 사용하지 않는 이미지 범위부터 봤다.

docker container ls -a
docker image ls

빌드 캐시가 문제일 때는 크기를 확인한 뒤 별도 정리 대상으로 분리했다.

docker builder du

급한 상황용 체크리스트

• df -h로 가득 찬 파티션 확인
• du로 큰 디렉터리 찾기
• 로그는 journalctl --disk-usage부터 확인
• 실행 중인 로그 파일은 삭제보다 크기 줄이기 고려
• Docker 정리는 docker system df 확인 후 진행
• 정리 뒤 서비스 재시작이 필요한지 확인

끝나고 추가한 예방책

정리만 하고 끝내면 다음 달에 같은 일이 난다. 그래서 디스크 사용량 알림 기준을 80%로 낮추고, journal 보관 기간도 명시했다. 서버 운영은 큰 장애보다 작은 청소 기준을 안 정해 둔 데서 자주 흔들린다.