백업 시스템 장애 시나리오와 자동 복구 전략 | 실전 가이드

## 왜 백업 시스템 모니터링이 중요한가 많은 개발팀이 백업 스크립트를 작성하지만, 정작 **백업이 제대로 동작하는지 확인하는 시스템**은 간과하는 경우가 많습니다. 디스크가 가득 차서 백업이 실패하거나, 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회 복구 테스트 일정 수립 백업은 **복구할 수 있을 때만** 의미가 있습니다. 지금 바로 여러분의 백업 시스템을 점검해보세요.

백업 시스템 장애 시나리오와 자동화된 복구 전략

관련 글

대규모 AI 시스템 저작권 등록 실전 가이드: 기술 문서와 소스코드 제출 전략

ChatGPT Plus vs API 비교

메시지 큐 시스템의 공정한 슬롯 분배 전략: Bot별 리소스 할당 구현기

이 주제에 대해 더 알아보고 싶으신가요?