EBS 스냅샷 보존 정책: DLM 자동화와 실제 복원 시험 설계

AI Editter

스냅샷이 매일 생성된다고 복구 준비가 끝난 것은 아닙니다. 필요한 볼륨이 정책 대상에서 빠졌거나, 여러 볼륨의 시점이 맞지 않거나, 복원할 때 KMS 키에 접근하지 못할 수 있습니다.

EBS 스냅샷 보존 정책은 생성 주기뿐 아니라 대상 선정, 보존 기간, 복원 시험, 비용 확인을 함께 설계합니다. Amazon Data Lifecycle Manager(DLM)는 이 중 스냅샷과 AMI의 생성·보존·삭제를 자동화하는 도구입니다.

복구 요구에서 주기를 결정

먼저 허용 가능한 데이터 손실 시간과 업무 복구 시간을 정합니다. 하루 한 번 스냅샷이면 그 사이에 생긴 변경을 얼마나 잃을 수 있는지 검토해야 합니다. DB 로그나 앱 자체 백업과 조합해야 할 수도 있습니다.

요구	설계에서 확인
최근 파일 복구	생성 주기·일일 보존
오래된 잘못된 수정 복구	주간·월간 보존과 발견 지연
인스턴스 전체 재구성	볼륨 외 설정·AMI·네트워크·권한
계정·리전 장애 대비	별도 계정·리전 복사와 키 접근

가령 일일 7개와 주간 4개를 보관하는 정책은 예시일 뿐입니다. 잘못된 데이터가 3주 뒤 발견되는 업무라면 일일 7개만으로 충분하지 않을 수 있습니다. 보존 기간은 데이터 변경량과 복구 요구를 함께 보고 정합니다.

대상 태그가 실제 볼륨을 포함하는지 대조

AWS DLM 정책 화면에서 자원 유형·대상 태그·등록된 태그·정책 설명을 1~4번으로 표시 — AWS 공식 2021년 예시 화면에 표시를 추가했습니다. 현재 콘솔의 배치·메뉴 문구와 다를 수 있으며 태그 값과 정책명은 샘플입니다. 공식 출처

① 백업 대상이 Volume인지 Instance인지 선택합니다. ② 대상 자원에 붙인 태그의 키·값을 입력하고 Add를 누릅니다. ③ 등록된 태그가 의도한 자원과 일치하는지 확인합니다. ④ 정책 설명을 작성합니다. 이후 일정·보존·권한·활성 상태를 확인해야 정책 생성이 완료됩니다.

정책에서 인스턴스 또는 볼륨을 대상으로 선택하고 태그 조건을 정합니다. Backup=Daily 같은 태그를 사용한다면 필요한 리소스에 정확히 붙었는지 확인합니다. 새 볼륨을 추가했을 때 태그가 누락되는 경로도 점검합니다.

aws ec2 describe-volumes \
  --filters Name=tag:Backup,Values=Daily \
  --query 'Volumes[].{Id:VolumeId,AZ:AvailabilityZone,State:State,Size:Size}' \
  --output table

이 명령은 설정된 프로파일과 리전에서 조회합니다. 실제 계정·리전이 맞는지 먼저 확인하고, 기대 볼륨 목록과 결과를 비교합니다. 조회 권한이 없거나 결과가 비었다고 백업 대상이 없다고 바로 결론 내리지 않습니다.

DLM의 정책 종류·일정·대상 태그는 공식 구성 요소 문서에 정리돼 있습니다.

볼륨 스냅샷과 앱 일관성은 별도 확인

DB 데이터와 로그가 다른 볼륨에 있다면 각 볼륨을 제각각 찍은 사본으로 복구가 가능한지 확인해야 합니다. 지원되는 다중 볼륨 스냅샷이나 앱 정지·flush·DB 전용 백업 등 워크로드에 맞는 방식을 선택합니다.

스냅샷이 생성됐다는 상태만으로 애플리케이션의 모든 거래가 일관되게 복원된다고 보장할 수는 없습니다. AWS의 다중 볼륨 스냅샷 안내를 확인하고, 필요한 애플리케이션 수준 절차를 함께 설계합니다.

파일 시스템, DB, 앱이 각각 정상으로 판단하는 기준을 따로 적습니다. DB가 시작되지만 특정 파일 첨부가 없는 경우처럼 시스템 구성 요소 사이의 불일치도 시험해야 합니다.

정책 생성 후 첫 실행에서 확인할 것

항목	통과 기준
대상	기대 인스턴스·볼륨 모두 포함
생성	예상 일정 이후 스냅샷 완료
태그·설명	어떤 정책·원본인지 추적 가능
암호화	필요한 KMS 키와 복원 권한 확인
보존	정책에 따른 만료 대상 파악
알림	실패·누락을 운영자가 인지

콘솔에서 정책이 Enabled라는 사실과 실제 스냅샷 성공을 구별합니다. 정책 실행 역할에 필요한 권한이 있는지, 최근 생성 기록이 정상인지 확인합니다. 대상 리소스가 바뀌었을 때도 같은 검사를 다시 수행합니다.

실제 복원은 원본과 분리된 환경에서

스냅샷으로 새 볼륨을 만들고, 시험 인스턴스와 같은 AZ인지 확인한 뒤 연결합니다. 운영 원본 볼륨을 바꿔 끼우는 방식으로 첫 시험을 하지 않습니다. 같은 파일 시스템 식별자가 충돌하는 등 OS별 주의사항도 확인합니다.

복원한 파일의 개수·핵심 해시·권한을 확인하고 실제 앱으로 읽습니다. DB라면 복구 로그, 핵심 테이블 건수, 최근 거래, 무결성 검사를 봅니다. 복원 시작부터 업무 확인까지 걸린 시간을 기록합니다. 볼륨 생성 완료 시각만 복구 시간으로 쓰지 않습니다.

암호화 스냅샷은 복원 수행 계정이 키를 사용할 수 있는지도 시험합니다. 계정 간 복사를 계획했다면 복사본이 있다는 사실과 다른 계정에서 복원할 수 있다는 사실을 각각 확인해야 합니다.

비용과 정리에서 흔한 오해

스냅샷은 증분 방식이므로 볼륨 크기와 보관 개수를 단순 곱한 값이 실제 스냅샷 저장 비용과 같지는 않습니다. 변경된 블록과 보존 관계에 따라 달라집니다. 과거 스냅샷을 지웠다고 다음 스냅샷을 복원할 수 없게 되는 방식으로 이해할 필요도 없습니다. AWS가 필요한 블록을 관리합니다.

다만 DLM 정책과 관계없는 수동 스냅샷, 다른 도구가 만든 백업, 리전·계정 복사본까지 같은 정책으로 모두 정리된다고 가정하지 않습니다. 정책 소유와 보존 책임을 구분해 목록을 관리합니다.

복원 시험이 끝난 임시 볼륨·인스턴스도 비용을 만듭니다. 검증 결과를 보관한 뒤 시험 리소스를 식별해 정리하고, 다음 시험 날짜를 정합니다. 백업 정책의 품질은 생성 개수보다 실제 복원 기록으로 판단하는 편이 정확합니다.