Summary
AWS 패치 작업 전 수동 백업은 서비스 중단 및 데이터 손실 위험을 최소화하기 위한 필수 절차입니다. EC2, RDS, EBS 등 각 서비스별로 적절한 백업 방법을 사용하여 패치 전 현재 상태를 안전하게 보존하고, 문제 발생 시 빠른 복원이 가능하도록 준비해야 합니다.
Details
1. EC2 인스턴스 수동 백업
1-1) AMI(Amazon Machine Image) 생성
- EC2 콘솔 접속: AWS Management Console → EC2 서비스
- 인스턴스 선택: 백업할 인스턴스 선택
- AMI 생성: 작업 → 이미지 및 템플릿 → 이미지 생성
- AMI 설정:
> 이미지 이름: 패치 날짜 포함 (예: myserver-patch-20251212)
> 이미지 설명: 패치 전 백업 목적 명시
> 재부팅 안 함: 서비스 중단 최소화 (권장)
> 인스턴스 스토어 볼륨: 제외 또는 포함 선택
1-2) EBS 스냅샷 생성
1-2-1) AWS 콘솔에서 생성
1. EC2 콘솔 → Elastic Block Store → Volumes
2. 백업할 볼륨 선택 → Actions → Create snapshot
3. 설명 입력 → Create snapshot
# 특정 볼륨의 스냅샷 생성
aws ec2 create-snapshot \
--volume-id vol-1234567890abcdef0 \
--description "Pre-patch backup $(date +%Y%m%d-%H%M%S)"
# 모든 연결된 볼륨의 스냅샷 생성
aws ec2 describe-instances \
--instance-ids i-1234567890abcdef0 \
--query 'Reservations[].Instances[].BlockDeviceMappings[].Ebs.VolumeId' \
--output text | xargs -I {} sh -c 'aws ec2 create-snapshot --volume-id {} --description "Pre-patch backup $(date +%Y%m%d-%H%M%S)"'
2. RDS 수동 백업
DB 스냅샷 생성
1. RDS 콘솔 접속: AWS Management Console → RDS 서비스
2. 데이터베이스 선택: 백업할 DB 인스턴스 선택
3. 스냅샷 생성: 작업 → 스냅샷 생성
4. 스냅샷 설정:
- 스냅샷 식별자: db-patch-backup-20251212
- 설명: 패치 전 백업 명시
CLI를 통한 RDS 백업
# 단일 DB 인스턴스 스냅샷
aws rds create-db-snapshot \
--db-instance-identifier mydb-instance \
--db-snapshot-identifier mydb-backup-$(date +%Y%m%d-%H%M%S)
# RDS 클러스터 백업
aws rds create-db-cluster-snapshot \
--db-cluster-identifier mydb-cluster \
--db-cluster-snapshot-identifier mydb-cluster-backup-$(date +%Y%m%d-%H%M%S)
3. AWS Backup을 이용한 통합 백업
3-1. On-Demand 백업 생성(ECS, RDS, EFS)
3-1-1) AWS Backup 콘솔 접속: AWS Management Console → AWS Backup
3-1-2) Protected Resources: 보호된 리소스 → Create on-demand backup
3--13) 백업 설정:
- Resource type: EC2, RDS, EFS 등 선택
- Resource ID: 백업할 리소스 선택
- Backup vault: 백업 저장소 지정
- Backup window: 백업 수행 시간 설정
- Lifecycle: 백업 보존 정책
3-2. On-Demand 백업 생성(EKS - 2025. 11 신규 추가)
3-2-1) AWS Backup 콘솔 접속
• AWS Backup → Create an on-demand backup
3-2-2) 리소스 선택
• Resource type: EKS
• EKS cluster: 백업할 클러스터 선택
• Kubernetes namespace: 백업할 네임스페이스 선택 (또는 전체)
3-2-3) 백업 설정
• Backup vault: default (또는 사용자 정의 vault)
• IAM role: AWSBackupDefaultServiceRole
• Backup window: 즉시 또는 예약
3-2-4) 고급 설정 (선택사항)
• Include cluster resources: 클러스터 메타데이터 포함 여부
• Include all namespaces: 모든 네임스페이스 백업 여부
백업 대상:
• EBS 기반 Persistent Volumes
• Kubernetes 리소스 메타데이터 (ConfigMap, Secret, Deployment 등)
• 네임스페이스별 리소스
CLI를 통한 AWS Backup
# Linux EC2 인스턴스
aws backup start-backup-job \
--backup-vault-name default \
--resource-arn arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0 \
--iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole
# Windows EC2 인스턴스 (VSS 옵션 필요시)
aws backup start-backup-job \
--backup-vault-name default \
--resource-arn arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0 \
--iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \
--backup-options WindowsVSS=enabled
4. 서비스별 백업 전략
웹 서버 (Apache/Nginx)
• 구성 파일: /etc/httpd, /etc/nginx, /etc/httpd/conf.d/, /etc/nginx/sites-available/
• 웹 콘텐츠: /var/www, /usr/share/nginx/html
• 로그 파일: /var/log/httpd, /var/log/nginx
• SSL 인증서: /etc/ssl/certs, /etc/letsencrypt, /etc/pki/tls/
• 사용자 정의 모듈/플러그인
데이터베이스 서버
• MySQL/MariaDB: mysqldump 또는 RDS 스냅샷
• PostgreSQL: pg_dump 또는 RDS 스냅샷
• 구성 파일: /etc/mysql/my.cnf, /etc/postgresql/*/main/postgresql.conf
• 데이터 디렉토리: /var/lib/mysql/, /var/lib/postgresql/
• 바이너리 로그: 백업 및 보존 정책 확인
• 트랜잭션 로그: PostgreSQL WAL 파일
애플리케이션 서버
• 애플리케이션 코드: Git 리포지토리 백업
• 설정 파일: application.properties, config.yaml
• 환경 변수: .env, /etc/environment
• 업로드된 파일: 사용자 업로드 디렉토리
• 세션 데이터: Redis, Memcached 덤프
• 로그 파일: /var/log/application/
• 크론잡: crontab -l 출력
• 시스템 서비스: /etc/systemd/system/
Guidance
백업 실행 전 고려사항
1. 서비스 영향도 평가
- 백업 중 I/O 성능 저하 가능성
- 데이터베이스 일관성 확보를 위한 잠시 중단 필요 여부
- 사용자 트래픽이 적은 시간대 선택
2. 백업 대상 식별
- 중요 데이터와 시스템 파일 구분
- 복구 우선순위에 따른 백업 계획
- 종속성이 있는 리소스 그룹화
3. 백업 저장소 관리
- 충분한 스토리지 용량 확보
- 교차 리전 백업 고려 (재해 복구)
- 백업 데이터 암호화 적용
백업 검증 및 테스트
1. 백업 무결성 확인
- 스냅샷 생성 완료 상태 확인
- 백업 파일 크기 및 체크섬 검증
- 메타데이터 정보 확인
2. 복원 테스트
- 별도 환경에서 복원 시뮬레이션
- 복원 시간(RTO) 측정
- 데이터 일관성 검증
3. 자동화 스크립트
- 백업 생성 스크립트 작성
- CloudWatch Events로 백업 완료 알림
- 백업 실패 시 자동 재시도 로직
패치 후 백업 정리
1. 임시 백업 정리
- 패치 성공 확인 후 불필요한 백업 삭제
- 스토리지 비용 최적화
- 백업 보존 정책에 따른 라이프사이클 관리
2. 백업 정책 업데이트
- 패치 후 변경된 구성에 맞는 백업 계획 수정
- 새로 추가된 리소스의 백업 포함
- 정기 백업 스케줄 재검토
잠재적 위험 및 대응
1. 백업 실패 시나리오
- 스토리지 용량 부족
- 권한 부족으로 인한 백업 실패
- 네트워크 연결 문제
2. 복원 시 고려사항
- IP 주소 및 DNS 설정 변경 필요 여부
- 라이센스 재활성화 필요성
- 외부 시스템과의 연동 재설정
댓글
댓글 0개
댓글을 남기려면 로그인하세요.