리눅스 서버에서 디스크 용량을 확인할 때 가장 많이 쓰는 명령어는 df -h입니다. 그런데 초보 운영자는 Use% 숫자만 보고 “90%니까 바로 파일을 지워야 하나?”라고 판단하기 쉽습니다. 하지만 서버 운영에서는 같은 90%라도 /가 찬 것인지, /backup이 찬 것인지, 실제 남은 용량인 Avail이 얼마나 되는지에 따라 위험도가 달라집니다. 이번 글에서는 df -h 결과에서 Use%, Avail, Mounted on을 함께 보고 디스크 용량 부족 상황을 안전하게 판단하는 방법을 정리합니다.
df -h는 디스크 용량 확인의 출발점입니다
서버에서 디스크 사용량을 확인할 때 가장 먼저 보는 명령어는 보통 아래 명령어입니다.
df -hdf는 파일시스템 단위로 디스크 사용량을 보여주는 명령어입니다.
여기에 -h 옵션을 붙이면 사람이 읽기 쉬운 단위인 G, M, T 형태로 출력됩니다.
예시 결과입니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 50G 45G 5.0G 90% /
/dev/sdb1 1.0T 900G 100G 90% /backup
/dev/sdc1 200G 160G 40G 80% /data여기서 초보자가 가장 먼저 보는 값은 보통 Use%입니다.
Use%가 90%로 보이면 바로 위험하다고 느낄 수 있습니다.
물론 디스크 사용률은 중요합니다. 하지만 서버 운영에서는 Use% 하나만 보고 바로 조치하면 판단이 틀어질 수 있습니다.
df -h에서 꼭 같이 봐야 할 3가지
df -h 결과에서 우선적으로 봐야 할 항목은 3가지입니다.
Use% : 전체 용량 대비 사용률
Avail : 실제로 사용 가능한 남은 용량
Mounted on : 해당 파일시스템이 연결된 경로이 3가지를 같이 봐야 “얼마나 찼는지”뿐 아니라 “어디가 찼고, 얼마나 위험한지”를 판단할 수 있습니다.
간단히 정리하면 이렇게 볼 수 있습니다.
Use% → 얼마나 찼는가?
Avail → 실제로 얼마나 남았는가?
Mounted on → 어디가 찼는가?이 중 하나만 보면 반쪽짜리 판단이 됩니다.
초보자가 흔히 하는 실수: Use%만 보고 바로 삭제하기
디스크 사용률이 90%라고 보이면 이런 생각이 들 수 있습니다.
90%면 위험한가?
큰 파일부터 지워야 하나?
로그 파일을 바로 삭제해야 하나?
백업 파일을 지워도 되나?하지만 운영 서버에서는 아래와 같은 명령어를 바로 실행하면 위험할 수 있습니다.
rm -rf /var/log/*
rm -rf /tmp/*
find / -type f -size +100M -delete이 명령어들이 항상 잘못된 것은 아닙니다.
문제는 어디가 찼는지 확인하지 않고 바로 삭제하는 것입니다.
예를 들어 /backup이 찼는데 /var/log를 지우면 문제 해결과 관계가 없을 수 있습니다.
반대로 /var가 찼는데 백업 파일만 보다가 로그 폭증 원인을 놓칠 수도 있습니다.
그래서 df -h에서는 먼저 Mounted on을 봐야 합니다.
같은 90%라도 의미는 다릅니다
아래 두 결과를 비교해보겠습니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 1.0T 900G 100G 90% /backup
/dev/sda2 50G 45G 5.0G 90% /둘 다 Use%는 90%입니다.
하지만 운영 관점에서 의미는 다릅니다.
/backup 90% → 백업 실패 가능성 점검
/ 90% → OS 영역 부족 가능성 점검/backup이 90%라면 당장 서비스가 멈춘다고 단정하기는 어렵습니다.
하지만 다음 백업이 실패할 가능성이 있으므로 보관 주기, 오래된 백업 파일, 최근 백업 파일 크기 증가 여부를 확인해야 합니다.
반대로 /가 90%라면 더 신중하게 봐야 합니다.
/는 루트 영역이고, OS와 기본 시스템 파일, 일부 로그와 임시파일이 연결될 수 있습니다. 이 영역이 부족해지면 서버 전체 동작에 영향을 줄 수 있습니다.
/backup 영역이 90%인 경우
예를 들어 아래처럼 /backup 영역이 90%라고 가정해보겠습니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 1.0T 900G 100G 90% /backup이 경우 먼저 확인할 것은 “서비스가 지금 바로 죽느냐”보다 “백업 운영에 문제가 생길 가능성이 있느냐”입니다.
확인할 항목은 다음과 같습니다.
오래된 백업 파일이 누적됐는지
백업 보관 주기가 적절한지
최근 백업 파일 크기가 갑자기 커졌는지
다음 백업 수행에 필요한 여유 공간이 충분한지
백업 실패 로그가 있는지예를 들어 /backup 아래를 확인할 때는 이렇게 볼 수 있습니다.
du -xhd1 /backup 2>/dev/null | sort -h오래된 백업 파일 후보를 볼 수도 있습니다.
find /backup -xdev -type f -mtime +30 -ls 2>/dev/null | head단, 백업 파일은 보관 정책이 있을 수 있습니다.
오래됐다고 바로 삭제하지 말고 보관 기간, 복구 필요성, 최신 백업 여부를 확인해야 합니다.
/ 영역이 90%인 경우
반대로 / 영역이 90%라면 더 조심해야 합니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 50G 45G 5.0G 90% //는 루트 영역입니다.
이 영역이 부족하면 서버 전체 동작에 영향을 줄 수 있습니다.
예를 들어 아래와 같은 문제가 생길 수 있습니다.
임시파일 생성 실패
로그 기록 실패
패키지 설치 또는 업데이트 실패
서비스 프로세스 오류
배포 작업 실패
애플리케이션 장애 가능성 증가이때는 단순히 큰 파일을 찾기 전에 /var, /tmp, /home, /root, 패키지 캐시 등을 나누어 확인해야 합니다.
du -xhd1 / 2>/dev/null | sort -h다만 운영 서버에서는 루트 전체를 무리하게 훑는 것이 부담이 될 수 있습니다.
가능하면 df -h로 문제 파일시스템을 확인한 뒤 의심 경로를 좁혀 확인하는 습관이 좋습니다.
/var 영역이 90%인 경우
/var가 90%라면 로그나 서비스 데이터 증가를 의심할 수 있습니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 30G 27G 3.0G 90% /var/var 아래에는 보통 이런 데이터가 쌓일 수 있습니다.
/var/log → 시스템 로그, 서비스 로그
/var/cache → 패키지 캐시, 애플리케이션 캐시
/var/spool → 메일 큐, 작업 큐
/var/lib → 서비스 데이터, 컨테이너 데이터, DB성 데이터그래서 /var가 찼다고 해서 바로 /var/log만 보면 부족할 수 있습니다.
아래처럼 먼저 큰 경로를 나눠서 확인합니다.
du -xhd1 /var 2>/dev/null | sort -h예시입니다.
500M /var/cache
1.5G /var/spool
8.0G /var/log
15G /var/lib
25G /var이 결과라면 /var/log도 크지만 /var/lib가 더 큽니다.
/var/lib는 서비스 데이터가 들어 있을 수 있으므로 특히 조심해야 합니다.
이런 식으로 Mounted on을 보고 어느 영역이 찼는지 확인해야 다음 명령어의 방향이 정해집니다.
Avail도 같이 봐야 하는 이유
Avail은 실제로 사용 가능한 남은 용량입니다.
같은 90%라도 남은 용량은 크게 다를 수 있습니다.
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 50G 45G 5.0G 90% /
/dev/sdb1 1.0T 900G 100G 90% /backup둘 다 90%지만 남은 용량은 다릅니다.
/ → 5GB 남음
/backup → 100GB 남음/에 5GB만 남은 상황과 /backup에 100GB가 남은 상황은 대응 우선순위가 다릅니다.
물론 /backup도 90%라면 점검이 필요합니다.
하지만 당장 서버 동작에 직접 영향을 줄 가능성은 /의 90%가 더 클 수 있습니다.
그래서 df -h 결과를 볼 때는 아래 순서로 생각하면 좋습니다.
1. Use%로 사용률 확인
2. Mounted on으로 위치 확인
3. Avail로 긴급도 판단df와 du의 역할은 다릅니다
여기서 헷갈리기 쉬운 부분이 있습니다.
df -h와 du는 둘 다 용량을 보는 명령어지만 역할이 다릅니다.
df -h → 파일시스템 단위로 어디가 찼는지 확인
du → 특정 경로 안에서 무엇이 큰지 확인즉, df -h는 지도에서 어느 구역에 불이 났는지 보는 것이고, du는 그 구역 안에서 어느 방이 타고 있는지 확인하는 느낌입니다.
먼저 df -h로 위치를 확인하고, 그다음 du로 원인을 좁히는 순서가 안전합니다.
예를 들어 /var가 문제라면:
du -xhd1 /var 2>/dev/null | sort -h/backup이 문제라면:
du -xhd1 /backup 2>/dev/null | sort -h/data가 문제라면:
du -xhd1 /data 2>/dev/null | sort -h이렇게 문제 경로를 좁혀서 확인하면 불필요한 부하도 줄이고, 판단도 빨라집니다.
실무에서 확인하는 순서
서버 용량 알림이 발생했을 때는 아래 순서로 확인하면 좋습니다.
1단계. df -h로 전체 현황 확인
df -h먼저 전체 파일시스템의 사용률을 확인합니다.
이때 Use%만 보는 것이 아니라 Avail, Mounted on을 같이 봅니다.
2단계. Use%가 높은 항목 확인
사용률이 높은 항목을 찾습니다.
보통 80% 이상이면 주의, 90% 이상이면 점검이 필요한 상태로 볼 수 있습니다.
다만 이 기준은 운영 환경과 서비스 특성에 따라 달라질 수 있습니다.
예를 들어 로그가 빠르게 쌓이는 서비스라면 85%도 위험할 수 있고, 백업 영역처럼 계획적으로 관리되는 영역이라면 보관 정책에 따라 판단이 달라질 수 있습니다.
3단계. Mounted on으로 영향도 판단
어떤 경로가 찼는지 확인합니다.
/ → OS 영역
/var → 로그 또는 서비스 데이터
/tmp → 임시파일
/data → 애플리케이션 데이터
/backup → 백업 파일
/home → 사용자 파일같은 90%라도 어느 경로인지에 따라 조치 방향이 달라집니다.
4단계. Avail로 긴급도 판단
남은 용량이 얼마나 되는지 확인합니다.
남은 용량이 매우 적음 → 빠른 원인 확인과 조치 필요
남은 용량이 어느 정도 있음 → 원인 분석 후 정리 계획 수립
남은 용량은 많지만 Use%가 높음 → 증가 추세와 다음 작업 영향 확인예를 들어 /backup에 100GB가 남아 있어도 다음 백업이 150GB라면 문제가 될 수 있습니다.
반대로 /에 5GB만 남았다면 로그 폭증이나 임시파일 증가에 따라 빠르게 위험해질 수 있습니다.
5단계. du로 세부 경로 추적
어느 마운트 경로가 문제인지 확인했다면 du 명령어로 어떤 디렉터리가 큰지 확인합니다.
du -xhd1 /var 2>/dev/null | sort -h또는:
du -xhd1 /backup 2>/dev/null | sort -h이렇게 df -h로 전체 위치를 확인하고, du로 세부 원인을 좁혀가는 방식이 좋습니다.
운영자 보고 문장 예시
df -h 결과를 보고 운영 보고를 해야 한다면 아래처럼 정리할 수 있습니다.
[디스크 용량 확인]
- 발생 시각: 2026-07-13 11:00
- 대상 서버: web-01
- 확인 명령어: df -h
- 확인 결과:
1) / 파일시스템 Use% 90%, Avail 5.0G 확인
2) /backup 파일시스템 Use% 90%, Avail 100G 확인
3) 동일한 90%지만 / 영역의 긴급도가 더 높은 것으로 판단
- 조치 방향:
/ 영역 기준으로 du 명령어를 통해 세부 경로 확인 예정이렇게 보고하면 단순히 “디스크 90%입니다”보다 훨씬 명확합니다.
운영 보고에서는 아래 3가지를 함께 쓰면 좋습니다.
얼마나 찼는지
어디가 찼는지
실제로 얼마나 남았는지이 3가지가 있어야 다음 사람이 봐도 상황을 판단하기 쉽습니다.
df -h 결과를 볼 때 기억할 것
df -h 결과를 볼 때는 아래처럼 기억하면 쉽습니다.
Use% : 얼마나 찼는가?
Avail : 얼마나 버틸 수 있는가?
Mounted on : 어디가 아픈 것인가?특히 Mounted on은 장애 범위를 판단하는 데 중요합니다.
같은 90%라도 의미가 다릅니다.
/backup 90% → 백업 실패 가능성 점검
/data 90% → 애플리케이션 데이터 증가 확인
/var 90% → 로그 또는 서비스 데이터 증가 확인
/ 90% → OS 영역 부족 가능성으로 신중히 확인이 차이를 모르면 엉뚱한 경로를 정리하거나, 정말 위험한 영역을 늦게 발견할 수 있습니다.
바로 하면 위험한 조치
df -h에서 90%가 보인다고 바로 아래 명령어를 실행하면 위험할 수 있습니다.
rm -rf /tmp/*
rm -rf /var/log/*
find / -type f -size +100M -delete
systemctl restart example-app
reboot특히 find ... -delete는 조건을 잘못 잡으면 필요한 파일까지 삭제할 수 있습니다.
삭제나 재기동은 마지막 단계에 가까워야 합니다.
먼저 확인해야 할 것은 아래입니다.
어느 파일시스템이 찼는가?
남은 용량은 얼마인가?
서비스 영향이 큰 경로인가?
du로 확인했을 때 어떤 디렉터리가 큰가?
해당 파일은 삭제해도 되는가?
현재 프로세스가 사용 중인 파일은 아닌가?운영 서버에서는 빠른 조치보다 안전한 판단이 더 중요합니다.
정리
df -h는 리눅스 서버 디스크 용량을 확인할 때 가장 기본이 되는 명령어입니다.
하지만 Use%만 보면 정확한 판단을 하기 어렵습니다.
반드시 아래 3가지를 같이 봐야 합니다.
1. Use% → 얼마나 찼는지
2. Avail → 실제로 얼마나 남았는지
3. Mounted on → 어느 경로가 찼는지디스크 용량 알림이 왔을 때 중요한 것은 “90%냐 아니냐”만 보는 것이 아닙니다.
그 90%가 /인지, /var인지, /backup인지에 따라 대응 우선순위가 달라집니다.
그리고 어느 파일시스템이 찼는지 확인했다면, 그다음은 du로 세부 경로를 좁혀가야 합니다.
df -h
du -xhd1 /var 2>/dev/null | sort -h서버 운영에서 숫자는 시작점이고, 판단은 그 숫자가 발생한 위치를 해석하는 데서 시작됩니다.
디스크 사용률이 높게 보일수록 바로 삭제하기보다 Use%, Avail, Mounted on을 함께 보고 영향 범위를 판단하는 습관이 필요합니다.
df -h 결과에서 Use%만 보고 판단하기 어렵다면, 먼저 전체 디스크 점검 순서를 함께 보는 것이 좋습니다. 아래 글에서 디스크 용량 90% 이상일 때 확인하는 전체 흐름을 정리했습니다.
리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법
리눅스 서버를 운영하다 보면 디스크 용량 90% 이상 사용 중 같은 알림을 받을 때가 있습니다. 이때 바로 파일을 삭제하면 로그 분석에 필요한 파일을 지우거나, 서비스가 사용 중인 파일을 잘못
opsnote.tistory.com
리눅스 서버 df와 du 용량이 다르게 보일 때 삭제된 파일부터 확인하는 법
리눅스 서버에서 디스크 용량을 확인하다 보면 df -h에서는 사용량이 높은데, du -sh로 디렉터리를 확인하면 큰 파일이 잘 보이지 않는 경우가 있습니다. 서버 운영 중 이런 상황은 삭제됐지만 프
opsnote.tistory.com
디스크 용량 문제를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/70
리눅스 서버 디스크 용량 문제 확인 순서 총정리
리눅스 서버를 운영하다 보면 디스크 용량 문제는 생각보다 자주 만납니다.처음에는 단순해 보입니다.디스크가 찼다.공간이 부족하다.큰 파일을 지우면 된다. 하지만 운영 서버에서는 이렇게
opsnote.tistory.com
'리눅스' 카테고리의 다른 글
| 리눅스 서버 /var/log 용량이 갑자기 커졌을 때 확인하는 법 (0) | 2026.05.06 |
|---|---|
| 리눅스에서 파일 삭제했는데 용량이 안 줄어들 때 lsof로 확인하는 법 (0) | 2026.05.05 |
| 리눅스 서버 디스크 용량을 잡아먹는 큰 파일 find 명령어로 찾는 법 (0) | 2026.05.05 |
| 리눅스 서버 디스크 용량이 찼을 때 du -sh로 큰 폴더 찾는 법 (0) | 2026.05.03 |
| 리눅스 서버 디스크 용량 90% 넘었을 때 바로 삭제하지 말고 확인하는 법 (0) | 2026.05.02 |