## 왜 백업 시스템 모니터링이 중요한가
많은 개발팀이 백업 스크립트를 작성하지만, 정작 **백업이 제대로 동작하는지 확인하는 시스템**은 간과하는 경우가 많습니다. 디스크가 가득 차서 백업이 실패하거나, 0바이트 파일만 생성되어도 모르고 지나가는 경우가 발생합니다. 이 글에서는 실제 운영 환경에서 발생할 수 있는 백업 장애 시나리오와 자동화된 대응 전략을 소개합니다.
## 주요 장애 시나리오와 위험도 분석
### 1. 디스크 공간 부족 (Critical)
가장 흔하면서도 치명적인 문제입니다. 백업 파일이 계속 쌓이면서 디스크 사용률이 100%에 도달하면 시스템 전체가 멈출 수 있습니다.
**자동 탐지 방법:**
- 80% 도달 시 경고
- 90% 도달 시 긴급 알림 및 자동 조치
**자동 복구 로직:**
```bash
if [ $DISK_USAGE -gt 90 ]; then
# 시간별 백업 보관 기간 축소: 7일 → 3일
find /backup/hourly -mtime +3 -delete
# 일별 백업 보관 기간 축소: 30일 → 14일
find /backup/daily -mtime +14 -delete
# 관리자에게 텔레그램/슬랙 알림
fi
```
### 2. 0바이트 백업 파일 생성 (Critical)
백업 프로세스가 오류로 중단되었지만 파일은 생성되어 "성공한 것처럼" 보이는 경우입니다.
**자동 탐지 방법:**
```bash
# 백업 직후 파일 크기 확인
if [ ! -s "$BACKUP_FILE" ]; then
echo "ERROR: 0-byte backup detected"
rm "$BACKUP_FILE" # 잘못된 파일 삭제
exit 1 # 실패로 기록
fi
```
### 3. 네트워크 장애 (Medium)
원격 서버로 백업 전송 중 연결이 끊어지는 경우입니다.
**복구 전략:**
- `rsync`의 `--partial` 옵션 활용으로 중단된 지점부터 재개
- 재시도 로직 구현 (3회 시도, 지수 백오프)
### 4. Cron 작업 실패 (Medium)
Cron 데몬 문제나 스크립트 권한 오류로 백업이 실행되지 않는 경우입니다.
**자동 탐지:**
```bash
# 백업 간격 검증 (2시간 이상 공백 시 알림)
LAST_BACKUP=$(find /backup -type f -mmin -120)
if [ -z "$LAST_BACKUP" ]; then
send_alert "2시간 이상 백업 없음"
fi
```
### 5. 중복 프로세스 실행 (Medium)
이전 백업이 끝나기 전에 다음 백업이 시작되어 충돌이 발생하는 경우입니다.
**방지 방법:**
```bash
# Lock 파일을 이용한 중복 실행 방지
LOCK_FILE="/var/lock/backup.lock"
if [ -f "$LOCK_FILE" ]; then
echo "Backup already running"
exit 1
fi
trap "rm -f $LOCK_FILE" EXIT
touch "$LOCK_FILE"
```
## 통합 모니터링 시스템 구축
### 30분 간격 헬스체크 스크립트
모든 체크를 하나의 모니터링 스크립트로 통합하여 Cron으로 실행합니다.
**주요 체크 항목:**
1. 디스크 사용률 확인
2. 0바이트 파일 탐지
3. 백업 공백 기간 검증
4. 원격 서버 연결 상태
5. 동기화 상태 확인
**Cron 설정 예시:**
```cron
*/30 * * * * /usr/local/bin/backup_monitor.sh
```
## 백업 스크립트 안전장치 구현
### 시간별 백업 스크립트 개선 사항
```bash
#!/bin/bash
set -euo pipefail # 오류 발생 시 즉시 종료
# 1. Lock 파일 체크
# 2. 디스크 공간 사전 확인
# 3. 백업 실행
# 4. 파일 크기 검증
# 5. 체크섬 생성
# 6. 오래된 백업 정리
# 7. Lock 파일 제거
```
## 실전 적용 팁
### 알림 채널 구성
- **경고(Warning)**: 로그 기록만
- **중요(Critical)**: 텔레그램/슬랙 실시간 알림
- **긴급(Emergency)**: SMS 발송
### 보관 정책 예시
- 시간별 백업: 7일 보관 (디스크 부족 시 3일로 자동 축소)
- 일별 백업: 30일 보관 (긴급 시 14일로 축소)
- 주별 백업: 90일 보관
- 월별 백업: 1년 보관
### 테스트 전략
1. **복구 테스트**: 월 1회 실제 백업에서 복구 시도
2. **장애 시뮬레이션**: 디스크 부족 상황 강제 생성
3. **알림 테스트**: 모니터링 알림이 제대로 도착하는지 확인
## 결론
백업 시스템은 "만들어놓고 끝"이 아니라 **지속적으로 모니터링하고 검증**해야 합니다. 이 글에서 소개한 5가지 주요 장애 시나리오와 자동화 전략을 적용하면:
- 디스크 부족으로 인한 시스템 장애 사전 방지
- 0바이트 백업 같은 "조용한 실패" 즉시 탐지
- 네트워크 장애 시 자동 재시도로 복구율 향상
**다음 단계:**
1. 현재 백업 시스템에 헬스체크 스크립트 추가
2. 알림 채널 구성 (텔레그램/슬랙 웹훅)
3. 월 1회 복구 테스트 일정 수립
백업은 **복구할 수 있을 때만** 의미가 있습니다. 지금 바로 여러분의 백업 시스템을 점검해보세요.