• 서버 장애의 은근한 1순위는 디스크 용량 부족입니다.
• 로그, 캐시, 오래된 백업, Docker 잔여 데이터가 단골 원인입니다.
• 임계치 초과 시 자동 정리 + 로그 기록 구조가 안전합니다.
• 삭제 전/후 용량 비교를 반드시 남겨야 합니다.
• 필요하면 시놀로지 챗/슬랙 알림까지 확장 가능합니다.

1️⃣ 문제 상황 (실제 운영에서 가장 흔한 케이스)

디스크가 100% 가까워지면 이런 일이 벌어집니다.

• 워드프레스 업로드 실패
• DB 쓰기 오류 → 서비스 중단
• 로그 기록 중단 → 원인 추적 불가
• Docker 컨테이너 갑자기 종료
• MySQL InnoDB write error

특히 무서운 건:

디스크 95% → 느려짐
100% → 바로 장애

CPU 문제보다 더 갑작스럽습니다.

2️⃣ 내 환경 (예시)

• Ubuntu 22.04
• Docker 사용
• 워드프레스 + MariaDB
• / 파티션 단일 구조
• 정기 백업 폴더 존재

※ 파티션이 분리되어 있으면 TARGET_MOUNT를 조정해야 합니다.

3️⃣ 1차 가설

느려질 때 CPU를 의심하지만,
top을 보면 CPU는 널널하고 wa(iowait)가 증가하는 경우가 많습니다.

확인 루틴:

df -h

90% 이상이면 거의 확실히 원인 후보입니다.

4️⃣ 자동 정리 전략 (안전하게)

❌ 무조건 삭제
❌ rm -rf 기반 강제 정리

실무에서 안전한 방식은 다음과 같습니다.

1. 디스크 사용량 확인
2. 임계치(예: 80%) 초과 시에만 실행
3. 삭제 목록 로그 기록
4. 정리 후 사용량 재확인
5. 로그 파일 유지

핵심은:

“정리했더니 얼마나 줄었는지” 기록하는 것

5️⃣ 자동 정리 스크립트

파일 생성:

sudo nano /usr/local/bin/disk_cleanup.sh

아래 내용 붙여넣기:

#!/bin/bash
set -eTARGET_MOUNT="/"
THRESHOLD=80LOG_DIR="/var/log/howinfo"
LOG_FILE="${LOG_DIR}/disk_cleanup.log"DAYS_LOG=14
DAYS_TMP=7
DAYS_BACKUP=30BACKUP_DIR="/backup/daily"mkdir -p "$LOG_DIR"log() {
  echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}usage_percent() {
  df -P "$TARGET_MOUNT" | awk 'NR==2 {gsub("%","",$5); print $5}'
}log "=== 디스크 정리 시작 ==="
BEFORE=$(usage_percent)
log "정리 전 사용량: ${BEFORE}% (기준: ${THRESHOLD}%)"if [ "$BEFORE" -lt "$THRESHOLD" ]; then
  log "임계치 미만 → 정리하지 않음"
  log "=== 종료 ==="
  exit 0
filog "임계치 초과 → 정리 실행"if command -v apt-get >/dev/null 2>&1; then
  apt-get -y autoclean || true
  apt-get -y clean || true
fiif command -v journalctl >/dev/null 2>&1; then
  journalctl --vacuum-time=7d || true
fifind /var/log -type f -name "*.gz" -mtime +"$DAYS_LOG" -print -delete | tee -a "$LOG_FILE" || true
find /tmp -type f -mtime +"$DAYS_TMP" -print -delete | tee -a "$LOG_FILE" || trueif command -v docker >/dev/null 2>&1; then
  docker system prune -f || true
  docker volume prune -f || true
fiif [ -d "$BACKUP_DIR" ]; then
  find "$BACKUP_DIR" -type f -mtime +"$DAYS_BACKUP" -print -delete | tee -a "$LOG_FILE" || true
fiAFTER=$(usage_percent)
log "정리 후 사용량: ${AFTER}%"
log "=== 디스크 정리 완료 ==="

권한 부여:

sudo chmod +x /usr/local/bin/disk_cleanup.sh

6️⃣ 수동 테스트 (반드시 먼저)

sudo /usr/local/bin/disk_cleanup.sh

로그 확인:

tail -n 50 /var/log/howinfo/disk_cleanup.log

삭제 내역과 전/후 % 확인이 핵심입니다.

7️⃣ 자동 실행 (crontab)

sudo crontab -e

추가:

0 3 * * * /usr/local/bin/disk_cleanup.sh

→ 매일 새벽 3시 검사

임계치 미만이면 아무 작업도 하지 않습니다.

8️⃣ 더 안전하게 쓰는 방법

1️⃣ 드라이런 모드

삭제 대신 목록만 보기:

find /var/log -type f -name "*.gz" -mtime +14 -print

2️⃣ 임계치 조정

THRESHOLD=90

너무 자주 돌면 올려도 됩니다.

9️⃣ 재발 방지 구조 (진짜 중요)

자동 정리만으로 끝나면 안 됩니다.

✔ 디스크 80% 이상 알림 설정
✔ Docker 로그 max-size 설정
✔ 백업 보관 정책 명확화
✔ 업로드 디렉토리 주기 점검
✔ DB 용량 성장 추적

🔟 장애 사례에서 배운 교훈

• 디스크는 95%부터 체감 저하 시작
• 100% 되면 장애가 아니라 “즉시 중단”
• 자동 정리는 “응급조치”
• 근본 원인은 로그 폭증/백업 정책 부재

체크리스트

• 수동 실행 테스트 완료
• 로그 생성 확인
• 임계치 설정 확인
• crontab 등록 완료
• 다음날 자동 실행 로그 확인

확장 (선택)

원하면 아래도 추가 가능합니다.

• 사용량 85% 이상 시 시놀로지 챗 알림
• Slack Webhook 연동
• n8n으로 모니터링 + 자동 조치
• 특정 파티션 개별 감시

게시물 서버 “용량 부족” 알림 + 자동 정리까지 한 번에 구축하기이 하우인포-IT·테크에 처음 등장했습니다.