'docker system prune -a'를 실행해도 안전한가요?

중지된 컨테이너, 사용하지 않는 네트워크, 주인 없는 빌드 캐시, 그리고 실행 중인 컨테이너가 쓰지 않는 모든 이미지를 지웁니다. --volumes를 붙이지 않는 한 데이터는 남습니다. --volumes를 붙이면 사용하지 않는 볼륨도 지워지는데, 중지된 데이터베이스 컨테이너의 볼륨도 미사용으로 취급됩니다. 확신이 없다면 이 플래그는 빼세요.

큰 로그 파일을 지웠는데 df는 여전히 디스크가 꽉 찼다고 합니다. 왜죠?

실행 중인 프로세스가 아직 그 파일을 열어 두고 있어서 커널이 공간을 돌려주지 않는 것입니다. 'lsof +L1'로 찾아서 해당 서비스를 재시작하세요. 다음부터는 사용 중인 로그를 지우지 말고 'truncate -s 0 file'로 비우세요.

여유 공간은 얼마나 남겨 둬야 하나요?

최소 10~15%입니다. 데이터베이스, 패키지 업데이트, Docker pull은 임시 공간이 필요하고, 100% 찬 디스크는 쓰기 도중에 데이터베이스를 망가뜨릴 수 있습니다.

재설치 없이 디스크를 늘릴 수 있나요?

네. 더 큰 요금제로 업그레이드하면 디스크가 그 자리에서 늘어나고 데이터도 유지됩니다. Nano는 15 GB, Micro는 25 GB, Small은 35 GB, Medium은 45 GB입니다. 업그레이드 시 서버가 한 번 재부팅됩니다.

작은 VPS는 보통 무엇으로 가득 차나요?

저희 경험상 Docker 이미지와 빌드 캐시, systemd journal, 아무도 로테이션하지 않는 앱 로그, 그리고 /root에 잊힌 데이터베이스 덤프나 백업 아카이브입니다.

아무것도 망가뜨리지 않고 VPS 디스크 공간 확보하는 법

VPS 디스크가 꽉 찼나요? du와 ncdu로 공간을 차지하는 것을 찾고, 데이터 손실 없이 apt 캐시, journal, Docker 찌꺼기, 로그를 정리하세요.

"No space left on device"는 절대 좋은 타이밍에 오지 않습니다. 데이터베이스는 쓰기를 받지 않고, apt는 업그레이드를 끝내지 못하고, Docker는 지금 꼭 필요한 바로 그 이미지를 pull하지 않습니다. 다행히 작은 VPS에서는 범인이 거의 항상 다섯 가지 중 하나이고, 2분이면 찾을 수 있습니다.

1. 얼마나 심각한가?

df -h /
df -i /

첫 줄은 사용 중인 공간을 보여 줍니다. 두 번째 줄은 inode입니다. 공간은 괜찮아 보이는데 inode가 100%라면 수백만 개의 작은 파일(세션 파일, 메일 큐, 캐시 디렉터리)이 있다는 뜻입니다. 문제는 다르지만 증상은 같습니다.

2. 큰 것을 찾기

트리를 위에서부터 훑으며 크기순으로 정렬합니다.

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x는 하나의 파일 시스템 안에만 머물러서 /proc으로 헤매지 않습니다. 그다음 가장 큰 곳으로 파고드세요. 대화형으로 둘러보려면 ncdu가 훨씬 편합니다.

apt install -y ncdu
ncdu -x /

화살표 키로 이동, d로 삭제합니다. 마지막 키는 조심하세요.

3. 바로 효과 보는 정리

아래 명령은 어떤 Ubuntu나 Debian 서버에서도 안전합니다.

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove는 오래된 커널도 정리합니다. 많은 사람이 놀라는 건 systemd journal입니다. 그냥 두면 몇 GB까지 불어납니다. 영구적으로 제한하려면 /etc/systemd/journald.conf에 SystemMaxUse=200M을 설정하고 systemctl restart systemd-journald를 실행하세요.

4. Docker 찌꺼기

Docker를 쓴다면 여기부터 보세요. 오래된 이미지와 빌드 캐시는 배포할 때마다 쌓입니다.

docker system df
docker image prune -a
docker builder prune

docker image prune -a는 실행 중인 어떤 컨테이너도 쓰지 않는 이미지를 지웁니다. 대개 원하는 결과지만, 다음 배포 때 다시 pull됩니다.

위험한 건 docker system prune -a --volumes입니다. 볼륨에는 데이터가 들어 있고, 중지된 컨테이너에 연결된 볼륨은 미사용으로 간주됩니다. 이렇게 데이터베이스를 날리는 사람이 있습니다. 포럼 답변에서 복사해 붙여 넣지 마세요.

또 하나의 숨은 공간 도둑은 컨테이너 로그입니다. /etc/docker/daemon.json에서 제한하세요.

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

그런 다음 Docker를 재시작합니다. 이 제한은 이후에 만든 컨테이너에만 적용되므로, 로그를 많이 쓰는 컨테이너는 docker compose up -d --force-recreate로 다시 만드세요.

5. 로그와 잊힌 파일

디스크 어디든 큰 파일을 찾습니다.

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

흔히 나오는 것들: /root에 있는 반년 전 backup.tar.gz, 누군가 내려받으려던 데이터베이스 덤프, 한 번도 로테이션되지 않은 앱 로그.

서비스가 아직 쓰고 있는 로그는 rm으로 지우지 말고 비우세요.

truncate -s 0 /var/log/myapp/app.log

이미 지웠는데 공간이 돌아오지 않았다면, 어떤 프로세스가 아직 파일을 열어 두고 있는 것입니다.

lsof +L1

거기 나오는 서비스를 재시작하면 공간이 돌아옵니다.

정리만으로 부족할 때

데이터가 정말로 필요한 경우도 있습니다. 계속 커지는 데이터베이스, 사용자 업로드, 모델 파일. 그럴 때 정직한 해결책은 디스크를 늘리는 것입니다. 요금제를 업그레이드하면 디스크가 그 자리에서 늘어나고 모든 것이 유지됩니다. Nano는 15 GB, Micro는 25 GB, Small은 35 GB, Medium은 45 GB입니다. 서버는 한 번 재부팅됩니다. 자세한 내용은 요금제 문서에 있습니다.

조용히 공간을 먹는 게 하나 더 있습니다. swap 파일입니다. swap 가이드를 따랐다면 그 1~2 GB는 일부러 잡아 둔 것입니다. Docker가 가장 큰 소비자라면 Docker 설치 가이드와 Compose 스택 가이드에서 이미지가 불어나지 않게 관리하는 법을 소개합니다.

이 모든 걸 막는 습관: 첫날부터 journal과 Docker 로그에 상한을 거세요. 설정 두 줄이면 "디스크 꽉 참"은 거의 일어나지 않습니다.