> ## Content Index
> Fetch the complete content index at: https://mlog.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# Ubuntu 서버 용량 부족, 지우기 전에 확인할 것: /var/log · /var/lib · Docker 정리 순서
- URL: https://mlog.me/ubuntu-server-disk-usage-var-log-docker-cleanup/
- Published: 2026-08-25T10:00:13.000Z
- Updated: 2026-09-08T22:38:12.000Z
- Description: Ubuntu 서버에서 df·du로 디스크와 inode를 확인하고 /var/log, systemd journal, /var/lib/docker, APT 캐시를 데이터 손실 없이 점검·정리하는 순서를 설명합니다.
- Author: mLog
- Tags: 서버·인프라, Ubuntu, Linux, Docker

Ubuntu 서버의 용량을 확인했을 때 `/var`는 11G였고, 그중 `/var/log`가 2.4G, `/var/lib`가 7.9G였습니다. 당시 질문은 이 두 디렉터리를 어떻게 정리해야 하느냐는 것이었습니다. 하지만 같은 `/var` 아래에 있어도 로그와 서비스 상태 데이터는 정리 기준이 다릅니다. 큰 경로를 찾은 다음에는 무엇을 지울 수 있는지부터 구분해야 했습니다.

이 글은 그 출력에서 출발한 정리 전 점검 가이드입니다. 실제 삭제 후 확보한 공간을 보고하는 글은 아닙니다. `/var/log`의 로그와 `/var/lib`의 데이터베이스·Docker·패키지 상태를 나누고, 측정 → 원인 분류 → 서비스별 정리 → 재발 방지 순서로 운영 데이터와 컨테이너 볼륨을 보호하는 확인 절차를 정리합니다.

**핵심 원칙**

- `/var/log/*`와 `/var/lib/*`를 통째로 삭제하지 않습니다.
- 먼저 파일시스템 용량과 inode를 확인합니다.
- Docker·systemd journal·APT처럼 데이터를 만든 도구의 정리 기능을 사용합니다.
- 삭제 명령은 대상과 백업을 확인한 뒤 실행합니다.

## 1\. 디스크 공간과 inode부터 구분하기

먼저 루트 파일시스템의 전체 공간을 확인합니다.

```bash
df -hT /

```

`df`는 파일시스템 전체의 사용량과 남은 공간을 보여줍니다. `-h`는 사람이 읽기 쉬운 단위를 사용하고, `-T`는 파일시스템 형식을 함께 표시합니다. GNU Coreutils 공식 문서도 `df`를 파일시스템의 사용 가능 공간을 확인하는 도구로 설명합니다.

공간은 남았는데 파일을 만들 수 없다면 inode가 소진됐을 수도 있습니다.

```bash
df -ih /

```

작은 로그나 캐시 파일이 매우 많이 쌓이면 바이트 용량보다 inode가 먼저 부족해질 수 있습니다. `Use%`와 `IUse%`를 따로 봐야 하는 이유입니다.

참고: [GNU Coreutils df 공식 문서](https://www.gnu.org/software/coreutils/manual/html%5Fnode/df-invocation.html?ref=mlog.me)

## 2\. /var에서 큰 디렉터리 찾기

루트 파일시스템 밖의 마운트까지 따라가지 않도록 `-x`를 사용하고, 한 단계씩 범위를 좁힙니다.

```bash
sudo du -xhd1 /var | sort -h

```

`/var/log`와 `/var/lib`를 다시 확인합니다.

```bash
sudo du -xhd1 /var/log | sort -h
sudo du -xhd1 /var/lib | sort -h

```

`du`는 파일과 디렉터리가 차지하는 공간을 추정합니다. `-d1`은 합계가 표시되는 디렉터리 깊이를 바로 아래 한 단계로 제한할 뿐, 용량 합계를 계산하는 재귀 탐색을 한 단계에서 멈추지는 않습니다. `/` 대신 `/var`처럼 대상 경로를 좁히고 `-x`로 다른 파일시스템을 제외하면 점검 범위를 줄일 수 있지만, `/var` 아래 파일이 많으면 이 명령도 시간이 걸릴 수 있습니다.

`-x`는 다른 파일시스템으로 넘어가지 않습니다. `/var/lib/docker`가 별도 디스크나 마운트라면 다음 명령으로 마운트 위치와 해당 파일시스템의 용량을 따로 확인합니다.

```bash
findmnt -T /var/lib/docker
df -hT /var/lib/docker

```

특정 크기 이상의 일반 파일만 찾고 싶다면 다음처럼 조회할 수 있습니다.

```bash
sudo find /var -xdev -type f -size +500M -printf '%s %p\n' \
  | sort -n \
  | tail -n 30

```

출력에는 서비스명, 내부 경로, 백업 파일명이 포함될 수 있습니다. 외부에 공유할 때는 경로와 식별자를 가립니다.

참고: [GNU Coreutils du 공식 문서](https://www.gnu.org/software/coreutils/manual/html%5Fnode/du-invocation.html?ref=mlog.me)

## 3\. /var/log가 큰 경우: journal과 일반 로그를 분리하기

Ubuntu에서는 systemd journal과 일반 텍스트 로그가 함께 공간을 사용할 수 있습니다. 먼저 journal이 실제로 차지하는 용량을 확인합니다.

```bash
journalctl --disk-usage

```

부팅별 로그 범위도 확인할 수 있습니다.

```bash
journalctl --list-boots

```

보존 정책에 맞지 않게 오래된 **아카이브 journal**이 많다면 시간이나 크기를 기준으로 정리할 수 있습니다.

```bash
sudo journalctl --vacuum-time=14days

```

또는 운영 정책에 정한 상한을 사용합니다.

```bash
sudo journalctl --vacuum-size=1G

```

`1G`는 예시이므로 장애 분석에 필요한 보존 기간과 디스크 크기에 맞춰 조정합니다. `--vacuum-size`와 `--vacuum-time`은 오래된 아카이브 journal을 제거합니다. 현재 쓰는 활성 journal까지 모두 지우는 명령은 아닙니다. 그래서 실행 후 `journalctl --disk-usage` 값이 요청한 한도와 정확히 같아지지 않을 수 있습니다.

장기적으로는 `/etc/systemd/journald.conf` 또는 드롭인 파일에서 보존 한도를 정합니다. 서버마다 장애 분석에 필요한 보존 기간이 다르므로 모든 환경에 같은 숫자를 적용하면 안 됩니다.

```ini
[Journal]
SystemMaxUse=1G
SystemKeepFree=500M

```

위 값도 예시입니다. 실제 서버에서는 전체 디스크 크기와 로그 보존 정책을 기준으로 정합니다.

참고: [systemd journalctl 공식 문서](https://www.freedesktop.org/software/systemd/man/255/journalctl.html?ref=mlog.me)

일반 로그는 logrotate 설정을 먼저 확인합니다.

```bash
sudo logrotate -d /etc/logrotate.conf

```

`-d`는 디버그 모드로 설정을 확인하며 로그 파일과 상태 파일을 변경하지 않습니다. 실제 로테이션을 강제로 실행하기 전에 오류와 적용 대상을 확인하는 용도로 사용합니다.

참고: [Ubuntu 24.04 logrotate 매뉴얼](https://manpages.ubuntu.com/manpages/noble/man8/logrotate.8.html?ref=mlog.me)

다음과 같은 일괄 삭제는 피해야 합니다.

```bash
# 실행 금지 예시
# sudo rm -rf /var/log/*

```

서비스가 열어 둔 로그 파일, 권한과 소유자, 로그 로테이션 상태를 망가뜨릴 수 있습니다. 로그는 해당 서비스의 로테이션 정책이나 journal 기능을 통해 정리하는 편이 안전합니다.

## 4\. /var/lib가 큰 경우: 파일이 아니라 서비스를 찾기

`/var/lib`는 단순한 임시 디렉터리가 아닙니다. 데이터베이스, Docker 이미지와 볼륨, 패키지 상태, 애플리케이션 데이터가 존재할 수 있습니다.

```bash
sudo du -xhd1 /var/lib | sort -h

```

큰 하위 디렉터리를 찾았다면 먼저 어떤 서비스가 관리하는지 확인합니다. 경로만 보고 직접 `rm`을 실행하면 데이터 손실이나 서비스 기동 실패로 이어질 수 있습니다.

특히 다음 명령은 사용하지 않습니다.

```bash
# 실행 금지 예시
# sudo rm -rf /var/lib/docker/*

```

Docker 데이터는 Docker CLI로 사용 관계를 확인하고 정리해야 합니다.

## 5\. Docker가 큰 경우: system df로 사용 관계 확인하기

Docker 전체 사용량은 다음 명령으로 확인합니다.

```bash
docker system df
docker system df -v

```

`-v` 출력은 이미지, 컨테이너, 로컬 볼륨과 빌드 캐시를 더 자세히 보여 줍니다. 삭제 전에 실행 중인 컨테이너와 중지된 컨테이너도 확인합니다.

```bash
docker ps
docker ps -a
docker image ls
docker volume ls

```

정리 대상을 확인한 후에는 범위가 좁은 명령부터 사용합니다.

```bash
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 리소스 정리 공식 문서](https://docs.docker.com/engine/manage-resources/pruning/?ref=mlog.me), [Docker system df 공식 문서](https://docs.docker.com/reference/cli/docker/system/df/?ref=mlog.me)

Docker Compose 경고도 함께 보인다면 [Docker Compose version·external.name 경고 해결법](https://mlog.me/docker-compose-version-obsolete-external-name-deprecated/)을 먼저 확인할 수 있습니다. 관리 UI와 Docker API 노출 범위는 [Portainer·Docker 관리면 보안 점검](https://mlog.me/portainer-docker-management-security-check/)에서 이어집니다.

## 6\. Docker 컨테이너 로그의 재발 방지

Docker의 기본 `json-file` 로그 드라이버는 로테이션 설정이 없으면 로그가 계속 커질 수 있습니다. 현재 기본 드라이버를 확인합니다.

```bash
docker info --format '{{.LoggingDriver}}'

```

Docker 공식 문서는 `daemon.json`의 `log-opts` 값이 문자열이어야 한다고 안내합니다. 예시는 다음과 같습니다.

```json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

```

이 값은 예시일 뿐입니다. 실제 크기와 보존 개수는 장애 분석 기간과 디스크 크기에 맞춰 정해야 합니다. 기존 `daemon.json`에 다른 설정이 있다면 예시 전체로 덮어쓰지 말고 필요한 키를 병합한 뒤 JSON 문법과 설정 충돌을 검증합니다. Docker 데몬을 재시작한 뒤에도 기존 컨테이너가 자동으로 새 설정을 사용하지는 않습니다. 공식 문서에 따르면 새 로깅 설정은 새로 생성되는 컨테이너에 적용되므로, Compose 서비스는 변경 영향과 백업을 확인한 후 재생성해야 합니다.

참고: [Docker json-file 로깅 공식 문서](https://docs.docker.com/engine/logging/drivers/json-file/?ref=mlog.me), [Docker 로깅 드라이버 설정](https://docs.docker.com/engine/logging/configure/?ref=mlog.me)

## 7\. APT 캐시는 지우기 전에 크기와 제거 목록 확인하기

다운로드한 패키지 캐시의 크기를 확인합니다.

```bash
sudo du -sh /var/cache/apt/archives

```

캐시만 정리할 때는 다음 명령을 사용할 수 있습니다.

```bash
sudo apt-get clean

```

Ubuntu 24.04 공식 매뉴얼에 따르면 `clean`은 `/var/cache/apt/archives/`와 그 하위의 내려받은 패키지 파일을 정리하고 잠금 파일은 남깁니다.

더 이상 필요하지 않은 의존성 패키지는 먼저 시뮬레이션합니다.

```bash
sudo apt-get -s autoremove

```

출력의 제거 대상과 현재 필요한 커널·드라이버·서비스 패키지를 확인한 뒤에만 실제 `autoremove`를 검토합니다. `-s`는 실제 변경 없이 예상 동작을 보여 주는 옵션입니다.

참고: [Ubuntu 24.04 apt-get 공식 매뉴얼](https://manpages.ubuntu.com/manpages/noble/man8/apt-get.8.html?ref=mlog.me)

## 8\. 파일을 지웠는데 df 용량이 줄지 않는 경우

실행 중인 프로세스가 삭제된 파일을 계속 열고 있으면 디렉터리 목록에서는 사라져도 공간이 반환되지 않을 수 있습니다. `lsof`가 설치돼 있다면 다음처럼 확인합니다.

```bash
sudo lsof +L1

```

출력에서 큰 삭제 파일을 잡고 있는 프로세스를 찾은 뒤, 서비스 영향과 재시작 절차를 확인합니다. 공간을 되찾기 위해 서버 전체를 무조건 재부팅하기보다 해당 서비스를 정상적인 방식으로 재시작하는 편이 낫습니다.

## 9\. 안전한 실행 순서

운영 서버에서는 다음 순서를 권장합니다.

1. `df -hT /`와 `df -ih /`로 블록·inode 부족을 구분합니다.
2. `du -xhd1`로 `/var`, `/var/log`, `/var/lib`를 단계적으로 확인합니다.
3. 로그라면 journal과 일반 로그를 분리합니다.
4. Docker라면 `docker system df -v`와 컨테이너·볼륨 목록을 확인합니다.
5. 삭제 대상이 데이터인지 재생성 가능한 캐시인지 구분합니다.
6. 데이터가 포함될 수 있으면 백업과 복원 가능성을 먼저 확인합니다.
7. 범위가 좁고 확인 프롬프트가 있는 정리 명령부터 실행합니다.
8. 실행 전후의 `df`, `du`, 서비스 상태를 기록합니다.
9. 로그 로테이션과 Docker 로깅 제한을 설정해 재발을 막습니다.

백업 파일이 존재하는 것과 실제 복구가 가능한 것은 다릅니다. Ghost나 데이터베이스 볼륨을 정리하기 전에는 [Ghost·MySQL 백업 무결성 확인 방법](https://mlog.me/ghost-mysql-backup-integrity-check/)처럼 체크섬과 복원 절차를 별도로 확인해야 합니다.

## 마무리

`/var/log`가 크면 로그 정책을 확인하고, `/var/lib`가 크면 해당 데이터를 관리하는 서비스를 찾아야 합니다. 같은 `/var` 아래에 있어도 정리 방법은 다릅니다.

가장 중요한 기준은 간단합니다. **경로를 보고 지우지 말고, 데이터를 만든 서비스의 상태와 사용 관계를 확인한 뒤 그 서비스가 제공하는 정리 기능을 사용합니다.** 이 원칙을 지키면 디스크 공간을 확보하면서도 컨테이너 볼륨과 운영 데이터를 보호할 수 있습니다.

외부에서 노출된 관리 포트와 방화벽까지 함께 확인하려면 [서버 외부 포트·방화벽 점검 절차](https://mlog.me/server-security-check-external-ports-firewall/)를 이어서 볼 수 있습니다.

## 공식 자료

- [GNU Coreutils: Disk usage](https://www.gnu.org/software/coreutils/manual/html%5Fnode/Disk-usage.html?ref=mlog.me)
- [systemd: journalctl](https://www.freedesktop.org/software/systemd/man/255/journalctl.html?ref=mlog.me)
- [Ubuntu 24.04: apt-get](https://manpages.ubuntu.com/manpages/noble/man8/apt-get.8.html?ref=mlog.me)
- [Ubuntu 24.04: logrotate](https://manpages.ubuntu.com/manpages/noble/man8/logrotate.8.html?ref=mlog.me)
- [Docker: Prune unused objects](https://docs.docker.com/engine/manage-resources/pruning/?ref=mlog.me)
- [Docker: docker system df](https://docs.docker.com/reference/cli/docker/system/df/?ref=mlog.me)
- [Docker: Configure logging drivers](https://docs.docker.com/engine/logging/configure/?ref=mlog.me)