Linux 디스크 용량 부족 해결: df·du·journalctl로 원인 찾고 정리하기
2026년 8월 3일, GNU coreutils와 systemd를 사용하는 Linux 기준입니다. 루트 파일시스템 사용률이 100%에 가까워지면 업데이트 실패, 로그 기록 중단, 서비스 재시작 실패가 함께 나타날 수 있습니다. 무작정 파일을 지우기보다 df로 찬 파일시스템을 찾고, du로 큰 디렉터리를 좁힌 다음 정리 대상을 결정해야 합니다.
빠른 결론
df -hT로 용량이 부족한 마운트 지점을 먼저 확인합니다.du는 같은 파일시스템 안에서 큰 디렉터리를 좁히는 데 사용합니다.
systemd 로그는 사용량을 확인한 뒤 보존 기간이나 크기를 정해 정리합니다.
명령어별 역할
| 명령어 | 확인 대상 | 핵심 해석 |
|---|---|---|
df -hT | 마운트된 파일시스템 | Use%가 높은 지점과 형식 확인 |
df -i | inode 사용량 | 용량이 남아도 작은 파일이 너무 많으면 100% 가능 |
du -xhd1 | 디렉터리별 사용량 | 같은 파일시스템에서 큰 경로를 단계적으로 추적 |
journalctl --disk-usage | systemd journal | 활성·보관 로그가 차지하는 합계 확인 |
정리 전 체크리스트
- 중요한 설정, DB, 사용자 파일은 먼저 백업합니다.
- 운영 서버라면 서비스 소유자와 삭제 가능 기간을 확인합니다.
/var/lib,/usr, DB 데이터 디렉터리를 임의로 지우지 않습니다.- 명령 결과의 마운트 지점과 대상 경로가 같은지 확인합니다.
Linux 디스크 용량 부족 해결 순서
- 찬 파일시스템과 inode를 구분
df -hT를 실행해 루트(/),/home,/var등에서 Use%가 높은 지점을 찾습니다. 이어df -i로 IUse%도 확인합니다. 블록 용량이 부족한 경우와 작은 파일이 지나치게 많아 inode가 소진된 경우는 해결 대상이 다릅니다. - 큰 최상위 디렉터리 찾기
루트 파일시스템이 찼다면
sudo du -xhd1 / 2>/dev/null | sort -h를 실행합니다.-x는 다른 파일시스템으로 넘어가지 않게 하고,-d1은 한 단계까지만 보여 줍니다. GNUdu가 아닌 환경에서는--max-depth=1지원 여부를 매뉴얼로 확인하세요. - 경로를 한 단계씩 좁히기
/var가 크면sudo du -xhd1 /var | sort -h,/home이 크면 같은 방식으로 다시 확인합니다. 흔한 후보는 애플리케이션 로그, 패키지 캐시, 컨테이너 이미지, 다운로드 파일입니다. 결과를 보기 전에rm -rf부터 실행하지 마세요. - systemd journal 사용량 확인 후 정리
journalctl --disk-usage로 먼저 크기를 확인합니다. 보존 정책에 맞는 경우에만sudo journalctl --vacuum-time=14days또는sudo journalctl --vacuum-size=500M처럼 기간·크기를 지정합니다. 공식 문서상 vacuum은 오래된 보관 journal을 제거하며 활성 파일이 포함된 표시값이 즉시 목표 크기와 같아지지 않을 수 있습니다. - 패키지 캐시는 패키지 관리자로 정리
Debian·Ubuntu 계열은
sudo apt clean, Fedora 계열은sudo dnf clean packages처럼 배포판의 패키지 관리 명령을 사용합니다. 캐시 디렉터리를 직접 삭제하기보다 현재 배포판 공식 문서의 명령을 확인하세요. 오래된 커널과 사용 중인 커널을 혼동하지 않도록 패키지 제거는 별도 검토가 필요합니다. - 로그와 컨테이너 데이터의 소유 서비스 확인
/var/log,/var/lib/docker,/var/lib/containers가 크더라도 파일을 바로 지우지 않습니다. 로그는 logrotate 또는 서비스 보존 설정을 사용하고, 컨테이너는 Docker·Podman 명령으로 미사용 이미지와 볼륨을 확인합니다. 사용 중인 볼륨 삭제는 데이터 손실로 이어질 수 있습니다. - 삭제했는데 df가 줄지 않으면 열린 파일 점검
프로세스가 삭제된 파일을 계속 열고 있으면
du에는 보이지 않지만df사용량은 남을 수 있습니다.sudo lsof +L1로 후보를 확인하고, 서비스 영향과 유지보수 시간을 검토한 뒤 해당 프로세스를 정상 재시작합니다. - 정리 후 다시 측정
df -hT와df -i를 다시 실행해 실제로 여유 공간이 늘었는지 확인합니다. 임시 정리만 반복하지 말고 journal 보존 한도, 애플리케이션 로그 회전, 컨테이너 이미지 정리 정책을 설정해 재발을 막습니다.
주의사항
/var/lib/mysql,/var/lib/postgresql같은 DB 디렉터리는 서비스 절차 없이 삭제하지 않습니다.- 숫자만 보고 가장 큰 경로를 지우지 말고 소유 패키지와 서비스를 먼저 확인합니다.
- journal 보존 기간은 장애 분석과 감사 요건에 필요한 기간보다 짧게 잡지 않습니다.
- LVM, Btrfs 스냅샷, 컨테이너 overlay는
du와df값이 다르게 보일 수 있습니다.
그래도 해결되지 않을 때
df는 가득 찼는데 du 합계가 작다면 삭제된 열린 파일, 권한 때문에 빠진 경로, 스냅샷과 예약 블록을 확인합니다. 정리할 파일이 없다면 LVM 논리 볼륨과 파일시스템 확장, 별도 디스크 마운트 같은 용량 증설이 필요할 수 있습니다. 증설 전에는 파티션·볼륨·파일시스템 계층과 백업 상태를 먼저 확인하세요.
FAQ
Q1. df와 du 결과가 왜 다른가요?
df는 파일시스템 전체 사용량을, du는 접근 가능한 파일과 디렉터리의 사용량을 추정합니다. 삭제됐지만 열린 파일, 스냅샷, 예약 공간 때문에 차이가 날 수 있습니다.
Q2. journalctl vacuum을 실행하면 모든 로그가 지워지나요?
아닙니다. 지정한 조건에 따라 오래된 보관 journal을 제거합니다. 활성 journal은 남을 수 있으므로 실행 전후에 --disk-usage를 비교하세요.
Q3. Use%가 낮은데 파일을 만들 수 없는 이유는 무엇인가요?
inode가 소진됐을 수 있습니다. df -i에서 IUse%를 확인하고 캐시나 세션 파일처럼 작은 파일이 대량 생성된 경로를 찾으세요.