디스크 공간: 어디로 가는가

공간 부족은 겉으로는 전혀 다른 문제처럼 보이는 장애입니다. 데이터베이스가 쓰기를 못 하고, 사이트가 오류를 반환하고, 컨테이너가 재시작되죠. VDS 디스크는 엔트리 티어 기준 40 GB에서 최상위 티어 기준 250 GB까지인데, 거의 항상 같은 것들로 가득 찹니다.

첫 명령어

df -h
df -i
sudo du -x -h -d1 / | sort -h | tail -15

df -i를 건너뛰지 마세요. 공간은 남아 있는데 inode가 부족할 수 있고, 그러면 여유 기가바이트가 있는데도 “디스크 가득 참”이 뜹니다. 원인은 보통 수백만 개의 작은 캐시 파일이에요.

그다음 가장 큰 디렉터리를 파고들어 보세요:

sudo du -x -h -d1 /var | sort -h | tail
sudo du -x -h -d1 /var/lib | sort -h | tail

-x 플래그는 집계를 하나의 파일시스템 안으로 제한하고, 마운트된 디렉터리로 넘어가지 않게 해줍니다.

흔한 원인

삭제했는데도 공간을 차지하는 파일

전형적인 수수께끼입니다. du는 5 GB를 보여주는데 df는 30 GB 사용 중이라고 하죠. 이는 파일이 삭제되었지만 어떤 프로세스가 아직 열어 두고 있어서, 재시작 전까지 공간이 해제되지 않는다는 뜻입니다.

sudo lsof +L1 | head -20

출력에 프로세스와 크기가 표시됩니다. 해결책은 원인 프로세스를 재시작하는 거예요:

sudo systemctl restart <service>
docker compose restart <service>

사용 중인 로그 파일을 rm으로 지워서 공간을 확보하지 마세요. 올바른 방법은 잘라내는 겁니다: sudo truncate -s 0 /var/log/big.log. 삭제하면 공간은 계속 차지한 채로 남고 로그도 잃게 됩니다.

제어판의 사용량 링

“개요” 탭에 디스크 사용량 링이 있습니다. 이는 게스트 에이전트 qemu-guest-agent를 통해 계산됩니다. 에이전트가 제거되었거나 실행되지 않으면 데이터가 갱신되지 않고, 제어판에 설치 명령어가 표시됩니다. 머신 내부에서 확인하려면:

systemctl status qemu-guest-agent

에이전트의 측정값과 df -h는 일치해야 합니다. 차이가 나는 경우는 대개 별도로 마운트된 파티션에 일부 공간이 잡혀 있다는 뜻입니다. 파티션과 파일시스템을 참고하세요.

예방

정리와 알림을 위한 예약 작업을 설정하세요:

#!/bin/bash
USED=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$USED" -gt 85 ]; then
  journalctl --vacuum-size=200M
  apt clean
  docker image prune -f
  echo "Disk is ${USED}% full" | mail -s "VDS: low disk space" you@example.com
fi

85% 임계값이면 대응할 여유가 생깁니다. 100%까지 기다릴 수는 없어요. 디스크가 가득 차면 일부 서비스는 무슨 일이 있었는지 로그조차 쓰지 못합니다.

공간이 전혀 없을 때

1. 빠른 조치로 몇 기가바이트를 확보하세요: journalctl --vacuum-size=100M, apt clean, docker builder prune -f.
2. 위 명령어로 진짜 원인을 찾으세요. 그러지 않으면 일주일 뒤에 똑같이 반복됩니다.
3. 데이터가 정말로 늘어났다면 더 높은 티어로 이동해서 디스크를 증설해야 합니다. 다운그레이드는 불가능합니다. 디스크는 줄일 수 없어요.