[Infra Ops] 파일/설정/DB 백업과 재해복구 기초

RTO (Recovery Time Objective)
  장애 발생 후 서비스 복구까지 허용되는 최대 시간
  예: "RTO 4시간" → 장애 후 4시간 이내 서비스 재개 필요

RPO (Recovery Point Objective)
  복구 시 허용 가능한 데이터 손실 기간
  예: "RPO 1시간" → 최대 1시간 치 데이터 손실 감수 가능
       → 1시간마다 백업이 필요하다는 의미

주 1회 Full 백업 (일요일 새벽)
일별 Incremental 백업 (월~토 새벽)
월별 Full 백업 → 별도 장기 보관

보관 정책 예시:
  일별 백업 → 7일 보관
  주별 백업 → 4주 보관
  월별 백업 → 12개월 보관

# 설정 파일 tar 백업 (날짜 포함 파일명)
sudo tar -czf /backup/config_$(date +%Y%m%d).tar.gz \
  /etc/nginx/ \
  /opt/tomcat/conf/ \
  /etc/ssh/sshd_config \
  /etc/systemd/system/

# 백업 파일 확인
ls -lh /backup/config_*.tar.gz

# 백업 내용 목록 확인 (복구 전 검증)
tar -tzf /backup/config_20260530.tar.gz | head -20

# 원격 서버로 애플리케이션 디렉터리 동기화
# --delete: 원본에서 삭제된 파일을 대상에서도 삭제
# -avz: archive(권한/타임스탬프 유지) + verbose + gzip 압축
rsync -avz /opt/app/ backup-server:/backup/app/ --delete

# 설정 파일 원격 백업
rsync -avz /etc/nginx/ backup-server:/backup/nginx-conf/

# SSH 키 인증 사용 (비밀번호 없이 자동 실행)
rsync -avz -e "ssh -i /root/.ssh/backup_key" /opt/app/ backup-server:/backup/app/

# crontab -e 로 추가
# 매일 새벽 2시 설정 파일 백업 + rsync
0 2 * * * tar -czf /backup/config_$(date +\%Y\%m\%d).tar.gz /etc/nginx/ /opt/tomcat/conf/ && rsync -avz /backup/ backup-server:/backup/$(hostname)/

# 7일 지난 로컬 백업 정리: 먼저 목록만 확인하고 보존 정책·승인 후 삭제 절차를 등록합니다.
0 3 * * * find /backup/ -xdev -type f -name "config_*.tar.gz" -mtime +7 -print

# MySQL 전체 DB 무중단 백업 (InnoDB 기준)
mysqldump \
  --single-transaction \
  --all-databases \
  --routines \
  --triggers \
  -u root -p \
  > /backup/mysql_$(date +%Y%m%d_%H%M).sql

# 특정 DB만 백업
mysqldump --single-transaction -u root -p mydb > /backup/mydb_$(date +%Y%m%d).sql

# 압축 저장 (용량 절감)
mysqldump --single-transaction --all-databases -u root -p | gzip > /backup/mysql_$(date +%Y%m%d).sql.gz

# 백업 파일 크기 확인
ls -lh /backup/mysql_*.sql.gz

# SQL 파일에서 복구
mysql -u root -p < /backup/mysql_20260530.sql

# 압축 파일에서 복구
gunzip -c /backup/mysql_20260530.sql.gz | mysql -u root -p

# 특정 DB만 복구
mysql -u root -p mydb < /backup/mydb_20260530.sql

# 복구 후 확인
mysql -u root -p -e "SHOW DATABASES;"
mysql -u root -p mydb -e "SHOW TABLES;"

# pg_dump (PostgreSQL)
pg_dump -U postgres mydb > /backup/postgres_mydb_$(date +%Y%m%d).sql

# 전체 클러스터 백업
pg_dumpall -U postgres > /backup/postgres_all_$(date +%Y%m%d).sql

# 복구
psql -U postgres mydb < /backup/postgres_mydb_20260530.sql

# LVM 스냅샷 (Linux 볼륨 관리자)
# 현재 LVM 구성 확인
lvdisplay
vgdisplay

# 스냅샷 생성 (10GB 용량 할당)
sudo lvcreate -L 10G -s -n data_snap /dev/vg0/data

# 스냅샷을 마운트해서 파일 확인
sudo mkdir /mnt/snap
sudo mount /dev/vg0/data_snap /mnt/snap
ls /mnt/snap/

# 스냅샷 삭제 (더 이상 필요 없을 때)
sudo umount /mnt/snap
sudo lvremove /dev/vg0/data_snap

# EBS 스냅샷 생성 (AWS CLI)
aws ec2 create-snapshot \
  --volume-id vol-12345678 \
  --description "Daily backup $(date +%Y%m%d)"

# 스냅샷 목록 확인
aws ec2 describe-snapshots --owner-ids self

# 오래된 스냅샷 삭제 (30일 이전)
aws ec2 describe-snapshots --owner-ids self \
  --query "Snapshots[?StartTime<='$(date -d '30 days ago' +%Y-%m-%d)'].SnapshotId" \
  --output text | xargs -I {} aws ec2 delete-snapshot --snapshot-id {}

[평상시]
   │
   ① 백업 생성         주기(일·주)·방식(Full·증분·스냅샷)으로 원본을 뜬다
   │                    → 백업 성공 로그 + 무결성(gunzip -t) 확인
   │
   ② 오프사이트 보관    같은 랙·같은 전산실을 벗어난 곳으로 사본을 옮긴다
   │                    (원격 NAS·테이프 반출·타 전산실/타 리전)
   │
   ─ ─ ─ ─ ─ 여기까지가 재해 '전'에 끝나 있어야 한다 ─ ─ ─ ─ ─
   │
   ③ 재해 발생          주 사이트 소실(정전·화재·랜섬웨어) → 원본·로컬백업 동시 상실
   │
   ④ 복구 지점 선택     살아남은 사본 중 어느 시점으로 되돌릴지 고른다 = RPO 결정
   │                    (가장 최근 정상 백업 · 랜섬웨어면 감염 이전 시점)
   │
   ⑤ 복원 · 검증        DR 사이트·새 서버에 복원 → 건수·정합성 확인 후에야 '복구' 인정
   │
   ⑥ 서비스 재개        앱 기동 → 접속정보 전환 → DNS를 DR로 재지정 → 검증 = RTO 종료
   ▼
[정상화]  이 ①~⑥ 전체 시간이 RTO, ④에서 잃은 데이터 폭이 RPO

Active-Passive DR 흐름:
  평상시: 주 센터 운영, 백업 센터에 rsync/복제로 데이터 동기화
  장애시: DNS를 백업 센터 IP로 변경
         → 서비스 재개 (RTO: DNS TTL + 기동 시간)

Active-Active DR 흐름:
  평상시: 두 센터 모두 트래픽 처리 (로드밸런서로 분산)
  장애시: 한 센터 장애 → 자동으로 다른 센터로 100% 전환
         → 서비스 중단 거의 없음 (RTO: 수 초~수 분)

실제 사례:
  백업은 3년간 매일 실행
  → 어느 날 복구 시도
  → mysqldump 파일이 깨져 있음 (디스크 용량 부족으로 중간에 잘린 파일)
  → 실제 복구 불가

예방:
  월 1회 개발환경에서 복구 테스트 실행
  복구 성공 여부를 로그로 기록
  정기 리포트로 백업 상태 모니터링