매일 스냅샷을 찍는데도 별도 백업이 필요한 이유

매일 스냅샷이 만들어지고 있다고 해서 별도 백업이 항상 필요한 것은 아니다. 반대로 매일, 혹은 그보다 더 자주 스냅샷을 만든다고 해서 현재 보호 체계가 충분하다고 볼 수도 없다.

판단 기준은 스냅샷이라는 이름이 아니다. 운영 데이터와 함께 사라질 수 있는가, 같은 관리자 권한으로 모두 지울 수 있는가, 장애가 발견되기 전 시점까지 이력이 남아 있는가, 손상되지 않은 상태로 복원할 수 있는가를 봐야 한다. 이 조건들을 충족하는 Snapshot 시스템이라면 이미 Backup Strategy의 중요한 부분을 담당하고 있을 수 있다. 반대로 원본과 같은 통제 경계 안에서 짧은 기간만 보관되고 실제 복원을 해본 적이 없다면, 생성 주기가 하루 한 번인지 한 시간에 한 번인지는 결정적인 답이 되지 않는다. (NIST 기술 시리즈 간행물)

특히 랜섬웨어나 Credential 탈취까지 고려한다면 “복사본이 존재한다”와 “사고 뒤에도 복사본을 사용할 수 있다”는 다른 문제다. CISA는 접근 가능한 백업도 랜섬웨어에 의해 삭제되거나 암호화될 수 있음을 전제로 오프라인 백업과 정기적인 무결성·복원 검증을 함께 권고한다. (CISA)

그래서 질문을 Snapshot인가 Backup인가에서 바꾸는 편이 낫다.

어떤 사고가 났을 때 현재 복구 지점도 함께 잃는가?

이 질문에 답하면 별도 보호 계층이 필요한지가 훨씬 분명해진다.

Snapshot, Backup, Replication, Versioning, Archive는 무엇이 다른가

SNIA의 현재 용어 정의를 기준으로 보면 Snapshot은 특정 시점의 복사본이고 Backup은 손실되거나 접근할 수 없는 원본을 복구하기 위해 보존하는 데이터이며 Replication은 가용성과 중복성을 위해 복사본을 지속해서 유지하는 구조다. Versioning은 여러 시점의 버전을 남기는 것이고 Archive는 장기 보존에 초점이 있다. (SNIA | Experts on Data)

따라서 AWS가 EBS Snapshot을 증분 백업이라고 부르거나 Azure가 Snapshot 기반 Disk Backup을 제공한다고 해서 용어가 잘못된 것이 아니다. Snapshot이라는 메커니즘이 실제 Backup Strategy를 구현하는 경우다. 다만 같은 제품에서도 Snapshot이 어떤 저장 영역에 놓이는지, 누가 삭제할 수 있는지, 어떤 상태를 캡처하는지는 별개의 문제다. (AWS Docs)

매일 찍는가보다 먼저 볼 일곱 가지

1. Separation — 원본과 함께 실패하는가

Production Volume이 사라졌을 때 Snapshot도 사라지는가를 본다. 물리적으로 같은 디스크에 있는 Copy-on-write Snapshot과 원본 저장소와 분리된 관리형 Snapshot은 같은 Failure Mode를 갖지 않는다.

Snapshot이라는 단어만으로 이 조건을 추정하면 안 된다. 실제 저장 위치와 Failure Domain을 확인해야 한다.

2. Control Independence — 같은 권한으로 전부 지울 수 있는가

데이터와 Snapshot이 물리적으로 분리돼 있어도 동일한 계정, 동일한 관리자 Credential, 동일한 삭제 권한으로 함께 제거할 수 있다면 Credential 탈취나 내부자 실수에 취약할 수 있다.

NIST CP-9에는 별도 저장뿐 아니라 백업 정보 보호와 삭제·파괴에 대한 이중 승인 같은 통제가 별도 항목으로 존재한다. 물리적 분리와 관리 권한의 분리는 서로 다른 문제라는 뜻이다. (NIST 기술 시리즈 간행물)

3. History / Retention — 잘못된 상태 이전으로 돌아갈 수 있는가

논리적 데이터 손상은 발생 즉시 발견되지 않을 수 있다. 월요일에 데이터가 오염됐는데 목요일에 발견했다면 수요일·목요일 Snapshot을 아무리 정상적으로 생성했어도 이미 손상된 상태일 수 있다.

따라서 마지막 Snapshot 하나가 있다보다 충분한 기간 동안 여러 복구 지점이 남아 있는가가 중요하다. Versioning 역시 이 영역에서 의미가 있다.

4. Immutability — 보존 기간 동안 변경·삭제를 막는가

Immutable은 정해진 기간 동안 Recovery Point를 변경하거나 삭제할 수 없도록 하는 속성이다. AWS Backup Vault Lock, Azure Immutable Vault 같은 기능은 이를 구현하는 예다. 일부 서비스는 관리자 권한이 있어도 잠긴 보존 정책을 우회하지 못하도록 설계된다. 구현과 잠금 상태에 따라 강도는 달라진다. (AWS Docs)

여기서 세 용어는 구분해야 한다.

Immutable = Offline = Air-gapped라고 쓰면 보호 모델을 제대로 설명할 수 없다.

그리고 Immutable하다고 해서 데이터가 올바르다는 보장도 생기지 않는다. 이미 손상된 데이터를 저장하면 손상된 상태가 그대로 변경 불가능하게 보존될 뿐이다. 무결성 검사와 실제 복원 시험이 따로 필요한 이유다. (NIST 기술 시리즈 간행물)

5. Recoverability — 실제로 꺼내 쓸 수 있는가

Backup Console에서 Completed라고 표시되는 것은 생성 작업이 끝났다는 증거다. 복원할 수 있다는 증거와는 다르다.

NIST CP-9는 백업 정보의 신뢰성과 무결성을 시험하고 실제 선택한 시스템 기능을 Backup으로 복원해 정상적으로 복구되는지 확인하도록 별도 통제를 둔다. (NIST 기술 시리즈 간행물)

6. Application Consistency — 애플리케이션이 이해할 수 있는 상태인가

실행 중인 서버에서 Storage Snapshot을 찍으면 디스크에 기록된 블록은 잡아도 메모리나 OS·애플리케이션 캐시에 아직 남은 데이터는 놓칠 수 있다. AWS 공식 문서도 EBS Snapshot에 애플리케이션이나 OS가 캐시한 데이터는 포함되지 않는다고 명시한다. Azure와 Google Cloud 역시 Crash-consistent Snapshot과 Application-consistent Snapshot을 구분한다. (AWS Docs)

특히 DB, 여러 Volume을 함께 쓰는 애플리케이션, 파일과 DB 사이의 상태가 연결된 시스템에서는 Volume을 열 수 있다와 애플리케이션 데이터가 일관된다가 같은 말이 아니다.

7. Owner — 누가 복구까지 책임지는가

스케줄만 있고 담당자가 없는 백업은 장애가 나기 전까지는 정상처럼 보인다. 누가 실패한 Backup Job을 확인하는지, 보존 정책을 바꿀 수 있는지, 복원을 수행하는지, 정기 검증 결과를 승인하는지가 정해져 있어야 한다.

NIST가 빈도·보존·시험·삭제 통제를 각각 조직이 정의하도록 두는 이유도 Backup을 단순 Storage 기능보다 운영 통제로 보기 때문이다. (NIST 기술 시리즈 간행물)

Failure Domain을 보면 ‘별도’의 의미가 달라진다

별도 Backup이라는 표현을 반드시 다른 Vendor에 하나 더 복사한다는 뜻으로 해석할 필요는 없다.

구조 다이어그램

                         ┌─────────────────────────────┐
                         │       Application State     │
                         │ DB transaction / cache / IO │
                         └──────────────┬──────────────┘
                                        │
                                        ▼
┌─────────────────────────────────────────────────────────────────┐
│ Production Failure Domain                                       │
│                                                                 │
│  [Production Data / Volume] ───────▶ [Snapshot Recovery Points] │
│             │                              │                    │
│             └──── 어떤 영역을 공유하는가? ──┘                    │
│                                                                 │
│      Storage / Region / Account / IAM / Credential / KMS        │
└───────────────────────────────┬─────────────────────────────────┘
                                │
                 공통 실패가 가능한가?
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│ Independent Protection Boundary                                 │
│                                                                 │
│  [Backup / protected recovery points]                           │
│   - 별도 권한 또는 계정                                         │
│   - 보존·삭제 통제                                               │
│   - 필요하면 Immutable / Offline / Isolated                     │
│   - 검증된 Restore 경로                                         │
│                                                                 │
│  다른 Region·Vendor는 요구되는 Failure Mode가 있을 때 선택       │
└─────────────────────────────────────────────────────────────────┘

같은 Region에 있더라도 Credential 탈취나 Volume 손실에 충분히 독립적인 Backup이 있을 수 있다. 반대로 다른 Region에 복제했더라도 같은 관리자 Credential 하나로 양쪽을 지울 수 있다면 Control Independence는 낮다.

Region 장애까지 방어해야 하는 시스템이라면 해당 Region과 Failure Domain을 공유하지 않는 복구 지점이 필요하다. 그러나 이 사실을 모든 시스템이 Cross-Region이나 Cross-Vendor여야 한다는 규칙으로 바꾸지는 말아야 한다. NIST도 백업 빈도·별도 저장과 같은 통제를 조직의 요구와 위험에 맞게 정의하도록 한다. Google Cloud Backup Vault 역시 같은 Region, 다른 Region 등 여러 배치 방식을 제공한다. (NIST 기술 시리즈 간행물)

이 글에서는 같은 이유로 3-2-1을 합격선으로 사용하지 않는다. 복사본 개수를 세기 전에 그 복사본들이 실제로 같은 사고에 함께 사라지는지를 확인하는 편이 더 중요하다.

Failure Mode × Protection Mechanism Matrix

아래 표는 제품별 보증표가 아니다. 각 메커니즘의 일반적인 성격을 기준으로 한 출발점이며 실제 결과는 저장 위치·권한·보존·지연·불변성·일관성 설정에 따라 달라진다. (SNIA | Experts on Data)

표기: ◎ 주된 대응 수단이 될 수 있음 / ○ 유용함 / △ 추가 조건이 있어야 유효 / — 일반적으로 주된 대응 수단이 아님

Replication은 이 표에서 특히 주의해야 한다. 정상 데이터를 빠르게 복제하면 장애 시 가용성을 높일 수 있지만 잘못 삭제한 데이터나 논리적으로 손상된 데이터도 빠르게 복제할 수 있다. Journal이나 지연 복제처럼 과거 상태를 별도로 보존하는 구현이라면 성격이 달라지지만 복제본이 있으니 백업도 있다고 자동으로 판단해서는 안 된다. SNIA 역시 Replication을 지속적인 Copy 유지와 가용성·중복성의 맥락에서 정의한다. (SNIA | Experts on Data)

실제 복원은 다섯 단계로 증거가 강해진다

Backup이 제대로 만들어졌는지 확인할 때 가장 약한 증거는 목록을 보는 것이다. NIST는 한 단계 더 나아가 Backup Media의 신뢰성과 정보 무결성을 확인하고 Sample Backup을 실제 복원 시험에 사용하도록 요구한다. (NIST 기술 시리즈 간행물)

이를 실제 애플리케이션 운영 관점으로 확장하면 다음과 같은 Restore Evidence Ladder를 만들 수 있다.

1~4단계는 NIST의 Backup 신뢰성·무결성 확인과 선택된 시스템 기능 복원 시험을 실무 흐름으로 풀어낸 것이다. 5단계의 핵심 사용자 여정은 NIST 문구를 그대로 옮긴 것이 아니라, 시스템 기능 복구를 사용자 관점의 결과까지 확인하기 위한 이 글의 운영상 확장이다. 특정 SLI나 목표 시간까지 정하는 것은 이 글의 범위가 아니다. (NIST 기술 시리즈 간행물)

이 Ladder의 목적은 매번 Production 전체를 복제해 거대한 DR 훈련을 하자는 것이 아니다. Backup 목록 확인만 해온 조직과 복원된 서비스로 실제 작업이 가능한지 확인한 조직의 증거 수준이 다르다는 사실을 드러내는 데 있다.

내 Snapshot 정책이 충분한지 보는 방법

매일 Snapshot이 만들어지고 있다면 새로운 제품을 찾기 전에 현재 정책에 다음 질문을 던져보면 된다.

1. Production Storage가 손실돼도 Recovery Point는 남는가?
2. Production 관리자 Credential을 탈취당했을 때 Recovery Point까지 전부 삭제할 수 있는가?
3. 손상을 며칠 뒤 발견해도 그 이전의 정상 시점이 남아 있는가?
4. 필요한 Recovery Point에 삭제·변경 방지 통제가 있는가?
5. DB와 애플리케이션이 이해할 수 있는 일관된 상태로 캡처되는가?
6. 최근 Recovery Point를 실제로 복원해 본 적이 있는가?
7. Backup 실패와 Restore Test를 책임지는 사람이 정해져 있는가?

여기서 모두 만족한다면 Snapshot이니까 별도 Backup을 하나 더 구매해야 한다는 결론을 자동으로 내릴 이유는 없다. 그 Snapshot 체계 자체가 상당한 Backup 기능을 수행하고 있을 가능성이 있다.

반대로 여러 항목에서 답이 불명확하다면 문제는 Snapshot의 생성 빈도가 아니다. 현재 Recovery Point가 원본의 실패와 얼마나 독립적인지 증명되지 않았다는 것이다.

복구 전략은 이름보다 실패 조건으로 평가하는 편이 안전하다. Snapshot은 구현과 운영 방식에 따라 훌륭한 Backup Strategy의 일부가 될 수 있다. 다만 그 가치는 매일 생성됨이라는 설정 화면이 아니라, 원본과의 분리, 통제 독립성, 보존 이력, 불변성, 애플리케이션 정합성, 그리고 실제 Restore Evidence로 판단해야 한다.