17장. EBS 스냅샷과 백업 전략
이 장에서 말하고자 하는 것
EC2의 디스크(EBS) 에는 다음이 들어 있다.
- 운영체제
- 애플리케이션
- 로그
- 임시 데이터
서버가 죽거나 사람이 실수로 파일을 지웠을 때
디스크 단위로 시점 복구가 가능해야 한다.
이걸 가능하게 하는 도구가
EBS 스냅샷 (Snapshot)
이다.
이 장은 스냅샷의 동작과 운영 전략을 정리한다.
1. 스냅샷이란
스냅샷은 EBS 볼륨의 시점 백업 이다.
EBS 볼륨 (100GB, 70GB 사용 중)
↓ 스냅샷 만들기
[Snapshot in S3]
├─ 사용 중인 블록만 저장 (70GB 분량)
└─ KMS로 자동 암호화 (볼륨이 암호화돼 있으면)
- S3 위에 저장 (사용자가 직접 볼 수는 없음)
- 같은 볼륨의 다음 스냅샷은 변경된 블록만 저장 (증분)
- 매우 효율적
2. 어떻게 동작하는가
첫 스냅샷: 사용 중인 모든 블록 백업 (70GB)
다음 스냅샷: 그 사이 변경된 블록만 (10GB)
다음 스냅샷: 또 변경된 블록만 (5GB)
각 스냅샷은 독립적인 시점 복구가 가능하다.
중간 스냅샷을 삭제해도 다른 스냅샷은 그대로 살아 있다.
3. 스냅샷에서 볼륨 복원
Snapshot → 새 EBS 볼륨 (다른 AZ도 가능)
- 새 AZ에 볼륨을 만들 때 자주 쓴다 (EBS는 AZ 종속이라)
- 새 EC2에 그 볼륨을 attach
- 또는 그 스냅샷으로 새 AMI 등록
4. 무엇을 백업해야 하나
운영체제 디스크: AMI에 박혀 있으면 백업 덜 중요
데이터 디스크: 매우 중요 (사용자 업로드 · DB · 로그)
임시 디스크: 백업 안 함
운영체제와 데이터 디스크를 분리해 두면 백업이 단순해진다.
디스크 1: OS (변하지 않음, AMI로 복구 가능)
디스크 2: 데이터 (자주 스냅샷)
5. Application-Consistent vs Crash-Consistent
스냅샷은 디스크 단위 백업이라 애플리케이션 일관성이 보장되지 않는다.
DB가 쓰는 중에 스냅샷 시작
↓
스냅샷에는 "쓰다 만" 상태가 박힘
↓
복원 시 손상 가능
해결:
- DB는 RDS/Aurora 의 백업 사용 (앱 일관성 보장)
- 직접 운영하는 DB는 스냅샷 전에 flush/lock
- 파일 시스템은
sync+fsfreeze같은 절차
EC2 위에 직접 DB를 띄우지 않는 게 가장 단순한 해답
6. AWS Backup — 자동화
스냅샷을 사람이 손으로 만들지 않는다.
AWS Backup 으로 정책 기반 자동화.
Backup Plan
├─ 일정: 매일 새벽 3시
├─ 대상: 태그 "Backup=daily" 가 붙은 모든 EBS
├─ 보관: 30일
└─ 교차 리전 복사 (선택)
- 사람의 손이 닿지 않는다
- 보관 정책 일관됨
- Vault Lock으로 악의적 삭제 방지 가능
운영 EBS는 거의 항상 AWS Backup 으로
7. 빠른 복원 — EBS Fast Snapshot Restore
스냅샷에서 큰 볼륨을 복원하면 처음 접근하는 블록이 느리다.
긴급 복구 시나리오에서는 FSR (Fast Snapshot Restore) 를 켜 둔다.
FSR 활성화된 스냅샷 → 복원 즉시 풀 성능
- 비용이 든다
- DR · 자주 복원하는 시나리오에서만
8. 우리 서비스에서
이 책의 척추는 ECS Fargate라 EBS 직접 운영은 적다.
주요 데이터:
RDS · DynamoDB → AWS Backup 으로 별도 다룸 (71장)
S3 → 버전 관리 + 수명 주기
EC2가 있다면 (예: ML 노드):
운영체제 → AMI
데이터 디스크 → AWS Backup daily, retention 30일
데이터를 거의 외부 저장소에 두므로 EBS 백업 부담이 적다.
9. 직접 확인해보기 — CLI
스냅샷 만들기
aws ec2 create-snapshot \
--volume-id vol-xxxx \
--description "manual before upgrade" \
--tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=pre-upgrade}]'
스냅샷 목록
aws ec2 describe-snapshots --owner-ids self
스냅샷에서 새 볼륨 만들기
aws ec2 create-volume \
--availability-zone ap-northeast-2c \
--snapshot-id snap-xxxx \
--volume-type gp3
AWS Backup으로 점검
aws backup list-backup-plans
aws backup list-backup-jobs --by-state COMPLETED
10. 코드로는 이렇게 생겼다 — Terraform (AWS Backup)
resource "aws_backup_vault" "main" {
name = "main-vault"
kms_key_arn = aws_kms_key.backup.arn
}
resource "aws_backup_plan" "daily_ebs" {
name = "daily-ebs"
rule {
rule_name = "daily-3am"
target_vault_name = aws_backup_vault.main.name
schedule = "cron(0 18 * * ? *)" # UTC 18 = KST 03
lifecycle {
delete_after = 30
}
copy_action {
destination_vault_arn = aws_backup_vault.dr.arn # DR 리전
lifecycle { delete_after = 90 }
}
}
}
# 태그로 백업 대상 자동 선택
resource "aws_backup_selection" "tagged" {
name = "tagged-ebs"
plan_id = aws_backup_plan.daily_ebs.id
iam_role_arn = aws_iam_role.backup.arn
selection_tag {
type = "STRINGEQUALS"
key = "Backup"
value = "daily"
}
}
EBS 볼륨에 Backup=daily 태그만 붙이면 자동 포함.
11. 이렇게 쓰면 망한다 — 안티패턴
안티패턴 1. 스냅샷을 수동으로 가끔 만든다
사람이 잊는다. 매일이 아닌 백업은 효과가 약하다.
안티패턴 2. EC2 위에 DB를 운영하면서 스냅샷만 믿는다
앱 일관성이 깨질 수 있다.
DB는 RDS/Aurora 또는 명시적 quiesce 절차
안티패턴 3. 스냅샷을 같은 리전 · 같은 계정에만 둔다
리전 장애 · 계정 침해 시 모두 사라진다.
Cross-Region 복사 + Vault Lock
안티패턴 4. 복원을 한 번도 안 해본다
“백업은 됐는데 복원이 안 되더라” 가 가장 흔한 사고.
분기마다 실제 복원 시뮬레이션
12. 한 줄로 정리
EBS 스냅샷은 디스크의 시점 백업이며,
AWS Backup + 교차 리전 + 복원 시뮬레이션이 운영의 토대다
13. 이 장의 핵심 정리
- EBS 스냅샷은 사용 중인 블록만 저장하는 증분 백업이다.
- OS 디스크와 데이터 디스크를 분리하면 백업이 단순해진다.
- DB는 EC2 EBS가 아니라 관리형 DB (RDS · Aurora) 가 답이다.
- AWS Backup으로 정책 기반 자동화한다.
- Cross-Region 복사와 Vault Lock으로 폭발 반경을 좁힌다.
- 복원은 분기마다 시뮬레이션 — 안 해본 백업은 백업이 아니다.