sam-api/public/develop/disaster-recovery-plan.md

🔥 재해복구(DR) 계획서

1. 개요 및 목적

1.1 문서 목적

• 시스템 장애 발생 시 신속한 복구를 위한 체계적인 절차 수립
• 데이터 손실 최소화 및 서비스 연속성 보장
• 비상 상황 대응 프로세스 표준화

1.2 적용 범위

• 대상 시스템: 운영 서버 A/B, DB Master/Slave, 개발 서버
• 대상 서비스: 웹 애플리케이션, API, 데이터베이스
• 관련 팀: 개발팀, 인프라팀, 운영팀

---

2. 복구 목표 설정

2.1 RTO/RPO 목표

구분	목표 시간	설명
RTO (Recovery Time Objective)	4시간	장애 발생 후 서비스 정상화까지 목표 시간
RPO (Recovery Point Objective)	1시간	허용 가능한 최대 데이터 손실 시간

2.2 서비스별 우선순위

우선순위	서비스	RTO	RPO	비고
P0 (Critical)	결제 시스템	1시간	0분	실시간 백업
P1 (High)	사용자 인증	2시간	30분	핵심 기능
P2 (Medium)	API 서비스	4시간	1시간	일반 서비스
P3 (Low)	통계/리포트	8시간	4시간	비핵심 기능

---

3. 재해 시나리오 및 대응 전략

3.1 시나리오별 대응 방안

🔴 시나리오 1: 단일 서버 장애

상황: 운영 서버 A 또는 B 중 1대 장애

대응 절차:
1. 로드밸런서에서 장애 서버 제외 (자동)
2. 정상 서버로 모든 트래픽 라우팅
3. 장애 서버 재시작 시도
4. 복구 실패 시 새 인스턴스 생성
5. 서비스 정상화 확인

예상 복구 시간: 5분 (자동) ~ 30분 (수동)

🔴 시나리오 2: 데이터베이스 장애

상황: DB Master 장애 발생

대응 절차:
1. DB 모니터링 알람 감지
2. Slave DB를 Master로 승격
3. 애플리케이션 DB 연결 정보 변경
4. 기존 Master 복구 또는 재구축
5. 새로운 Slave 구성

예상 복구 시간: 30분 ~ 1시간

🔴 시나리오 3: 네트워크 장애

상황: 클라우드 리전 전체 네트워크 장애

대응 절차:
1. DR 사이트 활성화 (IDC 백업 서버)
2. DNS 전환 (TTL 5분)
3. 백업 데이터로 서비스 구동
4. 임시 운영 모드 전환
5. 주 사이트 복구 시 데이터 동기화

예상 복구 시간: 1시간 ~ 2시간

🔴 시나리오 4: 랜섬웨어/보안 침해

상황: 악성코드 감염 또는 보안 침해

대응 절차:
1. 감염 시스템 즉시 격리
2. 네트워크 차단
3. 클린 백업에서 복구
4. 보안 패치 적용
5. 침해 분석 및 보고서 작성

예상 복구 시간: 4시간 ~ 8시간

3.2 데이터 백업 전략

백업 정책

백업 유형	주기	보관 기간	저장 위치	자동화
전체 백업	주 1회 (일요일)	3개월	IDC 백업서버	✅
증분 백업	일 1회 (새벽 2시)	1개월	클라우드 스토리지	✅
실시간 복제	지속	-	DB Slave	✅
스냅샷	4시간마다	7일	클라우드 스냅샷	✅

백업 스크립트 예시

#!/bin/bash
# Daily Backup Script
DATE=$(date +%Y%m%d)
BACKUP_DIR="/backup/daily/${DATE}"

# Database Backup
mysqldump -h 10.0.2.20 -u backup -p$DB_PASS \
  --all-databases --single-transaction \
  > ${BACKUP_DIR}/db_backup.sql

# Application Files Backup
tar -czf ${BACKUP_DIR}/app_backup.tar.gz \
  /var/www/html

# Upload to Remote Storage
rsync -avz ${BACKUP_DIR}/ \
  backup@172.16.1.11:/central-backup/

# Verify Backup
if [ $? -eq 0 ]; then
  echo "Backup successful: ${DATE}"
  # Send success notification
else
  echo "Backup failed: ${DATE}"
  # Send alert
fi

---

4. 복구 절차서

4.1 웹 서버 복구

## 웹 서버 복구 체크리스트
- [ ] 1. 장애 서버 상태 확인
- [ ] 2. 로드밸런서에서 제외 확인
- [ ] 3. 새 인스턴스 생성 (필요시)
- [ ] 4. Docker 환경 구성
- [ ] 5. 최신 이미지 Pull
- [ ] 6. 환경 변수 설정 (.env)
- [ ] 7. 컨테이너 실행
- [ ] 8. Health Check 확인
- [ ] 9. 로드밸런서 재등록
- [ ] 10. 모니터링 확인

4.2 데이터베이스 복구

## DB 복구 체크리스트
- [ ] 1. 백업 파일 확인 (최신 시점)
- [ ] 2. 새 DB 인스턴스 준비
- [ ] 3. 백업 데이터 복원
  ```sql
  mysql -u root -p < backup.sql

• 4. 데이터 정합성 검증
• 5. Replication 재설정
• 6. 애플리케이션 연결 테스트
• 7. 성능 테스트
• 8. 모니터링 설정

### 4.3 전체 시스템 복구 (Full DR)

```markdown
## 전체 시스템 복구 순서
1. **네트워크 인프라** (10분)
   - [ ] VPC/Subnet 구성
   - [ ] Security Group 설정
   - [ ] Load Balancer 생성

2. **컴퓨팅 리소스** (20분)
   - [ ] EC2 인스턴스 생성
   - [ ] Docker 설치
   - [ ] 기본 패키지 설치

3. **데이터 복원** (30분)
   - [ ] 최신 백업 확인
   - [ ] DB 복원
   - [ ] 파일 시스템 복원

4. **애플리케이션 배포** (20분)
   - [ ] 컨테이너 이미지 Pull
   - [ ] 환경 설정
   - [ ] 서비스 시작

5. **검증 및 전환** (20분)
   - [ ] 서비스 테스트
   - [ ] DNS 전환
   - [ ] 모니터링 확인

---

5. 비상 연락망

5.1 에스컬레이션 매트릭스

레벨	담당자	역할	연락처	대응 시간
L1	운영팀	1차 대응	010-xxxx-xxxx	24/7
L2	인프라팀장	인프라 복구	010-xxxx-xxxx	15분 이내
L3	개발팀장	애플리케이션 복구	010-xxxx-xxxx	30분 이내
L4	CTO	최종 의사결정	010-xxxx-xxxx	1시간 이내

5.2 외부 지원 연락처

구분	업체명	담당자	연락처	계약 SLA
클라우드	호스팅사	기술지원	1544-xxxx	4시간
IDC	코로케이션	24시간 NOC	02-xxxx-xxxx	2시간
보안	보안업체	CERT팀	02-xxxx-xxxx	1시간

---

6. 복구 테스트 계획

6.1 정기 DR 훈련

훈련 유형	주기	범위	소요 시간
Table Top	분기 1회	시나리오 검토	2시간
부분 복구	반기 1회	단일 시스템	4시간
전체 복구	연 1회	전체 시스템	8시간

6.2 테스트 시나리오

## DR 테스트 시나리오 예시
1. **준비 단계** (30분)
   - 테스트 환경 격리
   - 백업 확인
   - 팀 준비 상태 확인

2. **장애 시뮬레이션** (10분)
   - Production 서버 A 강제 종료
   - DB Master 연결 차단

3. **복구 실행** (60분)
   - 절차서에 따른 복구
   - 시간 측정
   - 이슈 기록

4. **검증** (30분)
   - 서비스 정상 동작 확인
   - 데이터 정합성 검증
   - 성능 테스트

5. **원복** (30분)
   - 원래 상태로 복구
   - 테스트 데이터 정리

6. **리뷰** (60분)
   - 결과 분석
   - 개선점 도출
   - 문서 업데이트

---

7. 복구 후 조치사항

7.1 Post-Incident 체크리스트

• 즉시 조치 (1시간 이내)

  • 서비스 정상화 공지
  • 임시 조치사항 문서화
  • 긴급 패치 적용

• 단기 조치 (24시간 이내)

  • 장애 보고서 작성
  • 근본 원인 분석 (RCA)
  • 임시 조치 → 영구 조치 전환

• 장기 조치 (1주일 이내)

  • 재발 방지 대책 수립
  • 프로세스 개선
  • 교육/훈련 계획

7.2 장애 보고서 템플릿

# 장애 보고서

## 1. 장애 개요
- **발생 일시**: 2025-XX-XX HH:MM
- **복구 일시**: 2025-XX-XX HH:MM
- **영향 범위**: 
- **심각도**: P0 / P1 / P2 / P3

## 2. 타임라인
| 시간 | 내용 |
|------|------|
| HH:MM | 장애 감지 |
| HH:MM | 1차 대응 시작 |
| HH:MM | 원인 파악 |
| HH:MM | 복구 작업 시작 |
| HH:MM | 서비스 정상화 |

## 3. 근본 원인
- 

## 4. 대응 내역
- 

## 5. 개선 사항
- [ ] Action Item 1
- [ ] Action Item 2
- [ ] Action Item 3

## 6. 교훈 (Lessons Learned)
- 

---

8. 부록

8.1 주요 명령어 모음

# 서버 상태 확인
docker ps -a
systemctl status nginx
netstat -tlnp

# DB 상태 확인
mysql -e "SHOW SLAVE STATUS\G"
mysql -e "SHOW PROCESSLIST"

# 백업/복원
tar -xzf backup.tar.gz -C /restore/
mysql < backup.sql

# 네트워크 진단
ping -c 4 10.0.1.10
traceroute 10.0.1.10
nslookup domain.com

# 로그 확인
tail -f /var/log/nginx/error.log
docker logs container_name
journalctl -u docker -f

8.2 유용한 도구

도구	용도	URL/명령어
htop	시스템 모니터링	htop
netdata	실시간 모니터링	http://server:19999
mysqltuner	DB 성능 분석	perl mysqltuner.pl
docker stats	컨테이너 모니터링	docker stats

8.3 참고 문서

• AWS Disaster Recovery Whitepaper
• MySQL Replication Best Practices
• Docker Swarm DR Guide
• Laravel Backup Package Documentation

---

문서 버전: v1.0
최종 수정일: 2025-01-XX
다음 검토일: 2025-04-XX
담당자: 인프라팀