리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

리눅스 서버에서 /var 용량이 찼을 때 로그, 캐시, 스풀, 서비스 데이터를 구분하고 바로 삭제하지 않고 안전하게 확인하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 /var 용량이 가득 차면 단순히 디스크 공간이 부족한 문제로 끝나지 않을 수 있습니다. /var에는 로그, 캐시, 스풀, 패키지 데이터, 애플리케이션 상태 파일이 쌓이는 경우가 많아서 서버 운영 중 /var가 차면 로그 기록 실패, 서비스 기동 실패, 배치 오류, 패키지 설치 실패 같은 장애로 이어질 수 있습니다.

이번 글에서는 /var 용량 부족 알림이 떴을 때 바로 삭제하지 않고, 어떤 경로가 커졌는지 구분한 뒤 안전하게 확인하는 순서를 정리해보겠습니다.

/var에는 뭐가 쌓일까?

/var는 이름 그대로 변하는 데이터가 많이 쌓이는 경로입니다.

대표적으로 이런 것들이 있습니다.

/var/log      → 시스템 로그, 서비스 로그
/var/cache    → 패키지 캐시, 애플리케이션 캐시
/var/spool    → 메일, 프린트, 작업 큐
/var/tmp      → 재부팅 후에도 남을 수 있는 임시파일
/var/lib      → 서비스 상태 데이터, DB성 데이터, 컨테이너 데이터

 

그래서 /var가 꽉 차면 “로그 하나 지우면 되겠지”로 보기 어렵습니다.

어떤 서비스가 어떤 용도로 쓰는 공간인지 먼저 확인해야 합니다.

특히 /var/lib는 더 조심해야 합니다.
이 경로 아래에는 DB 데이터, 컨테이너 데이터, 패키지 관리 데이터, kubelet 데이터처럼 서비스 운영에 직접 영향을 주는 파일이 있을 수 있습니다.

가상의 운영 상황 예시

예를 들어 운영 서버에서 이런 알림이 발생했다고 가정해보겠습니다.

[상황]
- 디스크 사용률 알림 발생
- df -h /var 결과 Use% 92% 확인
- 애플리케이션 로그 기록 지연 발생
- 패키지 설치 작업 실패
- /var/log 또는 /var/lib 증가 의심

 

이 상황에서 초보 운영자는 이렇게 생각할 수 있습니다.

/var가 찼으니까 /var/log만 지우면 되지 않을까?

 

하지만 /var는 로그만 있는 공간이 아닙니다.

/var/log, /var/cache, /var/spool, /var/lib는 각각 성격이 다릅니다.
따라서 먼저 어떤 하위 경로가 커졌는지 확인해야 합니다.

초보 운영자가 하기 쉬운 실수

/var가 90% 이상 찼다고 보면 바로 이런 명령어를 떠올리기 쉽습니다.

 

rm -rf /var/log/*
rm -rf /var/cache/*

 

하지만 운영 서버에서는 매우 조심해야 합니다.

로그는 장애 원인 분석에 필요할 수 있고, /var/lib 아래에는 서비스 데이터가 있을 수 있습니다.

특히 Docker, containerd, DB, 패키지 관리 도구, Kubernetes kubelet이 /var 아래 데이터를 쓰는 경우도 있습니다.

그래서 /var는 바로 삭제가 아니라, 무엇이 커졌는지 먼저 확인하는 공간으로 봐야 합니다.

1단계. df -h로 /var가 별도 파일시스템인지 확인하기

먼저 /var가 실제로 어느 파일시스템에 있는지 확인합니다.

 

df -h /var

 

예시입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        30G   27G  3.0G  90% /var

 

여기서 /var가 별도 마운트라면 /var 내부를 확인하면 됩니다.

반대로 /var가 /에 포함되어 있다면 루트 파일시스템 전체 용량 문제로 이어질 수 있습니다.

전체 파일시스템도 함께 봅니다.

 

df -h

 

Use%만 보지 말고 Mounted on을 같이 봐야 합니다.

같은 90%라도 /var가 찬 것인지, /가 찬 것인지, /data가 찬 것인지에 따라 대응 방향이 달라집니다.

 

df -h 결과를 볼 때는 Use%만 보면 놓치는 경우가 있습니다. 어느 파일시스템이 찼는지에 따라 대응 순서가 달라지기 때문에 Mounted on을 함께 확인하는 습관이 중요합니다.

2026.05.02 - [리눅스] - 리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

리눅스 서버 df -h 결과, Use%만 보면 안 되는 이유와 확인 순서

 

2단계. /var 안에서 큰 디렉터리 찾기

이제 /var 안에서 어디가 큰지 봅니다.

 

du -xhd1 /var 2>/dev/null | sort -h

 

예시입니다.

500M    /var/cache
1.2G    /var/spool
8.0G    /var/log
15G     /var/lib
25G     /var

 

여기서 /var/log가 큰지, /var/lib가 큰지에 따라 확인 방향이 완전히 달라집니다.

/var/log   → 로그 증가 확인
/var/cache → 패키지 캐시, 애플리케이션 캐시 확인
/var/spool → 큐 적체 확인
/var/tmp   → 오래된 임시파일 확인
/var/lib   → 서비스 데이터, 컨테이너, DB 데이터 확인

 

/var/log가 크면 로그를 봐야 하고, /var/lib가 크면 서비스 데이터, 컨테이너, DB 관련 데이터를 의심해야 합니다.

이 단계에서 중요한 건 삭제가 아니라 분류입니다.

/var 문제는 /tmp처럼 임시파일만 보는 방식으로 접근하면 위험합니다. /tmp 용량이 찼을 때 안전하게 확인하는 흐름은 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량 찼을 때 당황해서 바로 삭제하지 마세요 - 안전한 임시 파일 확인 및 조치

 

3단계. /var/log가 크면 로그부터 확인하기

로그가 큰 경우에는 어떤 로그가 커졌는지 확인합니다.

 

du -xhd1 /var/log 2>/dev/null | sort -h

 

큰 파일을 직접 찾을 수도 있습니다.

 

find /var/log -xdev -type f -size +500M -ls 2>/dev/null

 

예시입니다.

/var/log/nginx/access.log
/var/log/messages
/var/log/example-app/app.log

 

여기서 바로 삭제하지 말고, 왜 커졌는지 먼저 봐야 합니다.

 

tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/messages

 

로그가 갑자기 커졌다면 같은 오류가 반복 출력되고 있을 수 있습니다.

예를 들면 이런 상황입니다.

- 애플리케이션 오류가 초당 반복 출력됨
- 외부 연동 실패 로그가 계속 쌓임
- 접근 로그가 비정상적으로 증가함
- 배치 실패 로그가 반복됨
- 디버그 로그가 운영 환경에서 켜져 있음

 

이런 경우 단순히 로그 파일만 비워도, 원인이 남아 있으면 다시 빠르게 커질 수 있습니다.

4단계. 로그 파일은 삭제보다 로테이션 상태 확인하기

로그가 크다고 바로 삭제하면 안 됩니다.

먼저 logrotate 설정을 확인합니다.

 

ls -l /etc/logrotate.d/

 

특정 로그가 로테이션 대상인지 확인합니다.

 

grep -R "/var/log/example-app" /etc/logrotate.d/

 

로테이션이 안 되어 있으면 로그가 계속 커질 수 있습니다.

운영 서버에서는 직접 삭제보다 이런 방향으로 봐야 합니다.

- 로그가 왜 커졌는지 확인
- logrotate 설정이 있는지 확인
- 보관 정책 확인
- 필요하면 로그 백업 후 정리
- 서비스가 잡고 있는 deleted 파일 여부 확인

 

deleted 파일도 같이 확인합니다.

 

lsof | grep deleted | grep /var/log

 

로그를 삭제했는데 용량이 줄지 않는다면 프로세스가 파일을 아직 잡고 있을 수 있습니다.

이때 바로 kill -9 하거나 reboot 하기보다, 어떤 프로세스가 어떤 파일을 잡고 있는지 먼저 확인해야 합니다.

 

/var 용량 문제는 로그 파일 증가와 자주 연결됩니다. 로그를 삭제했는데도 용량이 줄지 않거나 df와 du 결과가 다르게 보인다면 deleted 파일을 함께 확인해야 합니다.

https://opsnote.tistory.com/65

리눅스 서버 df와 du 결과가 다르게 보일 때 deleted 파일부터 확인하는 법

 

5단계. /var/cache가 크면 패키지 캐시 확인하기

/var/cache가 크다면 패키지 캐시나 애플리케이션 캐시가 쌓였을 수 있습니다.

 

du -xhd1 /var/cache 2>/dev/null | sort -h

 

RHEL, Rocky, CentOS 계열이라면 패키지 캐시가 있을 수 있습니다.

 

du -sh /var/cache/dnf 2>/dev/null
du -sh /var/cache/yum 2>/dev/null

 

캐시 정리는 비교적 안전한 편인 경우도 있지만, 운영 기준이 있을 수 있으니 확인 후 진행해야 합니다.

예를 들어 dnf 캐시 정리는 아래처럼 할 수 있습니다.

 

dnf clean all

 

다만 이것도 운영 서버에서는 패키지 관리 정책과 영향 여부를 확인한 뒤 실행하는 것이 좋습니다.

특정 애플리케이션 캐시라면 더 조심해야 합니다.
서비스가 캐시 파일을 계속 참조 중일 수 있고, 캐시를 삭제한 뒤 재생성 과정에서 순간적으로 부하가 생길 수 있습니다.

6단계. /var/spool이 크면 큐 적체를 의심하기

/var/spool은 작업 대기열 성격의 파일이 쌓일 수 있는 곳입니다.

 

du -xhd1 /var/spool 2>/dev/null | sort -h

 

메일 큐, 프린트 큐, cron 관련 파일 등이 있을 수 있습니다.

메일 큐가 많다면 단순 삭제보다 왜 발송이 안 되고 쌓였는지 봐야 합니다.

- 메일 발송 실패
- DNS 문제
- 외부 SMTP 연결 실패
- 작업 큐 처리 지연
- 배치 실패

 

스풀은 “쌓인 결과”일 뿐이고, 진짜 원인은 처리 실패일 수 있습니다.

따라서 /var/spool이 크다면 파일을 지우기보다 큐가 왜 처리되지 않는지 확인해야 합니다.

7단계. /var/lib가 크면 더 조심하기

/var/lib가 크다면 특히 조심해야 합니다.

 

du -xhd1 /var/lib 2>/dev/null | sort -h

 

여기에는 서비스 데이터가 들어가는 경우가 많습니다.

예를 들면 이런 경로입니다.

/var/lib/docker
/var/lib/containerd
/var/lib/mysql
/var/lib/pgsql
/var/lib/rpm
/var/lib/kubelet

 

이 경로들은 함부로 삭제하면 서비스 장애로 바로 이어질 수 있습니다.

특히 /var/lib/docker, /var/lib/containerd, /var/lib/mysql 같은 경로는 운영 데이터일 수 있습니다.

아래 명령어는 절대 가볍게 실행하면 안 됩니다.

 

rm -rf /var/lib/*

 

/var/lib는 “용량 많이 쓰니까 지워도 되는 곳”이 아니라, 서비스가 상태를 저장하는 공간으로 보는 게 안전합니다.

/var/lib가 큰 경우에는 해당 서비스의 정리 방식으로 접근해야 합니다.

Docker 이미지 정리 → docker 명령어 기준으로 검토
containerd 데이터 정리 → 컨테이너 런타임 기준으로 검토
DB 데이터 증가 → DB 내부 용량과 테이블 확인
kubelet 데이터 증가 → Pod, 이미지, 로그 정책 확인
패키지 DB → 패키지 관리 도구 상태 확인

 

8단계. 최근에 커진 파일 확인하기

최근에 갑자기 /var가 찼다면 최근 수정된 큰 파일을 확인합니다.

 

find /var -xdev -type f -mtime -1 -size +100M -ls 2>/dev/null

 

최근 1시간 안에 생성 또는 수정된 파일을 볼 수도 있습니다.

 

find /var -xdev -type f -mmin -60 -ls 2>/dev/null | head

 

이렇게 보면 갑자기 커지는 로그나 임시 파일을 찾는 데 도움이 됩니다.

최근 파일이 계속 늘어난다면 단순 정리보다 원인 확인이 먼저입니다.

- 어떤 프로세스가 만들고 있는지
- 특정 오류가 반복되는지
- 배치가 실패하고 있는지
- 로그 레벨이 과도하게 설정됐는지
- 외부 연동 실패로 큐가 쌓이는지

 

9단계. inode도 같이 확인하기

/var는 작은 파일이 많이 쌓이는 경우도 많습니다.

용량은 남아 있는데 파일 생성이 안 된다면 inode를 확인합니다.

 

df -i /var

 

예시입니다.

Filesystem      Inodes  IUsed  IFree IUse% Mounted on
/dev/sda3      2000000 1999000  1000  100% /var

 

이 경우 용량보다 inode 부족이 문제일 수 있습니다.

작은 파일이 많은 경로를 확인합니다.

 

for d in /var/*; do echo "$d"; find "$d" -xdev -type f 2>/dev/null | wc -l; done

 

작은 파일이 많이 쌓이면 df -h에서는 용량이 남아 보여도 파일 생성이 실패할 수 있습니다.

 

용량은 남았는데 파일 생성이 안 되는 상황은 inode 부족일 수 있습니다. df -h가 정상인데 No space left on device가 뜬다면 아래 글에서 df -i 확인 방법을 함께 보면 좋습니다.

https://opsnote.tistory.com/66

리눅스 서버 용량은 남았는데 파일 생성이 안 될 때 df -i로 inode 확인하는 법

 

10단계. 운영자 보고 문장 예시

/var 용량 부족을 발견했다면 이렇게 보고하면 좋습니다.

[/var 용량 부족 확인]

- 발생 시각: 2026-07-08 15:20
- 대상 서버: web-01
- 증상: /var 파일시스템 Use% 92% 확인
- 확인 내용:
  1) df -h /var 결과 /var 92% 사용 중
  2) du -xhd1 /var 결과 /var/log 약 12G 확인
  3) /var/log/example-app/app.log 파일이 8G로 확인
  4) logrotate 설정 확인 중
  5) lsof deleted 여부 확인 중
- 추정 원인:
  애플리케이션 로그 반복 증가 가능성
- 조치 방향:
  로그 증가 원인 확인 후 로테이션 및 정리 검토

 

이렇게 적으면 “용량 찼습니다”보다 훨씬 명확합니다.

운영 보고에서는 아래 내용을 함께 적으면 좋습니다.

- 어느 파일시스템이 찼는지
- /var 아래 어떤 경로가 큰지
- 로그, 캐시, 스풀, 서비스 데이터 중 무엇인지
- 최근 증가인지 오래 누적된 것인지
- 삭제 가능한 파일인지 확인이 필요한 데이터인지

 

운영 서버에서 조심할 점

/var가 찼을 때 아래 명령어는 특히 조심해야 합니다.

 

rm -rf /var/log/*
rm -rf /var/cache/*
rm -rf /var/lib/*
kill -9 <PID>
reboot

 

/var는 단순 임시공간이 아니라 서비스 운영 데이터가 많이 들어가는 경로입니다.

특히 /var/lib는 함부로 지우면 서비스 데이터가 사라질 수 있습니다.
로그 파일도 장애 원인 분석에 필요할 수 있으므로, 삭제보다 원인 확인과 로테이션 상태 확인이 먼저입니다.

안전한 흐름은 이렇게 잡는 것이 좋습니다.

1. df -h /var 확인
2. Mounted on 확인
3. du -xhd1 /var 로 큰 경로 확인
4. /var/log, /var/cache, /var/spool, /var/lib 구분
5. 로그 증가 원인 확인
6. deleted 파일 확인
7. inode 확인
8. 정리 가능 여부 확인 후 조치

 

디스크 용량 문제를 처음부터 순서대로 보고 싶다면 전체 점검 흐름도 함께 확인해두면 좋습니다. 아래 글에서는 디스크 사용률이 90%를 넘었을 때 바로 삭제하지 않고 확인하는 순서를 정리했습니다.

https://opsnote.tistory.com/1

리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법

 

정리하면

/var 용량이 차면 서비스도 위험해질 수 있습니다.

이유는 /var 아래에 로그, 캐시, 스풀, 서비스 데이터가 함께 쌓이기 때문입니다.

확인 명령어는 이렇게 시작하면 됩니다.

 

df -h /var
du -xhd1 /var 2>/dev/null | sort -h
find /var -xdev -type f -size +500M -ls 2>/dev/null
lsof | grep deleted | grep /var
df -i /var

 

/var 용량 문제는 로그 파일 증가와 함께 나타나는 경우가 많습니다.

로그가 계속 커질 때는 바로 비우기보다, 어떤 오류가 반복되는지, logrotate가 정상 동작하는지, deleted 파일이 남아 있는지 먼저 확인하는 것이 좋습니다.

로그 파일이 계속 커질 때 확인하는 순서는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/7

리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법

 

리눅스 서버 장애 대응 전체 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/69

초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리

 

디스크 용량 문제를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리