여기서는 멈추세요
- 명령 출력의 서버·서비스·경로가 예상 대상과 다르면 변경 단계로 넘어가지 않습니다.
- 현재 접속 세션, 백업 또는 콘솔 복구 경로를 확보하지 못했다면 상태 변경 명령을 실행하지 않습니다.
STORAGE FIRST AID
Linux 서버 디스크가 가득 찼을 때
무작정 로그를 지우지 않고 파일시스템, inode, 큰 경로, 열린 삭제 파일 순서로 원인을 좁힙니다.디스크 fullNo space leftdfduUbuntu 용량 부족
환경Ubuntu 20.04+ · Debian 계열 · systemd 기준
분류디스크·파일
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
변경 전 설정과 출력값을 기록하고, 예상과 다른 결과가 나오면 추가 변경을 멈춘 뒤 승인된 운영 복구 절차로 되돌립니다.
담당자에게 전달할 자료
- 장애 발생 시각·정상화 시각과 원문 오류 메시지
- 민감정보를 제거한 조회 명령 출력과 변경 전후 차이
- 조치 후 동일 조건으로 수행한 재검증 결과
BEFORE YOU START
이런 증상에서 시작합니다
- 파일 저장 실패
- 배포 실패
- 로그 기록 중단
- No space left on device
CHECK THE BRANCH
놓치기 쉬운 원인 분기
Docker가 큰 경우
호스트의 du 결과만으로 이미지를 삭제하지 말고 docker system df -v로 이미지·컨테이너·볼륨·빌드 캐시를 먼저 구분합니다.
로그 파일이 큰 경우
Docker json-file 로그는 daemon이 관리하므로 파일을 직접 자르지 말고 로그 회전 설정과 컨테이너 재생성 범위를 확인합니다.
df와 du가 다른 경우
삭제된 파일을 프로세스가 계속 열고 있으면 경로에서는 사라져도 공간은 반환되지 않습니다. lsof +L1 결과와 서비스 영향을 함께 확인합니다.
journald가 계속 증가하는 경우
journalctl의 전체 사용량과 persistent·runtime 저장 위치를 구분하고, vacuum 전에 보존 정책과 SystemMaxUse 설정을 확인합니다.
일반 로그 회전이 멈춘 경우
파일을 직접 비우지 말고 logrotate debug 결과, 대상 설정, 애플리케이션의 파일 재열기 방식을 확인합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
가득 찬 파일시스템 확인
먼저 전체 디스크가 아니라 어느 마운트 지점이 부족한지 확인합니다.
용량과 파일시스템 종류
df -hTinode 사용률
df -ih결과 읽기
Use%가 높으면 용량 문제, IUse%가 높으면 작은 파일이 너무 많은 inode 문제입니다.
다음 판단
문제가 발생한 Mountpoint를 기록하고 그 경로만 조사합니다.
조회시스템을 변경하지 않는 확인 단계
대상 경로의 실제 마운트 확인
별도 볼륨이나 bind mount를 다른 디스크로 착각하지 않도록 대상 경로의 소스를 확인합니다.
/var가 속한 파일시스템
findmnt -T /var결과 읽기
SOURCE와 TARGET이 1단계에서 확인한 파일시스템과 일치하는지 봅니다.
다음 판단
다른 볼륨이면 해당 마운트 지점을 기준으로 다음 단계를 실행합니다.
주의서버 부하나 권한을 고려할 단계
큰 디렉터리부터 범위 좁히기
같은 파일시스템 안에서만 한 단계씩 내려갑니다. 파일이 매우 많으면 du가 I/O를 사용할 수 있습니다.
/var 하위 비교
sudo du -xhd1 /var 2>/dev/null | sort -h로그 경로 비교
sudo du -xhd1 /var/log 2>/dev/null | sort -h결과 읽기
목록 아래쪽의 큰 디렉터리가 우선 조사 대상입니다. 숫자만 보고 바로 삭제하지 마세요.
다음 판단
애플리케이션 데이터인지 로그·캐시인지 소유 서비스를 먼저 확인합니다.
조회시스템을 변경하지 않는 확인 단계
로그와 삭제된 열린 파일 확인
df는 가득 찼는데 du 합계가 작다면 삭제된 파일을 프로세스가 계속 열고 있을 수 있습니다.
systemd 로그 사용량
journalctl --disk-usage삭제됐지만 열린 파일
sudo lsof +L1journal 저장 위치별 용량
sudo du -sh /var/log/journal /run/log/journal 2>/dev/nulljournald 제한값 확인
systemd-analyze cat-config systemd/journald.conf | grep -E '^(System|Runtime)(MaxUse|KeepFree)='logrotate 설정 시뮬레이션
sudo logrotate --debug /etc/logrotate.conf결과 읽기
journal 사용량, 삭제됐지만 열린 파일, logrotate의 오류를 구분합니다. vacuum은 보관된 journal만 줄이고 활성 파일은 남을 수 있습니다.
다음 판단
로그 생성 주체와 보존 요건을 확인한 뒤 journald 또는 애플리케이션별 회전 정책을 선택합니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
보존 정책에 맞춰 정리하고 재검증
아래 명령은 데이터를 줄입니다. 조직의 로그 보존 정책과 장애 분석 필요 여부를 먼저 확인하세요.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
보관 journal을 500MB로 제한
sudo journalctl --vacuum-size=500MAPT 다운로드 캐시 정리
sudo apt clean조치 후 확인
df -hT / /var결과 읽기
Use%가 줄었고 서비스 로그가 정상 기록되는지 함께 확인합니다.
다음 판단
재발한다면 journald·애플리케이션 로그 회전 정책을 별도 개선합니다.
PRIMARY REFERENCES
공식 문서
- GNU Coreutils — 파일시스템 사용량
- util-linux findmnt 매뉴얼
- systemd — journalctl disk usage와 vacuum
- lsof 매뉴얼
- Docker — docker system df
- Docker — JSON file 로그 회전
- systemd — journald 용량 제한
- logrotate — 공식 매뉴얼 소스
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.