beautifulsoups.dev
Published on

리눅스 디스크 100%? 큰 파일 5분내 찾아 삭제

Authors

서버 알람이 disk usage 95% 를 찍는 순간, 원인은 대부분 단순합니다.

  • 로그가 폭주했다
  • 덤프 파일이 쌓였다
  • 컨테이너 이미지/레이어가 비대해졌다
  • 임시 디렉터리가 청소되지 않았다
  • 삭제했는데도 용량이 안 줄었다(열린 파일)

이 글은 “지금 당장 디스크를 비워야 하는 상황”을 기준으로, 5분 내 큰 파일을 찾아 삭제하거나, 최소한 용량을 회수할 수 있게 하는 커맨드 플로우를 정리합니다.

주의: 무작정 rm -rf 는 장애를 키웁니다. 아래 순서대로 어디가 찼는지 확인하고, 삭제 전 영향 범위를 좁힌 뒤, 안전하게 정리하세요.

0. 현재 상황 30초 진단: 어느 마운트가 찼나

가장 먼저 “전체 디스크”가 아니라 어느 파일시스템(마운트포인트) 이 찼는지 확인해야 합니다.

df -h

출력에서 Use% 가 높은 라인을 찾고, 보통은 / 또는 /var 또는 /home 가 원인입니다.

Inode(파일 개수) 부족일 수도 있으니 같이 확인합니다.

df -ih
  • df -h 는 용량 기준
  • df -ih 는 inode 기준

inode가 100%면 “큰 파일”이 아니라 “너무 많은 작은 파일”이 원인이라 접근법이 달라집니다(예: 캐시 디렉터리 폭주).

1. 1분 컷: 어떤 디렉터리가 제일 큰가(상위부터)

문제 마운트포인트를 기준으로 상위 디렉터리부터 범위를 좁힙니다. 루트(/)가 찼다면 아래처럼 합니다.

sudo du -xhd 1 / | sort -h
  • -x : 다른 파일시스템으로 넘어가지 않음(원인 추적에 중요)
  • -h : 사람이 읽기 쉬운 단위
  • -d 1 : 1단계 깊이만

예를 들어 /var 가 크다면 /var 안에서 다시 좁힙니다.

sudo du -xhd 1 /var | sort -h
sudo du -xhd 1 /var/log | sort -h

여기까지 하면 보통 “범인 디렉터리”는 잡힙니다. 이제 그 안에서 “큰 파일 Top N”을 뽑습니다.

2. 2분 컷: 큰 파일 Top 20 찾기(삭제 후보 리스트)

옵션 A: find 로 크기순 정렬(가장 범용)

특정 디렉터리(예: /var/log)에서 100MB 이상 파일을 찾아 크기순으로 봅니다.

sudo find /var/log -xdev -type f -size +100M -printf '%s\t%p\n' \
  | sort -nr \
  | head -n 20 \
  | awk '{printf "%.1fMB\t%s\n", $1/1024/1024, $2}'
  • -xdev : 해당 파일시스템 내부만
  • -size +100M : 기준은 상황에 맞게 +500M, +1G 로 조정

옵션 B: 전체에서 가장 큰 파일 찾기(루트 기준)

sudo find / -xdev -type f -size +1G -printf '%s\t%p\n' 2>/dev/null \
  | sort -nr \
  | head -n 30 \
  | awk '{printf "%.2fGB\t%s\n", $1/1024/1024/1024, $2}'

2>/dev/null 은 권한 에러로 출력이 도배되는 걸 줄여줍니다.

3. 삭제 전에 30초만: 이 파일, 지금 지워도 되나?

큰 파일이 보이면 바로 지우기 전에 최소한 아래를 확인합니다.

3-1. 로그 파일인가

로그면 대개 지워도 되지만, 서비스가 계속 쓰는 중이면 “삭제해도 용량이 안 돌아오는” 상황이 생깁니다(열린 파일). 이 케이스는 아래 6번에서 다룹니다.

로그인지 빠르게 확인:

sudo file -b /path/to/file
sudo ls -lh /path/to/file

3-2. 최근에 생성된 덤프/코어 파일인가

core.*, heapdump, hs_err_pid*, *.dump, *.hprof 같은 파일은 수 GB 로 커지기도 합니다.

sudo ls -lh /path/to/file
sudo stat /path/to/file

업무적으로 필요하면 다른 볼륨이나 오브젝트 스토리지로 옮기고 지우세요.

sudo mv /path/to/big.dump /mnt/bigger-disk/

4. 안전한 삭제 패턴: 즉시 확보 vs 점진적 확보

4-1. 즉시 확보: 필요 없는 파일 삭제

sudo rm -f /path/to/bigfile

4-2. 로그는 “truncate” 가 더 안전할 때가 많다

프로세스가 로그 파일을 계속 쓰는 중이라면 rm 보다 크기만 0으로 만드는 방식이 안전합니다.

sudo truncate -s 0 /var/log/nginx/access.log

또는 셸 리다이렉션:

: | sudo tee /var/log/nginx/access.log >/dev/null
  • 장점: 파일 핸들은 유지되므로 서비스 영향이 적음
  • 단점: 원인 분석을 위한 로그가 사라짐(필요하면 먼저 백업)

백업 후 비우기:

sudo cp /var/log/nginx/access.log /tmp/access.log.bak
sudo truncate -s 0 /var/log/nginx/access.log

5. “로그가 범인”일 때 자주 터지는 지점

5-1. journalctl 로그(시스템드 저널) 정리

저널이 수 GB 이상 커지는 경우가 있습니다.

현재 사용량:

sudo journalctl --disk-usage

최근 7일만 남기기:

sudo journalctl --vacuum-time=7d

용량으로 제한(예: 1GB):

sudo journalctl --vacuum-size=1G

5-2. 애플리케이션 로그 폭주: 로테이션 설정 확인

장기적으로는 logrotate 설정을 점검해야 합니다. 특히 copytruncate 여부, 보관 주기, 압축, 서비스 재시작 정책을 확인하세요.

관련해서 “삭제했는데도 디스크가 안 줄어드는” 열린 파일 이슈까지 연결되는 경우가 많습니다. 아래 글도 함께 보시면 좋습니다.

6. 삭제했는데도 df 가 안 줄어든다: 열린 삭제 파일(진짜 흔함)

리눅스는 어떤 프로세스가 파일을 열고 있는 동안, 그 파일을 rm 해도 디스크 공간이 즉시 반환되지 않을 수 있습니다. 파일은 디렉터리 엔트리에서만 사라지고, inode는 프로세스가 잡고 있어 “삭제된 채로 열린 파일”이 됩니다.

6-1. 열린 삭제 파일 찾기

lsof 로 (deleted) 를 찾습니다.

sudo lsof +L1

또는 특정 디렉터리/마운트에서 좁혀서:

sudo lsof | grep '(deleted)'

출력에서 용량이 큰 항목을 찾고, 해당 PID의 프로세스를 재시작하거나(가장 일반적), 안전하게 종료하면 공간이 회수됩니다.

sudo systemctl restart nginx
# 또는
sudo kill -HUP PID

서비스 영향이 있으니, 트래픽/배포 상태를 보고 판단하세요.

7. 컨테이너 환경에서 100%가 잘 나는 곳: Docker 정리

서버가 Docker 를 쓰면 /var/lib/docker 가 급격히 커질 수 있습니다.

7-1. Docker 사용량 확인

docker system df

7-2. 안 쓰는 리소스 정리(주의해서)

중지된 컨테이너, dangling 이미지, 빌드 캐시 등을 정리합니다.

docker system prune

좀 더 공격적으로(사용하지 않는 이미지까지):

docker system prune -a

볼륨까지 지우면 데이터가 날아갈 수 있으니 신중히:

docker system prune -a --volumes

운영에서는 “어떤 볼륨이 데이터 볼륨인지”를 먼저 확인하고 진행하세요.

8. 5분 타임라인(실전 체크리스트)

아래 순서대로 하면 대부분 5분 내에 원인을 찾고, 최소한 긴급 공간을 확보할 수 있습니다.

  1. 마운트 확인
df -h
  1. 가장 큰 디렉터리 찾기
sudo du -xhd 1 /var | sort -h
  1. 큰 파일 Top N 뽑기
sudo find /var -xdev -type f -size +500M -printf '%s\t%p\n' | sort -nr | head
  1. 로그면 truncate 우선 고려
sudo truncate -s 0 /var/log/your.log
  1. 삭제했는데도 안 줄면 열린 삭제 파일 확인
sudo lsof +L1
  1. Docker 쓰면 정리
docker system df

9. 재발 방지: “큰 파일이 생기는 구조”를 없애기

긴급 대응 후에는 재발 방지를 걸어두는 게 진짜 해결입니다.

  • 로그 정책: logrotate 주기, 압축(compress), 보관 개수(rotate), 최대 크기(size)를 서비스별로 정의
  • 저널 제한: /etc/systemd/journald.conf 에 SystemMaxUse 같은 상한 설정
  • 덤프 파일 정책: JVM heap dump, core dump 경로를 별도 볼륨으로 분리하거나 생성 조건을 제한
  • 모니터링: 디스크 사용률 임계치 알림을 80%, 90%, 95%로 단계화

운영 이슈는 대개 “한 번 터지고 끝”이 아니라, 같은 패턴으로 다시 터집니다. 이번에 찾은 범인이 로그라면 로그 정책을, 컨테이너 캐시라면 이미지/빌드 캐시 정책을 함께 손보는 것이 장기적으로 가장 비용이 적습니다.

Discuss on Twitter • View on GitHub