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

리눅스 서버에서 df와 du 결과가 다르게 보일 때 deleted 파일, 마운트 지점, 권한 문제를 확인하고 바로 삭제나 재기동하지 않는 방법을 설명하는 대표 이미지

리눅스 서버에서 디스크 용량을 확인하다 보면 df -h에서는 사용량이 높은데, du로 디렉터리를 확인하면 큰 파일이 잘 보이지 않는 경우가 있습니다. 이럴 때 초보 운영자는 “파일을 더 지워야 하나?”, “서버를 재기동해야 하나?”라고 생각하기 쉽지만, 바로 삭제하거나 재기동하면 장애 원인 분석에 필요한 로그를 잃거나 서비스 영향이 커질 수 있습니다. df와 du 결과가 다르게 보일 때는 deleted 파일, 마운트 지점, 숨김 파일, 권한 문제, 확인 범위를 순서대로 확인해야 합니다.

df와 du는 보는 기준이 다릅니다

먼저 df와 du는 둘 다 디스크 용량을 확인할 때 쓰지만, 보는 기준이 다릅니다.

df → 파일시스템 전체 사용량 확인
du → 특정 디렉터리와 파일 기준 사용량 확인

 

쉽게 말하면 df -h는 파일시스템 전체가 얼마나 찼는지 보는 명령어이고, du는 특정 경로 안에서 보이는 파일과 디렉터리의 용량을 계산하는 명령어입니다.

예를 들어 df -h를 실행하면 파일시스템 단위로 사용량이 보입니다.

 

df -h

 

예시입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   45G  5.0G  90% /

 

반면 /var 아래에서 어떤 디렉터리가 큰지 보려면 du를 사용합니다.

 

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

 

즉, df는 “어느 파일시스템이 찼는지”를 보는 출발점이고, du는 “그 안에서 무엇이 큰지”를 좁혀가는 도구입니다.

 

디스크 용량 문제를 처음 확인하는 순서가 헷갈린다면, 먼저 전체 점검 흐름을 잡는 것이 좋습니다. 아래 글에서 디스크 사용률이 90%를 넘었을 때 바로 삭제하지 않고 확인하는 순서를 정리했습니다.

 

 

가상의 운영 상황 예시

예를 들어 서버에서 아래와 같은 상황이 발생했다고 가정해보겠습니다.

[상황]
- df -h 결과: / 파일시스템 90% 사용 중
- du -xhd1 / 결과: 눈에 띄게 큰 디렉터리가 보이지 않음
- 최근 큰 로그 파일을 삭제한 이력이 있음
- 서비스는 계속 실행 중

 

이 경우 초보자는 이렇게 생각할 수 있습니다.

분명히 파일을 지웠는데 왜 df 용량이 그대로지?
du로 보면 큰 파일이 없는데 왜 /는 90%지?
서버를 재기동하면 해결되는 건가?

 

하지만 이때 바로 재기동하거나 파일을 더 삭제하기보다, 먼저 의심해야 할 것이 있습니다.
바로 삭제됐지만 프로세스가 아직 잡고 있는 파일, 즉 deleted 파일입니다.

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

df와 du 결과가 다르게 보이면 당황해서 이런 작업부터 하고 싶어질 수 있습니다.

 

rm -rf /var/log/*
systemctl restart example-app
reboot
kill -9 <PID>

 

하지만 운영 서버에서는 바로 삭제하거나 재기동하면 위험합니다.

로그 파일은 장애 원인 분석에 필요할 수 있고, 서비스 재기동은 사용자 영향으로 이어질 수 있습니다.
특히 kill -9는 프로세스를 강제로 종료하는 방식이라 정상 종료 처리 없이 서비스가 끊길 수 있습니다.

df와 du가 다를 때는 먼저 이렇게 생각하는 것이 좋습니다.

df는 파일시스템 전체 사용량을 보고 있다
du는 내가 지정한 경로 안에서 보이는 파일만 계산한다
둘이 크게 다르면 보이지 않는 사용량이 있을 수 있다

 

여기서 말하는 “보이지 않는 사용량”의 대표적인 예가 deleted 파일입니다.

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

먼저 어느 마운트 지점의 사용률이 높은지 확인합니다.

 

df -h

 

예시입니다.

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   45G  5.0G  90% /
/dev/sdb1       100G   20G   80G  20% /data

 

여기서 중요한 것은 Use%만 보는 것이 아니라 Mounted on을 함께 보는 것입니다.

/       → 루트 파일시스템 확인
/var    → 로그, 캐시, 패키지 관련 확인
/data   → 데이터 파일 확인
/app    → 애플리케이션 로그 또는 업로드 파일 확인

 

예시에서는 / 파일시스템이 90%입니다.
이 경우 /data를 열심히 뒤져도 원인을 못 찾을 수 있습니다.

df -h에서 높은 파일시스템을 먼저 잡아야 du도 엉뚱한 곳을 뒤지지 않습니다.

df -h 결과에서 Use%, Avail, Mounted on을 어떻게 해석해야 할지 헷갈린다면 아래 글도 함께 확인해보면 좋습니다.

2단계. du로 큰 디렉터리 확인하기

마운트 지점이 /라면 먼저 1단계 깊이로 확인합니다.

 

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

 

여기서 -x 옵션은 다른 파일시스템으로 넘어가지 않도록 하는 옵션입니다.
루트 파일시스템만 보고 싶을 때 도움이 됩니다.

예시입니다.

1.2G    /usr
2.5G    /home
8.0G    /var
12G     /

 

이 결과에서 /var가 크다면 다시 한 단계 들어갑니다.

 

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

 

운영 서버에서는 처음부터 너무 깊게 전체를 뒤지는 것보다, 이렇게 1단계씩 좁혀가는 방식이 안전합니다.
용량 확인 명령어도 서버에 부담이 될 수 있기 때문에 범위를 줄여가며 보는 습관이 좋습니다.

3단계. du 결과가 df보다 너무 작으면 deleted 파일 의심하기

문제는 이런 상황입니다.

df -h 결과
/ 파일시스템 사용량: 45G

du -xhd1 / 결과
보이는 디렉터리 합계: 약 25G

 

차이가 20G 정도 난다면 단순히 “du를 잘못 봤나?”로 끝내지 말고 deleted 파일을 의심해야 합니다.

리눅스에서는 파일을 삭제해도, 어떤 프로세스가 그 파일을 계속 열고 있으면 디스크 공간이 바로 반환되지 않을 수 있습니다.

예를 들어 애플리케이션이 큰 로그 파일을 쓰고 있었고, 그 로그 파일을 삭제했는데 애플리케이션 프로세스가 계속 붙잡고 있는 상황입니다.

이때 du에서는 파일이 안 보일 수 있지만, df에서는 사용량이 여전히 남아 있을 수 있습니다.

확인 명령어는 lsof입니다.

 

lsof | grep deleted

 

결과가 너무 많으면 특정 경로 중심으로 좁혀서 확인합니다.

 

lsof | grep deleted | grep /var

 

또는 애플리케이션 로그 경로가 정해져 있다면 그 경로로 좁힙니다.

 

lsof | grep deleted | grep /app/logs

 

4단계. lsof deleted 결과 해석하기

예시 결과입니다.

java  12345  appuser  10w  REG  8,2  10737418240  /app/logs/app.log (deleted)

 

이 결과는 대략 이렇게 해석할 수 있습니다.

java       → 파일을 잡고 있는 프로세스
12345      → PID
appuser    → 실행 사용자
10w        → 쓰기 모드로 열린 파일
10737418240 → 약 10GB 크기
/app/logs/app.log (deleted) → 삭제됐지만 아직 프로세스가 잡고 있는 파일

 

즉, app.log 파일은 삭제됐지만 java 프로세스가 아직 파일을 놓지 않은 상태일 수 있습니다.
이 경우 파일 목록에서는 안 보이는데, 디스크 용량은 계속 사용 중으로 남을 수 있습니다.

이때 중요한 것은 “PID를 찾았으니 바로 kill”이 아닙니다.
어떤 서비스인지, 영향이 있는지, 정상 재기동이 가능한지 먼저 확인해야 합니다.

5단계. deleted 파일을 발견했을 때 바로 kill 하지 않기

deleted 파일을 발견했다고 바로 아래처럼 실행하면 위험합니다.

 

kill -9 12345

 

운영 서버에서 kill -9는 마지막 수단에 가깝습니다.
프로세스를 강제로 종료하면 서비스 장애가 생길 수 있고, 정상 종료 처리도 못 할 수 있습니다.

먼저 확인해야 할 것은 다음과 같습니다.

어떤 프로세스가 파일을 잡고 있는지
서비스 영향이 있는 프로세스인지
이중화가 되어 있는지
정상 재기동 가능한 서비스인지
현재 장애 분석에 필요한 로그가 있는지
logrotate 설정이 정상인지
재기동 가능한 시간인지

 

가능하면 해당 서비스의 상태를 먼저 확인합니다.

 

systemctl status example-app
journalctl -u example-app -n 50 --no-pager

 

재기동이 필요하다면 영향 범위와 재기동 가능 시간을 확인한 뒤 진행해야 합니다.

 

systemctl restart example-app

 

위 명령어도 운영 서버에서는 바로 실행하지 말고, 사용자 영향과 이중화 여부를 확인한 뒤 조치하는 것이 안전합니다.

6단계. 로그 파일 삭제보다 truncate를 신중히 검토하기

큰 로그 파일이 원인이라면 무작정 삭제보다 내용을 비우는 방식이 필요한 경우도 있습니다.

 

: > /app/logs/app.log

 

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

 

truncate -s 0 /app/logs/app.log

 

하지만 이것도 바로 실행하면 안 됩니다.

먼저 확인할 기준은 다음과 같습니다.

현재 장애 분석에 필요한 로그인지
로그 수집 시스템으로 이미 전송됐는지
애플리케이션이 해당 파일을 계속 쓰는지
로그 로테이션 정책이 있는지
백업 후 비워야 하는지

 

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

 

cp -p /app/logs/app.log /app/logs/app.log.bak

 

그 다음 로그 보관 기준과 서비스 영향 여부를 확인한 뒤 truncate 여부를 판단하는 것이 좋습니다.

7단계. 숨김 파일과 du 사용 방식 확인하기

초보자가 자주 놓치는 부분이 숨김 파일입니다.

예를 들어 아래 명령어는 현재 디렉터리의 일반 항목만 확인하는 방식이라, 숨김 파일을 놓쳤다고 느낄 수 있습니다.

 

du -sh *

 

숨김 파일까지 같이 보고 싶다면 이렇게 확인할 수 있습니다.

 

du -sh .[!.]* * 2>/dev/null

 

또는 전체 합계를 보고 싶다면 대상 디렉터리 자체를 확인합니다.

 

du -sh /var

 

du -sh *만 보고 “큰 파일이 없는데요?”라고 판단하면 놓치는 항목이 생길 수 있습니다.
특히 애플리케이션 설정이나 캐시가 숨김 디렉터리에 쌓이는 경우도 있으므로 확인 범위를 주의해야 합니다.

8단계. 마운트 지점이 섞였는지 확인하기

df와 du 차이는 마운트 지점 때문에도 생깁니다.

현재 마운트 상태를 확인합니다.

 

findmnt

 

또는 아래처럼 확인할 수 있습니다.

 

mount | column -t

 

예를 들어 /data가 별도 파일시스템이라면 / 용량과 /data 용량은 따로 봐야 합니다.

/      → /dev/sda2
/data  → /dev/sdb1

 

이 상태에서 /가 찼는데 /data를 열심히 확인해도 원인을 찾을 수 없습니다.

그래서 항상 df -h에서 먼저 Mounted on을 보고, 해당 마운트 안에서 du를 실행해야 합니다.

9단계. 권한 때문에 du가 일부 파일을 못 봤는지 확인하기

일반 사용자로 du를 실행하면 권한 없는 디렉터리는 제대로 계산하지 못할 수 있습니다.

이런 메시지가 나올 수 있습니다.

du: cannot read directory '/var/lib/example': Permission denied

 

운영 점검 시에는 권한 오류 메시지를 무조건 버리지 말고 확인해야 합니다.

아래처럼 오류를 따로 저장해서 볼 수 있습니다.

 

du -xhd1 /var 2>/tmp/du-error.log | sort -h
cat /tmp/du-error.log

 

권한 문제 때문에 일부 디렉터리를 못 봤다면 실제 사용량보다 작게 보일 수 있습니다.

다만 운영 서버에서 무조건 root로 실행하기보다, 필요한 권한과 절차에 맞게 확인해야 합니다.

10단계. 예약 블록도 차이를 만들 수 있습니다

ext 계열 파일시스템에서는 root를 위해 예약된 블록이 있을 수 있습니다.
이 때문에 일반 사용자가 보는 사용 가능 공간과 실제 사용량이 다르게 느껴질 수 있습니다.

파일시스템 정보를 확인할 수 있는 환경이라면 아래처럼 볼 수 있습니다.

 

tune2fs -l /dev/sda2 | grep -i "Reserved block"

 

다만 이 명령어는 파일시스템 장치명을 정확히 알아야 하고, 운영 서버에서는 신중하게 사용해야 합니다.

초보 운영자 관점에서는 먼저 아래 항목부터 보는 것이 더 현실적입니다.

deleted 파일
마운트 지점
du 확인 범위
숨김 파일
권한 오류

 

예약 블록은 앞의 항목들을 확인한 뒤에도 차이가 설명되지 않을 때 참고하는 정도로 보면 좋습니다.

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

df와 du 결과가 다를 때는 이렇게 보고하면 좋습니다.

[df와 du 용량 차이 확인]

- 발생 시각: 2026-07-13 14:20
- 대상 서버: web-01
- 증상: df -h 기준 / 파일시스템 Use% 90% 확인
- 확인 내용:
  1) df -h 결과 / 사용량 45G 확인
  2) du -xhd1 / 결과 보이는 디렉터리 합계 약 25G 수준
  3) lsof deleted 확인 결과 /app/logs/app.log deleted 상태 확인
  4) java 프로세스가 해당 파일을 계속 잡고 있는 것으로 추정
- 조치 방향:
  서비스 영향 범위 확인 후 정상 재기동 또는 로그 처리 방안 검토

 

이렇게 정리하면 단순히 “용량이 안 맞습니다”보다 훨씬 명확합니다.

운영 보고에서는 아래 4가지를 함께 적으면 좋습니다.

df 기준 사용량
du 기준 확인한 경로와 합계
deleted 파일 여부
서비스 영향과 조치 방향

 

12단계. 정리용 확인 순서

df와 du 결과가 다르게 보일 때는 아래 순서로 확인하면 좋습니다.

1. df -h 로 높은 파일시스템 확인
2. Mounted on 기준으로 대상 경로 확인
3. du -xhd1 로 큰 디렉터리 확인
4. df와 du 차이가 크면 lsof deleted 확인
5. 숨김 파일 확인
6. 마운트 지점 확인
7. du 권한 오류 확인
8. 로그 로테이션 상태 확인
9. 영향 범위 확인 후 조치

 

바로 삭제나 재부팅으로 가지 않고, 어디에서 차이가 나는지 먼저 보는 것이 중요합니다.

운영 서버에서 조심할 점

df와 du가 다를 때 아래 작업은 특히 조심해야 합니다.

 

rm -rf /var/log/*
kill -9 <PID>
reboot
chmod -R 777 /app
find / -type f -size +100M -delete

 

이런 조치는 원인을 없애는 것이 아니라 단서를 지워버리거나 장애를 키울 수 있습니다.

특히 chmod -R 777 같은 권한 변경은 보안과 서비스 동작에 모두 영향을 줄 수 있으므로 디스크 용량 문제 해결 방법으로 사용하면 안 됩니다.

운영에서는 아래 정보를 먼저 정리해야 합니다.

확인한 파일시스템
확인한 경로
큰 파일 또는 deleted 파일 여부
파일을 잡고 있는 프로세스
서비스 영향
조치 필요 여부

 

이 정보를 정리한 뒤 필요한 조치를 결정해야 합니다.

정리하면

df와 du 결과가 다르게 보이는 것은 이상한 일이 아닙니다.
둘은 보는 기준이 다릅니다.

df → 파일시스템 기준
du → 디렉터리와 파일 기준

 

그리고 차이가 크다면 먼저 이런 항목을 의심해볼 수 있습니다.

삭제됐지만 프로세스가 잡고 있는 파일
마운트 지점 차이
숨김 파일
권한 문제
du 확인 범위 누락
예약 블록

 

특히 운영 서버에서 가장 먼저 확인해볼 만한 것은 deleted 파일입니다.

 

lsof | grep deleted

 

df와 du가 다르다고 바로 삭제하거나 재기동하지 말고, 어떤 파일시스템에서 어떤 사용량이 보이지 않는지부터 차분히 확인하는 것이 좋습니다.

서버 운영에서 디스크 숫자가 맞지 않아 보일 때는 조치보다 해석이 먼저입니다.
지금 보이지 않는 용량이 어디에 숨어 있는지 찾는 과정이 곧 장애를 키우지 않는 첫 단계입니다.

 

df -h에서 용량이 남아 보이는데도 파일 생성이 안 된다면 inode 부족도 함께 확인해야 합니다. 디스크 용량은 남아 있는데 파일 생성이 안 될 때 `df -i`로 inode를 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

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

 

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

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