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

리눅스 서버 디스크 용량 90% 이상일 때 확인해야 할 df -h, du -sh, find 명령어 안내 이미지

리눅스 서버를 운영하다 보면 디스크 용량 90% 이상 사용 중 같은 알림을 받을 때가 있습니다. 이때 바로 파일을 삭제하면 로그 분석에 필요한 파일을 지우거나, 서비스가 사용 중인 파일을 잘못 건드려 장애가 커질 수 있습니다. 디스크 용량 부족 상황에서는 먼저 df -h로 어떤 파일시스템이 찼는지 확인하고, du, find, lsof 명령어로 원인을 좁혀가야 합니다. 이번 글에서는 초보 운영자가 서버 용량 부족 알림을 받았을 때 바로 삭제하지 않고 안전하게 확인하는 순서를 정리합니다.

디스크 용량 90% 알림이 위험한 이유

디스크 사용률이 90%를 넘었다고 해서 바로 서비스가 중단되는 것은 아닐 수 있습니다.

하지만 남은 공간이 적어지면 여러 문제가 이어질 수 있습니다.

로그 파일 기록 실패
애플리케이션 임시파일 생성 실패
파일 업로드 실패
배포 중 압축 해제 실패
DB 또는 WAS 오류
백업 파일 생성 실패
패키지 설치 실패

 

특히 /, /var, /tmp, /data 같은 경로가 꽉 차면 서비스 영향이 커질 수 있습니다.

초보 운영자가 여기서 흔히 하는 실수는 “용량이 부족하니까 큰 파일부터 지우면 되겠지”라고 판단하는 것입니다.
하지만 운영 서버에서는 파일 크기보다 그 파일이 무엇인지, 누가 사용 중인지, 지워도 되는지가 먼저입니다.

가상의 운영 상황 예시

예를 들어 웹서버에서 아래와 같은 알림을 받았다고 가정해보겠습니다.

[경고]
서버: web-01
증상: 디스크 사용률 92%
영향: 일부 로그 기록 지연 가능성
확인 필요 경로: /var

 

이 상황에서 바로 아래 명령어를 실행하면 위험할 수 있습니다.

 

rm -rf /var/log/*

 

왜냐하면 /var/log 안에는 장애 원인을 확인할 로그가 있을 수 있고, 현재 프로세스가 쓰고 있는 로그 파일도 있을 수 있기 때문입니다.

그래서 먼저 확인할 것은 삭제 명령어가 아니라 현재 상태입니다.

1. df -h로 어떤 파일시스템이 찼는지 확인하기

가장 먼저 전체 디스크 사용량을 확인합니다.

 

df -h

 

예시 결과입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   32G   18G  64% /
/dev/sda3        30G   27G  3.0G  90% /var
/dev/sdb1       100G   45G   55G  45% /data

 

여기서 중요한 항목은 Use%와 Mounted on입니다.

Use%       : 디스크 사용률
Avail      : 남은 용량
Mounted on : 실제로 연결된 경로

 

위 예시에서는 /가 아니라 /var가 90%입니다.
이 경우 루트 전체를 뒤지기보다 /var 아래를 먼저 확인하는 게 더 안전합니다.

반대로 /가 90% 이상이라면 OS 영역, 로그, 임시파일, 패키지 캐시 등이 함께 영향을 줄 수 있습니다.

 

df -h /
df -h /var
df -h /tmp

 

이렇게 의심되는 경로를 직접 찍어서 확인하면 좋습니다.

2. df -h 결과를 볼 때 초보자가 착각하기 쉬운 부분

Use%만 보고 판단하면 실수할 수 있습니다.

예를 들어 아래 두 상황은 둘 다 90%처럼 보이지만 의미가 다릅니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G   18G  2.0G  90% /
/dev/sdb1       500G  450G   50G  90% /backup

 

둘 다 90%이지만 /가 90%인 것과 /backup이 90%인 것은 위험도가 다릅니다.

/가 차면 OS와 서비스 동작에 직접 영향을 줄 수 있고, /backup이 차면 백업 실패로 이어질 수 있습니다.
그래서 디스크 용량 알림을 받으면 Use%만 보지 말고 Mounted on을 함께 봐야 합니다.

3. du로 어떤 디렉터리가 큰지 확인하기

어떤 파일시스템이 찼는지 확인했다면, 이제 어떤 디렉터리가 용량을 많이 쓰는지 봅니다.

/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/lib와 /var/log가 큽니다.

여기서 중요한 판단은 이것입니다.

/var/log가 크다  → 로그 증가 원인 확인
/var/cache가 크다 → 패키지 캐시 또는 애플리케이션 캐시 확인
/var/spool이 크다 → 메일 큐, 작업 큐 적체 확인
/var/lib가 크다  → 서비스 데이터 가능성이 있어 특히 조심

 

특히 /var/lib는 함부로 삭제하면 안 됩니다.
Docker, containerd, DB, 패키지 상태 정보, 애플리케이션 데이터가 들어 있을 수 있습니다.

4. 루트 경로 전체를 확인할 때 주의할 점

루트 전체에서 큰 디렉터리를 보고 싶을 때는 아래 명령어를 사용할 수 있습니다.

 

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

 

다만 운영 서버에서는 전체 경로를 무리하게 훑으면 부하가 생길 수 있습니다.
가능하면 df -h로 먼저 찬 파일시스템을 찾고, 그 경로만 좁혀서 확인하는 것이 좋습니다.

예를 들어 /data가 찼다면 이렇게 확인합니다.

 

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

 

/backup이 찼다면 이렇게 봅니다.

 

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

 

핵심은 “서버 전체를 무작정 뒤지는 것”이 아니라, 문제가 생긴 마운트 지점부터 좁혀가는 것입니다.

5. find로 큰 파일 찾기

디렉터리 단위로 확인한 뒤에는 큰 파일을 직접 찾을 수 있습니다.

예를 들어 /var/log 아래에서 100MB 이상 파일을 찾으려면 아래처럼 실행합니다.

 

find /var/log -xdev -type f -size +100M -exec ls -lh {} \; 2>/dev/null

 

예시 결과입니다.

-rw-r--r-- 1 root root 1.8G Jul 13 10:20 /var/log/example-app/app.log
-rw-r--r-- 1 root root 900M Jul 13 10:18 /var/log/nginx/access.log

 

이 결과가 나오면 바로 삭제하기보다 먼저 질문해야 합니다.

이 로그는 어떤 서비스 로그인가?
최근 갑자기 커졌는가?
장애 분석에 필요한 로그인가?
logrotate 대상인가?
현재 프로세스가 쓰고 있는 파일인가?
백업 후 정리해야 하는가?

 

큰 파일을 찾는 것은 조치가 아니라 판단을 위한 재료를 모으는 단계입니다.

서버 전체에서 찾고 싶다면 범위를 너무 넓히기보다 주요 경로만 지정하는 편이 좋습니다.

 

find /home /data /backup /var/log -xdev -type f -size +100M -exec ls -lh {} \; 2>/dev/null

 

6. 로그 파일은 삭제보다 비우기가 나을 때가 있음

운영 서버에서 자주 헷갈리는 부분입니다.

로그 파일이 너무 커졌다고 해서 바로 rm으로 삭제하면, 파일 목록에서는 사라졌는데 디스크 용량은 바로 줄지 않는 경우가 있습니다.

프로세스가 해당 로그 파일을 계속 잡고 있으면 이런 일이 생길 수 있습니다.

그래서 서비스가 현재 사용 중인 로그 파일은 삭제보다 내용을 비우는 방식이 더 나을 때가 있습니다.

 

> /var/log/example-app/app.log

 

또는 아래처럼 사용할 수도 있습니다.

 

cat /dev/null > /var/log/example-app/app.log

 

하지만 이 명령어도 바로 실행하면 안 됩니다.

먼저 아래를 확인해야 합니다.

장애 분석에 필요한 로그인지
보관 정책상 백업이 필요한지
현재 장애 원인을 확인한 뒤 비워도 되는지
서비스 담당자나 운영 기준상 허용되는지

 

필요하다면 먼저 백업을 남깁니다.

 

cp -p /var/log/example-app/app.log /var/log/example-app/app.log.bak

 

그 다음 영향 범위를 확인하고 비우는 방식이 더 안전합니다.

7. 삭제했는데도 용량이 줄지 않을 때 lsof 확인하기

파일을 삭제했는데도 df -h 결과가 그대로라면, 프로세스가 이미 삭제된 파일을 계속 잡고 있을 수 있습니다.

이때 확인할 수 있는 명령어입니다.

 

lsof | grep deleted

 

로그 경로만 보고 싶다면 이렇게 좁힐 수 있습니다.

 

lsof | grep deleted | grep /var/log

 

예시 상황입니다.

example-a  12345  appuser  5w  REG  253,0  2147483648  /var/log/example-app/app.log (deleted)

 

이 결과는 대략 이런 뜻입니다.

example-a 프로세스가
이미 삭제된 app.log 파일을
아직 열어둔 상태일 수 있음

 

이 경우에는 해당 프로세스가 파일을 놓아야 용량이 반환될 수 있습니다.
다만 운영 서버에서 프로세스를 재시작하면 서비스 영향이 있을 수 있습니다.

그래서 바로 재시작하지 말고 아래를 확인합니다.

이 프로세스가 어떤 서비스인지
재시작해도 되는 시간대인지
이중화가 되어 있는지
사용자 영향이 있는지
담당자 승인이나 작업 공지가 필요한지

 

8. /tmp와 백업 파일도 함께 확인하기

디스크 용량 부족은 로그만의 문제가 아닐 수 있습니다.

자주 확인하는 경로는 아래와 같습니다.

/var/log
/tmp
/var/tmp
/home
/data
/backup
애플리케이션 로그 경로
배치 작업 결과 경로

 

예를 들어 /backup 아래에 오래된 백업 파일이 쌓였을 수 있습니다.

 

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

 

오래된 파일을 찾을 수도 있습니다.

 

find /backup -xdev -type f -mtime +30 -ls 2>/dev/null | head

 

단, 백업 파일은 보관 정책이 있을 수 있으므로 바로 삭제하면 안 됩니다.
삭제 전에는 보관 기간, 복구 필요성, 최신 백업 여부를 확인해야 합니다.

9. 용량을 확보한 뒤에는 원인을 확인하기

디스크 용량을 일부 확보했다고 끝난 것이 아닙니다.

더 중요한 것은 왜 갑자기 용량이 늘었는지 확인하는 것입니다.

확인할 항목은 다음과 같습니다.

logrotate 설정이 정상인지
특정 애플리케이션 로그가 폭증했는지
같은 에러 로그가 반복되고 있는지
백업 파일이 과도하게 누적됐는지
임시 파일이 정리되지 않았는지
배치 작업이 실패하면서 중간 파일이 남았는지
deleted 파일이 용량을 잡고 있는지

 

특히 로그가 갑자기 커졌다면 단순 디스크 문제가 아닐 수 있습니다.

예를 들어 같은 오류가 반복되면 로그 파일은 빠르게 커질 수 있습니다.

 

tail -n 100 /var/log/example-app/app.log

 

여기서 같은 에러가 계속 반복된다면, 로그 정리보다 애플리케이션 오류 원인 확인이 먼저입니다.

10. 운영자 보고 문장 예시

디스크 용량 부족 상황은 이렇게 정리해서 보고하면 좋습니다.

[디스크 용량 부족 확인]

- 발생 시각: 2026-07-13 10:30
- 대상 서버: web-01
- 증상: /var 파일시스템 사용률 90% 확인
- 확인 내용:
  1) df -h 결과 /var Use% 90%
  2) du -xhd1 /var 결과 /var/log 약 8G 확인
  3) /var/log/example-app/app.log 파일 약 1.8G 확인
  4) lsof deleted 여부 확인 중
- 추정 원인: 애플리케이션 로그 증가 가능성
- 조치 방향: 로그 보관 필요 여부 확인 후 백업 및 정리 검토

 

이렇게 쓰면 단순히 “용량 찼습니다”보다 훨씬 좋습니다.

운영 보고에서는 아래 4가지를 함께 적으면 도움이 됩니다.

어디가 찼는지
무엇이 커졌는지
왜 커진 것으로 보이는지
어떤 조치를 검토 중인지

 

11. 운영 서버에서 바로 하면 위험한 조치

디스크 용량이 부족할 때 아래 명령어는 특히 조심해야 합니다.

 

rm -rf /var/log/*
rm -rf /tmp/*
find / -type f -size +100M -delete
kill -9 <PID>
systemctl restart example-app
reboot

 

이 명령어들이 항상 나쁜 것은 아닙니다.
다만 운영 서버에서는 확인 없이 실행하면 위험합니다.

예를 들어:

rm -rf /var/log/*       → 장애 원인 분석 로그 삭제 가능
rm -rf /tmp/*           → 서비스가 사용하는 임시파일 삭제 가능
find ... -delete        → 조건 실수 시 필요한 파일 삭제 가능
kill -9                 → 데이터 정리 없이 프로세스 강제 종료 가능
restart                 → 사용자 영향 발생 가능
reboot                  → 전체 서비스 중단 가능

 

그래서 삭제, 재기동, 강제 종료는 마지막 단계에 가까워야 합니다.

12. 정리하면

리눅스 서버 디스크 사용률이 90%를 넘었다면 아래 순서로 확인하는 것이 좋습니다.

1. df -h로 어떤 파일시스템이 찼는지 확인
2. Mounted on을 보고 영향 범위 판단
3. du로 큰 디렉터리 확인
4. find로 큰 파일 확인
5. 로그 파일은 삭제 전 백업과 사용 여부 확인
6. lsof로 deleted 파일 확인
7. 용량 확보 후 증가 원인 분석

 

처음부터 파일을 지우는 것보다, 어느 경로가 왜 커졌는지 확인하는 것이 먼저입니다.

디스크 용량 부족은 단순 청소 문제가 아니라 서비스 장애의 신호일 수 있습니다.
특히 로그가 갑자기 커졌다면 애플리케이션 오류, 비정상 요청, 배치 실패 같은 원인이 숨어 있을 수 있습니다.

운영 서버에서는 용량을 줄이는 것만큼 같은 문제가 다시 쌓이지 않게 원인을 찾는 것이 중요합니다.

이번 상황도 결국 순서는 같습니다.

확인 → 판단 → 조치

다만 여기서의 핵심은 “무엇을 지울까”가 아니라, 어느 파일시스템에서 어떤 데이터가 왜 커졌는지 먼저 보는 것입니다.

 

 

df -h 결과만으로 원인을 찾기 어렵다면 du 결과와 비교해서 보는 것이 좋습니다. 특히 파일을 삭제했는데도 용량이 줄지 않는 상황은 “df와 du 결과가 다르게 보이는 이유” 글에서 이어서 정리해두면 좋습니다.

리눅스 서버 df와 du 용량이 다르게 보일 때 삭제된 파일부터 확인하는 법

디스크 용량 문제는 inode 부족, /tmp 용량 증가, /var 로그 증가와 함께 나타나는 경우가 많습니다. 용량은 남아 있는데 파일 생성이 안 된다면 inode 부족 여부도 함께 확인해보는 것이 좋습니다.

리눅스 서버 디스크 용량 남았는데 파일 생성 안 될 때? df -i 명령어로 inode 부족 확인하는 법

 

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

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

 

---