서버 디스크 용량 부족은 갑자기 보이지만, 대부분은 오래 쌓인 로그에서 시작됩니다. 병원 홈페이지가 느려지거나 접속이 불안정할 때 CPU보다 디스크부터 봐야 하는 경우가 많습니다.
실제로 새벽에 홈페이지 접속 불가 신고를 받고 확인했더니 특정 파티션 사용률이 100%였습니다. nginx access 로그가 logrotate 없이 수개월치 쌓였고, MySQL slow query log도 비활성화를 놓쳐 커져 있었습니다. 서버 디스크 용량 부족은 작은 관리 누락이 누적된 결과였습니다.
먼저 현재 상태를 확인합니다. 운영 서버의 실제 경로나 내부 정보는 외부에 공유하지 말고, 아래처럼 일반적인 명령 구조만 참고하면 됩니다.
df -h
du -sh [log-directory]/*
사용률이 100%라면 무작정 파일을 지우기보다 오래된 로그를 압축하거나 별도 보관 위치로 이동합니다. DB 파일, 업로드 파일, 설정 파일은 임의 삭제하면 복구가 더 어려워질 수 있습니다.
서버 디스크 용량 부족 상태에서는 새 로그도 쓰이지 않아 원인 파악이 어려워질 수 있습니다. 그래서 우선 최소 여유 공간을 확보한 뒤 원인을 봐야 합니다.
logrotate는 로그를 주기적으로 분리하고 오래된 파일을 압축해줍니다. 아래는 예시이며, 실제 파일명과 경로는 서버 구성에 맞게 바꿔야 합니다.
[web-access-log] {
daily
rotate 14
compress
missingok
notifempty
sharedscripts
postrotate
systemctl reload nginx >/dev/null 2>&1 || true
endscript
}
핵심은 주기와 보존 기간을 정하는 것입니다. 병원 서버마다 제각각 두면 관리가 어려우니 14일, 30일처럼 기준을 정해 문서화합니다.
서버 디스크 용량 부족은 알림만 있어도 대부분 장애 전에 잡을 수 있습니다. 저는 사용률 80% 초과 시 이메일 알림이 오도록 cron에 등록했습니다.
#!/bin/bash
LIMIT=80
USED=$(df -P / | awk 'NR==2 {gsub("%","",$5); print $5}')
if [ "$USED" -ge "$LIMIT" ]; then
echo "Disk usage is ${USED}%" | mail -s "Disk warning" admin@example.com
fi
운영에서는 루트 파티션뿐 아니라 로그, 업로드, DB가 있는 파티션을 각각 확인해야 합니다. 메일이 어렵다면 Slack, 문자, 모니터링 도구 등 팀에서 실제로 보는 채널을 쓰면 됩니다.
서버 디스크 용량 부족을 막으려면 용량 증설보다 정리 기준이 먼저입니다. 어떤 로그를 며칠 보관할지, 어떤 파일은 압축할지, 임계값은 몇 퍼센트로 볼지 정해야 합니다.
정리하면 긴급 대응은 큰 로그 확인, 압축 또는 이동, logrotate 적용 순서입니다. 예방은 80% 알림, 보존 기간 통일, 월 1회 점검표 기록입니다. 이 세 가지만 있어도 새벽 장애 대응 가능성이 크게 줄어듭니다.
AI가 초안을 생성하고, 의료기관 인프라 운영자가 1차 데이터 기반으로 최종 검수·승인합니다.
작성·검수: WavePix 운영자 (의료기관 3곳 인프라 전담)