EBS 스냅샷을 만들었으니 그 순간의 모든 데이터가 안전하게 들어갔다고 생각하기 쉽다. 하지만 애플리케이션이 아직 메모리나 운영체제 버퍼에 쓰기를 보관하고 있었다면, 볼륨에 기록된 시점과 애플리케이션이 완료했다고 믿는 시점이 다를 수 있다. 스냅샷은 유용한 복구 수단이지만, 생성 버튼을 눌렀다는 사실만으로 애플리케이션 데이터의 일관성이 보장되지는 않는다.
EBS 스냅샷은 어느 데이터를 담을까?
도식에서 스냅샷이 붙잡는 대상은 애플리케이션 메모리가 아니라 EBS 볼륨의 시점이다. 쓰기 버퍼를 먼저 반영해야 하는 이유와, 생성 성공만으로 복구 가능성을 판단할 수 없는 이유를 이 경계에서 읽을 수 있다.
EBS 볼륨 스냅샷은 볼륨의 특정 시점을 보존한다. 예를 들어 10시에 주문 데이터 쓰기가 시작돼 앱은 성공 응답을 준비했지만, 일부 데이터가 아직 버퍼에만 있다면 스냅샷이 그 데이터를 포함한다고 단정할 수 없다. 이 시간 예시는 원리를 설명하기 위한 가상 상황이다.
| 시점 | 애플리케이션 쪽 | EBS 볼륨 쪽 |
|---|---|---|
| 쓰기 요청 직후 | 버퍼에 변경 내용이 남을 수 있음 | 아직 반영되지 않았을 수 있음 |
| 쓰기 정리 뒤 | 필요한 변경이 디스크로 전달됨 | 스냅샷 대상 상태에 가까워짐 |
| 복원 뒤 | 앱의 데이터 구조 검사가 필요 | 볼륨 파일만 있다고 성공은 아님 |
AWS도 EBS 스냅샷 생성 설명에서 애플리케이션이나 운영체제가 캐시한 데이터는 스냅샷에 포함되지 않을 수 있으며, 일관성과 완전성을 위해 쓰기를 일시 중지할 것을 권장한다. 교육 자료는 ‘특정 시점 볼륨 복사’까지 설명하지만 이 안전 경계는 따로 보완해야 한다.
쓰기 중인 서비스에서는 무엇을 준비할까?
읽기 전용 파일 보관용 볼륨과 계속 쓰는 데이터베이스 볼륨은 요구하는 일관성 수준이 다르다. 데이터베이스라면 해당 DB가 제공하는 백업·체크포인트 절차와 복구 가능 지점을 확인한다. 스냅샷 전후에 쓰기 중단, 버퍼 비우기, 파일시스템 동결 같은 조치를 사용할지는 애플리케이션과 운영 절차에 맞춰 결정해야 한다. 검증 없이 동결 명령을 운영 서버에 복사해 실행해서는 안 된다. 동결을 했다면 풀리는 경로와 실패 시 복구 방법까지 준비해야 한다.
한 데이터가 여러 볼륨에 나뉘어 있다면 각 볼륨을 아무 때나 따로 캡처한 결과가 하나의 일관된 애플리케이션 상태인지 별도로 검토한다. 스냅샷이 ‘성공’으로 표시되는 것과 데이터베이스가 정상적으로 열리는 것은 다른 검사다.
복원 시험에서 무엇을 확인할까?
생성된 스냅샷으로 격리된 환경에 새 볼륨을 만들고 파일이 있는지만 보지 말고, 애플리케이션이 데이터를 실제로 읽는지 확인한다. 주문 같은 데이터라면 기준 시점의 건수와 중요한 키가 복원되는지, 쓰기 중이던 기록은 어떤 상태인지 비교한다. 복원 시험에 운영 고객 데이터를 사용할 경우 접근 권한과 개인정보 처리 범위를 먼저 정해야 한다.
보관 기간과 비용, 필요한 복구 시점도 함께 결정한다. 오래 보관한 스냅샷이 많아도 요구한 시점으로 복구할 수 없다면 계획이 부족한 것이다. 특정 AWS 계정에서 테스트했다거나 실제 운영 복구에 성공했다는 주장은 이 글에 포함하지 않는다.
핵심 요약: 스냅샷 성공과 데이터 복구 성공은 다르다
EBS 스냅샷은 볼륨의 시점을 담지만 앱·OS 버퍼의 미기록 데이터까지 자동으로 보장하지는 않는다. 쓰기 중인 서비스는 일관성 절차를 정하고, 스냅샷 생성 뒤에는 격리된 복원 시험으로 실제 데이터 읽기까지 확인해야 한다.
작성자
기초 개념을 구현과 검증, 실제 운영 판단까지 연결해 기록합니다.
