Ubuntu 서버 용량 부족, 지우기 전에 확인할 것: /var/log · /var/lib · Docker 정리 순서
Ubuntu 서버의 디스크가 가득 차면 가장 먼저 /var/log나 /var/lib를 지우고 싶어집니다. 하지만 두 경로는 성격이 완전히 다릅니다. /var/log에는 시스템과 서비스의 로그가 저장되고, /var/lib에는 데이터베이스·Docker·패키지 관리자처럼 서비스가 계속 사용해야 하는 상태 데이터가 들어갈 수 있습니다.
따라서 안전한 순서는 삭제가 아니라 측정 → 원인 분류 → 서비스별 정리 → 재발 방지입니다. 이 글은 운영 서버의 데이터와 컨테이너 볼륨을 보호하면서 용량 원인을 좁히는 절차를 정리합니다.
핵심 원칙
/var/log/*와/var/lib/*를 통째로 삭제하지 않습니다.- 먼저 파일시스템 용량과 inode를 확인합니다.
- Docker·systemd journal·APT처럼 데이터를 만든 도구의 정리 기능을 사용합니다.
- 삭제 명령은 대상과 백업을 확인한 뒤 실행합니다.
1. 디스크 공간과 inode부터 구분하기
먼저 루트 파일시스템의 전체 공간을 확인합니다.
df -hT /
df는 파일시스템 전체의 사용량과 남은 공간을 보여줍니다. -h는 사람이 읽기 쉬운 단위를 사용하고, -T는 파일시스템 형식을 함께 표시합니다. GNU Coreutils 공식 문서도 df를 파일시스템의 사용 가능 공간을 확인하는 도구로 설명합니다.
공간은 남았는데 파일을 만들 수 없다면 inode가 소진됐을 수도 있습니다.
df -ih /
작은 로그나 캐시 파일이 매우 많이 쌓이면 바이트 용량보다 inode가 먼저 부족해질 수 있습니다. Use%와 IUse%를 따로 봐야 하는 이유입니다.
2. /var에서 큰 디렉터리 찾기
루트 파일시스템 밖의 마운트까지 따라가지 않도록 -x를 사용하고, 한 단계씩 범위를 좁힙니다.
sudo du -xhd1 /var | sort -h
/var/log와 /var/lib를 다시 확인합니다.
sudo du -xhd1 /var/log | sort -h
sudo du -xhd1 /var/lib | sort -h
du는 파일과 디렉터리가 차지하는 공간을 추정합니다. -d1은 바로 아래 한 단계만 보여 주므로, 처음부터 서버 전체를 재귀적으로 훑는 것보다 원인을 좁히기 쉽습니다.
-x는 다른 파일시스템으로 넘어가지 않습니다. /var/lib/docker가 별도 디스크나 마운트라면 다음 명령으로 마운트 위치와 해당 파일시스템의 용량을 따로 확인합니다.
findmnt -T /var/lib/docker
df -hT /var/lib/docker
특정 크기 이상의 일반 파일만 찾고 싶다면 다음처럼 조회할 수 있습니다.
sudo find /var -xdev -type f -size +500M -printf '%s %p\n' \
| sort -n \
| tail -n 30
출력에는 서비스명, 내부 경로, 백업 파일명이 포함될 수 있습니다. 외부에 공유할 때는 경로와 식별자를 가립니다.
3. /var/log가 큰 경우: journal과 일반 로그를 분리하기
Ubuntu에서는 systemd journal과 일반 텍스트 로그가 함께 공간을 사용할 수 있습니다. 먼저 journal이 실제로 차지하는 용량을 확인합니다.
journalctl --disk-usage
부팅별 로그 범위도 확인할 수 있습니다.
journalctl --list-boots
보존 정책에 맞지 않게 오래된 아카이브 journal이 많다면 시간이나 크기를 기준으로 정리할 수 있습니다.
sudo journalctl --vacuum-time=14days
또는 운영 정책에 정한 상한을 사용합니다.
sudo journalctl --vacuum-size=1G
1G는 예시이므로 장애 분석에 필요한 보존 기간과 디스크 크기에 맞춰 조정합니다. --vacuum-size와 --vacuum-time은 오래된 아카이브 journal을 제거합니다. 현재 쓰는 활성 journal까지 모두 지우는 명령은 아닙니다. 그래서 실행 후 journalctl --disk-usage 값이 요청한 한도와 정확히 같아지지 않을 수 있습니다.
장기적으로는 /etc/systemd/journald.conf 또는 드롭인 파일에서 보존 한도를 정합니다. 서버마다 장애 분석에 필요한 보존 기간이 다르므로 모든 환경에 같은 숫자를 적용하면 안 됩니다.
[Journal]
SystemMaxUse=1G
SystemKeepFree=500M
위 값도 예시입니다. 실제 서버에서는 전체 디스크 크기와 로그 보존 정책을 기준으로 정합니다.
일반 로그는 logrotate 설정을 먼저 확인합니다.
sudo logrotate -d /etc/logrotate.conf
-d는 디버그 모드로 설정을 확인하며 로그 파일과 상태 파일을 변경하지 않습니다. 실제 로테이션을 강제로 실행하기 전에 오류와 적용 대상을 확인하는 용도로 사용합니다.
참고: Ubuntu 24.04 logrotate 매뉴얼
다음과 같은 일괄 삭제는 피해야 합니다.
# 실행 금지 예시
sudo rm -rf /var/log/*
서비스가 열어 둔 로그 파일, 권한과 소유자, 로그 로테이션 상태를 망가뜨릴 수 있습니다. 로그는 해당 서비스의 로테이션 정책이나 journal 기능을 통해 정리하는 편이 안전합니다.
4. /var/lib가 큰 경우: 파일이 아니라 서비스를 찾기
/var/lib는 단순한 임시 디렉터리가 아닙니다. 데이터베이스, Docker 이미지와 볼륨, 패키지 상태, 애플리케이션 데이터가 존재할 수 있습니다.
sudo du -xhd1 /var/lib | sort -h
큰 하위 디렉터리를 찾았다면 먼저 어떤 서비스가 관리하는지 확인합니다. 경로만 보고 직접 rm을 실행하면 데이터 손실이나 서비스 기동 실패로 이어질 수 있습니다.
특히 다음 명령은 사용하지 않습니다.
# 실행 금지 예시
sudo rm -rf /var/lib/docker/*
Docker 데이터는 Docker CLI로 사용 관계를 확인하고 정리해야 합니다.
5. Docker가 큰 경우: system df로 사용 관계 확인하기
Docker 전체 사용량은 다음 명령으로 확인합니다.
docker system df
docker system df -v
-v 출력은 이미지, 컨테이너, 로컬 볼륨과 빌드 캐시를 더 자세히 보여 줍니다. 삭제 전에 실행 중인 컨테이너와 중지된 컨테이너도 확인합니다.
docker ps
docker ps -a
docker image ls
docker volume ls
정리 대상을 확인한 후에는 범위가 좁은 명령부터 사용합니다.
docker image prune
docker container prune
docker builder prune
docker image prune의 기본 동작은 dangling 이미지 정리입니다.docker container prune은 모든 중지된 컨테이너를 대상으로 하므로, 표시되는 확인 메시지에서 범위를 다시 보고 재사용 여부를 확인해야 합니다.docker builder prune은 기본적으로 dangling 빌드 캐시를 정리합니다.--all은 범위가 더 넓으므로 이 글의 기본 명령에서 제외합니다.
docker system prune은 중지된 컨테이너, 사용하지 않는 네트워크, dangling 이미지와 빌드 캐시를 한 번에 정리합니다. 편리하지만 영향 범위가 넓으므로 목록을 확인하지 않은 상태에서 습관적으로 실행하면 안 됩니다. --volumes는 기본값이 아니며, 볼륨 삭제는 데이터베이스·업로드 파일과 직접 연결될 수 있으므로 이 글의 기본 정리 명령에서 제외합니다.
참고: Docker 리소스 정리 공식 문서, Docker system df 공식 문서
Docker Compose 경고도 함께 보인다면 Docker Compose version·external.name 경고 해결법을 먼저 확인할 수 있습니다. 관리 UI와 Docker API 노출 범위는 Portainer·Docker 관리면 보안 점검에서 이어집니다.
6. Docker 컨테이너 로그의 재발 방지
Docker의 기본 json-file 로그 드라이버는 로테이션 설정이 없으면 로그가 계속 커질 수 있습니다. 현재 기본 드라이버를 확인합니다.
docker info --format '{{.LoggingDriver}}'
Docker 공식 문서는 daemon.json의 log-opts 값이 문자열이어야 한다고 안내합니다. 예시는 다음과 같습니다.
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
이 값은 예시일 뿐입니다. 실제 크기와 보존 개수는 장애 분석 기간과 디스크 크기에 맞춰 정해야 합니다. 기존 daemon.json에 다른 설정이 있다면 예시 전체로 덮어쓰지 말고 필요한 키를 병합한 뒤 JSON 문법과 설정 충돌을 검증합니다. Docker 데몬을 재시작한 뒤에도 기존 컨테이너가 자동으로 새 설정을 사용하지는 않습니다. 공식 문서에 따르면 새 로깅 설정은 새로 생성되는 컨테이너에 적용되므로, Compose 서비스는 변경 영향과 백업을 확인한 후 재생성해야 합니다.
참고: Docker json-file 로깅 공식 문서, Docker 로깅 드라이버 설정
7. APT 캐시는 지우기 전에 크기와 제거 목록 확인하기
다운로드한 패키지 캐시의 크기를 확인합니다.
sudo du -sh /var/cache/apt/archives
캐시만 정리할 때는 다음 명령을 사용할 수 있습니다.
sudo apt-get clean
Ubuntu 24.04 공식 매뉴얼에 따르면 clean은 /var/cache/apt/archives/와 그 하위의 내려받은 패키지 파일을 정리하고 잠금 파일은 남깁니다.
더 이상 필요하지 않은 의존성 패키지는 먼저 시뮬레이션합니다.
sudo apt-get -s autoremove
출력의 제거 대상과 현재 필요한 커널·드라이버·서비스 패키지를 확인한 뒤에만 실제 autoremove를 검토합니다. -s는 실제 변경 없이 예상 동작을 보여 주는 옵션입니다.
참고: Ubuntu 24.04 apt-get 공식 매뉴얼
8. 파일을 지웠는데 df 용량이 줄지 않는 경우
실행 중인 프로세스가 삭제된 파일을 계속 열고 있으면 디렉터리 목록에서는 사라져도 공간이 반환되지 않을 수 있습니다. lsof가 설치돼 있다면 다음처럼 확인합니다.
sudo lsof +L1
출력에서 큰 삭제 파일을 잡고 있는 프로세스를 찾은 뒤, 서비스 영향과 재시작 절차를 확인합니다. 공간을 되찾기 위해 서버 전체를 무조건 재부팅하기보다 해당 서비스를 정상적인 방식으로 재시작하는 편이 낫습니다.
9. 안전한 실행 순서
운영 서버에서는 다음 순서를 권장합니다.
df -hT /와df -ih /로 블록·inode 부족을 구분합니다.du -xhd1로/var,/var/log,/var/lib를 단계적으로 확인합니다.- 로그라면 journal과 일반 로그를 분리합니다.
- Docker라면
docker system df -v와 컨테이너·볼륨 목록을 확인합니다. - 삭제 대상이 데이터인지 재생성 가능한 캐시인지 구분합니다.
- 데이터가 포함될 수 있으면 백업과 복원 가능성을 먼저 확인합니다.
- 범위가 좁고 확인 프롬프트가 있는 정리 명령부터 실행합니다.
- 실행 전후의
df,du, 서비스 상태를 기록합니다. - 로그 로테이션과 Docker 로깅 제한을 설정해 재발을 막습니다.
백업 파일이 존재하는 것과 실제 복구가 가능한 것은 다릅니다. Ghost나 데이터베이스 볼륨을 정리하기 전에는 Ghost·MySQL 백업 무결성 확인 방법처럼 체크섬과 복원 절차를 별도로 확인해야 합니다.
마무리
/var/log가 크면 로그 정책을 확인하고, /var/lib가 크면 해당 데이터를 관리하는 서비스를 찾아야 합니다. 같은 /var 아래에 있어도 정리 방법은 다릅니다.
가장 중요한 기준은 간단합니다. 경로를 보고 지우지 말고, 데이터를 만든 서비스의 상태와 사용 관계를 확인한 뒤 그 서비스가 제공하는 정리 기능을 사용합니다. 이 원칙을 지키면 디스크 공간을 확보하면서도 컨테이너 볼륨과 운영 데이터를 보호할 수 있습니다.
외부에서 노출된 관리 포트와 방화벽까지 함께 확인하려면 서버 외부 포트·방화벽 점검 절차를 이어서 볼 수 있습니다.
