리눅스 서버 디스크 용량 90% 알림을 받았을 때 실제 점검 흐름 정리

리눅스 서버 디스크 용량 90% 알림을 받았을 때 df -h, du, find, df -i, deleted 파일 확인 순서와 조치 전 영향도 확인 흐름을 설명하는 이미지

리눅스 서버를 운영하다 보면 디스크 용량 알림을 받을 때가 있습니다.

처음에는 단순하게 보입니다.

디스크가 90%를 넘었다.
공간이 부족하다.
큰 파일 몇 개만 지우면 되지 않을까?

저도 처음에는 이렇게 생각했습니다.
그런데 운영 서버에서는 디스크 용량 알림을 단순한 청소 문제로 보면 위험할 수 있습니다.

디스크가 찼다고 바로 파일을 삭제하면 장애 원인을 확인할 로그를 지워버릴 수 있고, 서비스가 아직 사용 중인 파일을 건드릴 수도 있습니다.

특히 /var, /tmp, /data, 애플리케이션 로그 경로, 백업 경로는 각각 성격이 다르기 때문에 같은 방식으로 판단하면 안 됩니다.

이번 글에서는 리눅스 서버에서 디스크 용량 90% 알림을 받았을 때, 실제 운영 상황에서 어떤 순서로 확인하면 좋은지 정리해보겠습니다.

핵심은 단순합니다.

디스크가 찼다면, 지우기 전에 먼저 어디가 왜 찼는지 확인해야 합니다.

운영 서버에서는 항상 확인 → 판단 → 조치 → 재확인 순서가 먼저입니다.

---

1. 먼저 알림 내용을 확인합니다

디스크 용량 알림을 받으면 가장 먼저 알림 내용을 다시 봅니다.

이때 중요한 것은 사용률 숫자만 보는 것이 아닙니다.
90%라는 숫자보다 더 중요한 것은 어느 파일시스템이 찼는지입니다.

보통 알림에는 아래 정보가 들어 있습니다.

• 서버명
• 파일시스템
• 사용률
• 마운트 경로
• 알림 발생 시간

여기서 가장 먼저 볼 항목은 마운트 경로입니다.

같은 90%라도 /가 찬 것과 /var가 찬 것, /tmp가 찬 것, /data가 찬 것은 전혀 다른 문제일 수 있습니다.

• / : OS 전체 영향 가능성
• /var : 로그, 캐시, 패키지, 서비스 데이터 영향 가능성
• /tmp : 업로드, 압축 해제, 배치 작업, 임시 파일 영향 가능성
• /data : 애플리케이션 데이터나 사용자 업로드 파일 영향 가능성

그래서 처음 판단은 이렇게 잡는 것이 좋습니다.

디스크가 찼다.
그러면 어느 마운트가 찼는지 먼저 확인한다.

 

---

2. df -h로 전체 파일시스템을 봅니다

가장 먼저 확인할 명령어는 df -h입니다.

 

df -h

 

이 명령어로 전체 파일시스템의 사용률을 확인합니다.

여기서 Use%만 보면 안 됩니다.
Size, Used, Avail, Mounted on을 같이 봐야 합니다.

특히 Mounted on이 중요합니다.
같은 90%라도 어느 경로가 찼는지에 따라 판단이 완전히 달라집니다.

예를 들어 /var가 92%라면 로그나 캐시를 먼저 의심할 수 있습니다.
/tmp가 100%라면 임시 파일이나 배치 작업을 볼 수 있습니다.
/data가 찼다면 업로드 파일, 백업 파일, 애플리케이션 데이터 증가를 확인해야 할 수 있습니다.

df -h를 볼 때는 아래처럼 생각하면 좋습니다.

• 어느 경로가 찼는가?
• 남은 용량은 어느 정도인가?
• 증가 속도가 빠른가?
• 서비스 영향이 있는 경로인가?

df -h 결과를 볼 때 Use%만 보면 안 되는 이유는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/2

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

 

디스크 용량 90% 알림을 받았을 때 기본 확인 순서는 아래 글도 함께 보면 좋습니다.

https://opsnote.tistory.com/1

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

 

---

3. 바로 삭제하지 말고 큰 폴더부터 찾습니다

어느 마운트가 찼는지 확인했다면, 다음은 그 안에서 어떤 폴더가 큰지 확인합니다.

예를 들어 /var가 찼다고 해서 바로 /var/log 파일을 지우면 안 됩니다.
먼저 /var 아래에서 어떤 폴더가 큰지 봐야 합니다.

 

du -sh /var/* 2>/dev/null | sort -rh | head

 

문제가 되는 경로로 이동해서 볼 수도 있습니다.

 

cd /var
du -sh * 2>/dev/null | sort -rh | head

 

이 과정의 목적은 삭제할 파일을 바로 찾는 것이 아닙니다.

용량을 차지하는 위치를 좁히는 것입니다.

흐름은 이렇게 잡습니다.

df -h로 찬 마운트를 확인합니다.
du로 큰 폴더를 확인합니다.
큰 폴더 안으로 들어가서 다시 du로 확인합니다.
마지막에 실제 파일을 확인합니다.

 

큰 폴더를 찾는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/3

리눅스 서버 디스크 용량이 찼을 때 du -sh로 큰 폴더 찾는 법

 

---

4. 큰 파일인지, 작은 파일이 많이 쌓인 것인지 나눕니다

큰 폴더를 찾았다면 그다음은 원인을 조금 더 나눠야 합니다.

디스크가 찬 이유는 크게 두 가지일 때가 많습니다.

• 큰 파일 몇 개가 용량을 차지하는 경우
• 작은 파일이 너무 많이 쌓인 경우

큰 파일을 찾을 때는 find 명령어를 사용할 수 있습니다.

 

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

 

로그 파일 하나가 몇 GB까지 커졌다면 애플리케이션 오류가 반복되고 있을 수 있습니다.

반대로 작은 파일이 수십만 개 쌓였다면 용량보다 inode 문제가 먼저 나타날 수도 있습니다.

큰 파일을 찾는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/4

리눅스 서버 디스크 용량을 잡아먹는 큰 파일 find 명령어로 찾는 법

 

---

5. df와 du 결과가 다르면 deleted 파일을 의심합니다

운영 중에는 df -h와 du 결과가 맞지 않는 경우가 있습니다.

df -h에서는 용량이 많이 찼다고 나오는데, du로 찾아보면 그만큼 큰 파일이 보이지 않을 때가 있습니다.

이럴 때는 deleted 파일을 의심해야 합니다.

파일은 삭제됐지만, 어떤 프로세스가 아직 그 파일을 잡고 있으면 디스크 공간이 바로 반환되지 않을 수 있습니다.

확인은 이렇게 합니다.

 

lsof | grep deleted

 

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

 

lsof | grep deleted | grep /var

 

이 상황에서 무작정 다른 파일을 지우면 원인을 더 놓칠 수 있습니다.

실제로 공간을 잡고 있는 것은 이미 삭제된 로그 파일일 수도 있기 때문입니다.

df와 du 결과가 다르게 보일 때 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/65

---

6. 용량은 남았는데 파일 생성이 안 되면 inode를 확인합니다

디스크 문제는 용량만의 문제가 아닐 수 있습니다.

df -h에서는 용량이 남아 있는데, 파일 생성이 안 되거나 No space left on device 오류가 나는 경우가 있습니다.

이때는 inode를 확인해야 합니다.

 

df -i

 

inode는 파일을 만들 수 있는 자리표에 가깝습니다.

용량이 남아 있어도 inode가 다 차면 새 파일을 만들 수 없습니다.

이 문제는 작은 파일이 많이 쌓이는 경로에서 자주 발생합니다.

• 세션 파일
• 캐시 파일
• 임시 파일
• 작은 로그 파일
• 업로드 임시 파일

용량은 남았는데 파일 생성이 안 될 때 inode를 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/66

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

 

---

7. /tmp는 이름만 보고 가볍게 보면 안 됩니다

디스크 용량 문제에서 /tmp는 자주 등장합니다.

이름이 임시 폴더라서 쉽게 지워도 될 것처럼 보입니다.
하지만 운영 서버에서는 현재 프로세스가 /tmp 안의 파일을 사용 중일 수 있습니다.

예를 들어 이런 경우가 있습니다.

• 파일 업로드 중 임시 저장
• 압축 해제 중 임시 파일 생성
• 배치 작업 중 임시 결과 저장
• 애플리케이션이 임시 파일 사용

그래서 /tmp가 찼을 때도 바로 삭제하지 말고 먼저 확인해야 합니다.

 

du -sh /tmp/* 2>/dev/null | sort -rh | head
find /tmp -xdev -type f -mmin -60 | head
lsof | grep /tmp

 

중요한 것은 오래된 파일인지, 지금 사용 중인 파일인지, 정리 정책이 있는지 나누는 것입니다.

/tmp 용량이 찼을 때 확인하는 순서는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법

 

---

8. /var는 더 조심해서 봅니다

/var는 운영 서버에서 특히 조심해야 하는 경로입니다.

/var 아래에는 여러 성격의 데이터가 섞여 있습니다.

/var/log
/var/cache
/var/spool
/var/lib

 

/var/log는 로그가 쌓이는 경로입니다.
/var/cache는 캐시 데이터가 있을 수 있습니다.
/var/lib는 서비스 데이터가 들어가는 경우가 많아서 함부로 지우면 위험합니다.

그래서 /var가 찼을 때는 이렇게 나눠서 봐야 합니다.

• 로그가 커진 것인지
• 캐시가 쌓인 것인지
• 서비스 데이터가 증가한 것인지
• 패키지 관련 파일인지
• 현재 서비스가 사용하는 파일인지

/var 용량 문제를 안전하게 보는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/68

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

 

---

9. 조치 전에 영향도를 먼저 봅니다

어느 정도 원인을 찾았다면 다음은 조치입니다.

하지만 운영 서버에서는 조치도 바로 들어가면 안 됩니다.

삭제, 비우기, 이동, 압축, 재기동은 모두 영향이 있을 수 있습니다.

조치 전에는 최소한 아래를 확인해야 합니다.

• 이 파일을 삭제해도 되는가?
• 현재 서비스가 사용 중인가?
• 로그 분석에 필요한 파일인가?
• 백업 대상인가?
• 보관 정책이 있는가?
• 삭제보다 압축이나 이동이 나은가?
• 서비스 재기동이 필요한가?
• 원복 방법은 있는가?

특히 아래 작업은 운영 영향이 생길 수 있습니다.

rm
truncate
logrotate 강제 실행
서비스 restart
프로세스 kill

 

그래서 조치 전에는 이렇게 정리해두면 좋습니다.

확인된 사실:
어떤 파일시스템이 몇 %까지 찼는지

추정 원인:
어떤 경로나 파일이 증가했는지

조치 계획:
삭제, 이동, 압축, 로그 정리, 서비스 재기동 여부

영향 범위:
서비스 중단 가능성, 로그 유실 가능성, 재발 가능성

원복 방법:
백업 위치, 이동 경로, 변경 전 상태

 

---

10. 조치 후에는 다시 확인합니다

디스크 조치가 끝났다고 바로 완료라고 보면 안 됩니다.

반드시 다시 확인해야 합니다.

 

df -h
df -i

 

서비스 로그도 함께 확인합니다.

 

journalctl -u 서비스명 -n 100 --no-pager

 

웹 서비스라면 간단한 응답도 확인합니다.

 

curl -I http://localhost

 

조치 후에는 아래를 봅니다.

• 사용률이 실제로 내려갔는가?
• inode 사용률도 정상인가?
• 서비스 에러가 새로 발생하지 않는가?
• 로그가 다시 빠르게 증가하지 않는가?
• 같은 알림이 반복되지 않는가?

디스크 문제는 지웠다는 사실보다 다시 쌓이지 않는지 확인하는 것이 더 중요합니다.

---

11. 같은 디스크 90% 알림이어도 원인은 다를 수 있다

운영 중인 리눅스 서버에서 디스크 사용률이 90%를 넘었다는 알림을 받았다고 가정해 보겠습니다.

처음에는 공간이 부족하다는 사실만 확인할 수 있습니다. 실제로 어떤 파일이 증가했는지, 왜 사용률이 높아졌는지는 아직 알 수 없습니다.

그래서 먼저 파일시스템 사용률부터 확인합니다.

df -h

예를 들어 /var 파일시스템의 사용률이 92%라고 해보겠습니다.

이때 바로 로그 파일을 삭제하기보다는 어떤 경로에서 공간을 사용하고 있는지 확인합니다.

du -xhd1 /var 2>/dev/null

-x 옵션은 다른 파일시스템으로 넘어가지 않고 현재 파일시스템 안에서 사용량을 확인할 때 유용합니다.

다만 디렉터리의 파일을 읽으며 사용량을 계산하므로 파일이 매우 많은 운영 서버에서는 디스크 I/O 부하가 발생할 수 있습니다.

이후에는 확인 결과에 따라 점검 방향이 달라집니다.

1. 로그 파일이 계속 증가하는 경우

/var/log의 사용량이 크고 특정 로그 파일이 계속 증가하고 있다면, 로그 발생량과 보관 정책을 확인합니다.

이때 중요한 것은 해당 파일이 현재 서비스에서 사용 중인지 확인하는 것입니다.

로그 파일이 크다고 해서 무조건 삭제하면 안 됩니다. 장애 원인을 확인하는 데 필요한 기록일 수도 있기 때문입니다.

저는 이런 경우 로그가 갑자기 증가한 시각과 애플리케이션에서 오류가 발생한 시각이 비슷한지 먼저 비교합니다.

2. df와 du의 사용량이 크게 다른 경우

df -h에서는 디스크 사용률이 높은데, du로 확인한 파일 사용량의 합계는 생각보다 적을 수 있습니다.

이때는 삭제된 파일을 프로세스가 계속 열고 있는 상황인지 확인해 볼 수 있습니다.

lsof +L1

파일을 삭제했더라도 프로세스가 해당 파일을 계속 열고 있으면 디스크 공간이 즉시 반환되지 않을 수 있습니다.

다만 df와 du의 차이가 항상 삭제된 파일 때문인 것은 아닙니다. 파일시스템의 예약 공간이나 메타데이터 등 다른 원인도 있을 수 있습니다.

또한 lsof +L1은 서버 전체 프로세스를 확인하므로 규모가 큰 환경에서는 실행 비용을 고려해야 합니다.

주의할 점은 여기서 바로 프로세스를 종료하거나 서비스를 재시작하지 않는 것입니다.

해당 프로세스가 어떤 서비스를 담당하는지, 재시작하면 영향이 있는지 확인한 후 조치 여부를 결정해야 합니다.

3. 디스크 용량은 남았는데 파일 생성이 안 되는 경우

디스크 공간뿐 아니라 inode가 부족한 상황일 수도 있습니다.

이럴 때는 다음 명령으로 확인합니다.

df -i

inode 사용률이 100%라면 디스크 공간이 남아 있어도 새 파일을 만들지 못할 수 있습니다.

특히 작은 파일이 매우 많이 생성되는 환경에서는 사용 용량보다 inode가 먼저 부족해질 수 있습니다.

이 경우에도 파일을 무작정 삭제하기보다 어떤 경로에서 파일 수가 증가했는지 확인해야 합니다.

점검 결과에 따라 다음 행동을 결정한다

세 가지 상황을 정리하면 다음과 같습니다.

확인 결과의심할 수 있는 원인다음 확인

/var/log 사용량 증가	로그 급증 또는 보관 정책	로그 증가 시각과 서비스 오류
df와 du 사용량 차이	삭제 후 열린 파일 등	lsof +L1 결과
inode 사용률 100%	작은 파일 대량 생성	파일 생성 경로와 개수

같은 디스크 90% 알림이라도 확인 결과에 따라 원인과 조치 방법은 달라질 수 있습니다.

제가 운영하면서 중요하게 생각하는 순서는 다음과 같습니다.

디스크 알림 확인
→ 사용률이 높은 파일시스템 확인
→ 실제 사용 경로 확인
→ 점검 결과에 따라 원인 분기
→ 서비스 영향도 확인
→ 조치 후 재확인

결국 중요한 것은 디스크 사용률을 일시적으로 낮추는 것보다 왜 사용률이 올라갔는지 확인하고, 같은 문제가 반복되지 않도록 하는 것입니다.

 

12. 보고는 짧고 정확하게 남깁니다

디스크 용량 문제를 확인한 뒤에는 보고도 남겨야 합니다.

보고는 길게 쓰기보다, 확인한 사실과 조치 내용을 나눠서 쓰는 것이 좋습니다.

예시는 이렇게 정리할 수 있습니다.

[현상]
서버 디스크 사용률 90% 이상 알림 발생

[확인]
df -h 확인 결과 /var 파일시스템 사용률 92% 확인
du 확인 결과 /var/log/example-app 경로의 로그 파일 증가 확인
lsof deleted 확인 결과 삭제 상태로 점유 중인 파일은 확인되지 않음

[조치]
담당 서비스 로그 보관 정책 확인 후 오래된 로그 압축 및 정리
서비스 영향 없음

[결과]
df -h 재확인 결과 사용률 92%에서 76%로 감소
서비스 상태 및 최근 로그 정상 확인

[추가 확인]
로그 증가 원인 분석 및 logrotate 설정 점검 예정

 

이렇게 쓰면 보는 사람도 상황을 빠르게 이해할 수 있습니다.

단순히 “디스크 찼습니다. 정리했습니다.”라고 쓰는 것보다 훨씬 낫습니다.

---

 

13. 정리하면

리눅스 서버에서 디스크 용량 90% 알림을 받았을 때 가장 위험한 대응은 바로 삭제하는 것입니다.

운영 서버에서는 먼저 확인해야 합니다.

1. df -h로 어느 마운트가 찼는지 확인합니다.
2. du로 큰 폴더를 확인합니다.
3. find로 큰 파일을 확인합니다.
4. df와 du가 다르면 deleted 파일을 확인합니다.
5. 용량은 남았는데 파일 생성이 안 되면 df -i를 확인합니다.
6. /tmp와 /var는 경로 성격을 나눠서 확인합니다.
7. 조치 전 영향도를 확인합니다.
8. 조치 후 df -h, df -i, 서비스 상태를 다시 확인합니다.

초보 운영자라면 이 문장만 기억해도 좋습니다.

디스크가 찼다면, 지우기 전에 먼저 어디가 왜 찼는지 확인하세요.

디스크 문제도 결국 같습니다.

확인 → 판단 → 조치 → 재확인

 

디스크 용량 문제를 명령어별로 더 자세히 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/70

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

 

df -h, du, find, df -i, deleted 파일 확인 흐름을 따로 보고 싶다면 아래 글들도 이어서 볼 수 있습니다.

https://opsnote.tistory.com/2

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

 

https://opsnote.tistory.com/3

리눅스 서버 디스크 용량이 찼을 때 du -sh로 큰 폴더 찾는 법

 

https://opsnote.tistory.com/4

리눅스 서버 디스크 용량을 잡아먹는 큰 파일 find 명령어로 찾는 법

 

https://opsnote.tistory.com/65

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

 

https://opsnote.tistory.com/66

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

 

https://opsnote.tistory.com/67

리눅스 서버 /tmp 용량이 찼을 때 바로 삭제하지 말고 확인하는 법

 

https://opsnote.tistory.com/68

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