0️⃣ 상단 요약 5줄
- 서버 장애의 은근한 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 기반 강제 정리
실무에서 안전한 방식은 다음과 같습니다.
- 디스크 사용량 확인
- 임계치(예: 80%) 초과 시에만 실행
- 삭제 목록 로그 기록
- 정리 후 사용량 재확인
- 로그 파일 유지
핵심은:
“정리했더니 얼마나 줄었는지” 기록하는 것
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으로 모니터링 + 자동 조치
- 특정 파티션 개별 감시
이 글이 도움이 되었나요?좋아요/추천은 다시 누르면 취소됩니다.
