Snapshot, Backup, Replication, Versioning, Archive는 무엇이 다른가
매일 스냅샷이 만들어진다고 해서 별도 백업이 항상 필요하지는 않습니다. 반대로 매일, 혹은 그보다 자주 스냅샷을 만든다고 해서 현재 보호 체계가 충분하다고 보지도 못합니다. 판단 기준은 스냅샷이라는 이름이 아닙니다. 운영 데이터와 함께 사라지는가, 같은 관리자 권한으로 모두 지워지는가, 장애가 발견되기 전 시점까지 이력이 남아 있는가, 손상되지 않은 상태로 복원되는가를 봐야 합니다.[1]
특히 랜섬웨어나 Credential 탈취까지 고려하면 “복사본이 존재한다”와 “사고 뒤에도 복사본을 쓴다”는 다른 문제입니다. CISA는 랜섬웨어가 접근 가능한 백업까지 지우거나 암호화한다는 전제로 오프라인 백업과 정기적인 무결성·복원 검증을 함께 권고합니다.[2] 그래서 질문을 스냅샷인가 백업인가에서 “어떤 사고가 났을 때 현재 복구 지점도 함께 잃는가”로 바꾸는 편이 낫습니다.
SNIA의 현재 용어 정의로 보면 Snapshot은 특정 시점의 복사본입니다. Backup은 손실되거나 접근할 수 없는 원본을 복구하기 위해 보존하는 데이터입니다. Replication은 가용성과 중복성을 위해 복사본을 지속해서 유지하는 구조입니다. Versioning은 여러 시점의 버전을 남기는 일이고 Archive는 장기 보존에 초점이 있습니다.[3]
따라서 AWS가 EBS Snapshot을 증분 백업이라고 부르거나 Azure가 Snapshot 기반 Disk Backup을 제공한다고 해서 용어가 잘못된 것이 아닙니다. Snapshot이라는 메커니즘이 실제 Backup Strategy를 구현하는 경우입니다. 다만 같은 제품에서도 Snapshot이 어떤 저장 영역에 놓이는지, 누가 삭제하는지, 어떤 상태를 캡처하는지는 별개의 문제입니다.[4]
구분 | 주된 목적 | Separation | Control Independence | History / Retention | Immutability | Recoverability | Application Consistency | 운영 Owner |
|---|---|---|---|---|---|---|---|---|
| Snapshot | 특정 시점으로 복원하거나 되돌림 | 구현에 따라 다름 | 구현에 따라 다름 | 여러 Snapshot을 남기면 가능 | 별도 기능일 수 있음 | Volume·Filesystem 복구 기능에 따라 강함 | Crash-consistent일 수도, Application-consistent일 수도 있음 | Snapshot 정책·수명주기·복원 책임 필요 |
| Backup | 원본 손실·접근 불가 시 복구 | 정책으로 설계 | 독립시킬 수 있음 | 보존 정책이 중요한 구성 요소 | 필요에 따라 적용 | 복구가 존재 목적 | Backup 방식과 애플리케이션에 따라 달라짐 | 생성뿐 아니라 복원까지 책임 필요 |
| Replication | 가용성과 중복성 | 원격 대상이면 높일 수 있음 | 구조에 따라 다름 | 최신 상태 중심. Journal·Delay가 있으면 달라짐 | 일반적인 핵심 속성은 아님 | Failover에는 유리 | 복제 방식에 따라 다름 | 복제 지연·상태·Failover 책임 |
| Versioning | 이전 버전 보존 | 같은 저장소일 수 있음 | 같은 관리 Plane인 경우가 많음 | 본래 강점 | 별도 삭제 보호가 필요할 수 있음 | 파일·Object 단위 복원에 유용 | 여러 컴포넌트의 일관성은 따로 확인해야 함 | 보존 기간·삭제 권한 책임 |
| Archive | 장기 보존 | 별도 계층으로 둘 수 있음 | 강하게 분리할 수 있음 | 장기 보존이 본래 목적 | WORM 등과 결합 가능 | 복구되더라도 즉시 운영 복원을 목표로 하지 않음 | 보존 단위에 따라 다름 | 보존·폐기·접근 정책 Owner 필요 |
매일 찍는가보다 먼저 볼 일곱 가지
생성 주기보다 먼저 볼 축이 일곱 개 있습니다.
첫째는 Separation입니다. Production Volume이 사라졌을 때 Snapshot도 사라지는지를 봅니다. 물리적으로 같은 디스크에 있는 Copy-on-write Snapshot과 원본 저장소에서 분리된 관리형 Snapshot은 같은 Failure Mode를 갖지 않습니다. Snapshot이라는 단어만으로 이 조건을 추정해서는 안 됩니다. 실제 저장 위치와 Failure Domain을 확인해야 합니다.
둘째는 Control Independence입니다. 데이터와 Snapshot이 물리적으로 나뉘어 있어도 같은 계정, 같은 관리자 Credential, 같은 삭제 권한으로 함께 제거된다면 Credential 탈취나 내부자 실수에 취약합니다. NIST CP-9에는 별도 저장뿐 아니라 백업 정보 보호와 삭제·파괴에 대한 이중 승인 같은 통제가 별도 항목으로 있습니다. 물리적 분리와 관리 권한의 분리는 서로 다른 문제라는 뜻입니다.[1]
셋째는 History와 Retention입니다. 논리적 데이터 손상은 발생 즉시 발견되지 않습니다. 월요일에 데이터가 오염됐는데 목요일에 발견했다면, 수요일과 목요일 Snapshot을 아무리 정상적으로 생성했어도 이미 손상된 상태입니다. 따라서 마지막 Snapshot 하나가 있다는 사실보다 충분한 기간 동안 여러 복구 지점이 남아 있는지가 중요합니다. Versioning도 이 영역에서 의미가 있습니다.
넷째는 Immutability입니다. Immutable은 정해진 기간 동안 Recovery Point를 변경하거나 삭제하지 못하도록 하는 속성입니다. AWS Backup Vault Lock, Azure Immutable Vault 같은 기능이 이를 구현하는 예입니다. 일부 서비스는 관리자 권한이 있어도 잠긴 보존 정책을 우회하지 못하도록 설계됩니다. 구현과 잠금 상태에 따라 강도는 달라집니다.[5]
여기서 세 용어를 갈라야 합니다. Immutable을 Offline이나 Air-gapped와 같은 말로 쓰면 보호 모델을 제대로 설명하지 못합니다. 그리고 Immutable하다고 해서 데이터가 올바르다는 보장이 생기지도 않습니다. 이미 손상된 데이터를 저장하면 손상된 상태가 그대로 변경 불가능하게 보존될 뿐입니다. 무결성 검사와 실제 복원 시험이 따로 필요한 이유입니다.[1]
다섯째는 Recoverability입니다. Backup Console에서 Completed라고 표시되는 것은 생성 작업이 끝났다는 증거입니다. 복원한다는 증거와는 다릅니다. NIST CP-9는 백업 정보의 신뢰성과 무결성을 시험하고 실제 선택한 시스템 기능을 Backup으로 복원해 정상적으로 복구되는지 확인하도록 별도 통제를 둡니다.[1]
여섯째는 Application Consistency입니다. 실행 중인 서버에서 Storage Snapshot을 찍으면 디스크에 기록된 블록은 잡아도 메모리나 OS·애플리케이션 캐시에 아직 남은 데이터는 놓칩니다. AWS 공식 문서도 EBS Snapshot에 애플리케이션이나 OS가 캐시한 데이터는 포함되지 않는다고 밝힙니다.[6] Azure와 Google Cloud 역시 Crash-consistent Snapshot과 Application-consistent Snapshot을 가릅니다. 특히 DB, 여러 Volume을 함께 쓰는 애플리케이션, 파일과 DB 사이의 상태가 이어진 시스템에서는 “Volume을 연다”와 “애플리케이션 데이터가 일관된다”가 같은 말이 아닙니다.[4]
일곱째는 Owner입니다. 스케줄만 있고 담당자가 없는 백업은 장애가 나기 전까지 정상처럼 보입니다. 누가 실패한 Backup Job을 확인하는지, 보존 정책을 바꾸는지, 복원을 수행하는지, 정기 검증 결과를 승인하는지가 정해져 있어야 합니다. NIST가 빈도·보존·시험·삭제 통제를 각각 조직이 정의하도록 두는 이유도 Backup을 단순 Storage 기능보다 운영 통제로 보기 때문입니다.[1]
- Separation
- 원본이 사라졌을 때 복구 지점도 함께 사라지는지를 묻는 축입니다.
- Control Independence
- 같은 계정과 같은 관리자 권한으로 복구 지점까지 전부 지울 수 있는지를 묻는 축입니다.
- History / Retention
- 손상을 며칠 뒤에 발견해도 그 이전의 정상 시점이 남아 있는지를 묻는 축입니다.
- Immutability
- 정해진 보존 기간 동안 복구 지점의 변경과 삭제를 막는 속성입니다.
- Recoverability
- 생성이 끝났다는 기록이 아니라 실제로 꺼내 쓸 수 있는지를 묻는 축입니다.
- Application Consistency
- 애플리케이션이 이해하는 상태로 캡처됐는지를 묻는 축입니다.
- Owner
- 실패한 작업 확인과 보존 정책 변경, 복원 수행, 정기 검증 승인을 누가 맡는지를 묻는 축입니다.
개념 | 뜻 | 서로 같지 않은 이유 |
|---|---|---|
| Offline | 평상시 운영 네트워크와 시스템에서 직접 접근하지 못하는 상태 | Offline 매체도 다시 연결하면 변경된다 |
| Immutable | 정해진 보존 기간 동안 변경과 삭제를 막는 속성 | 온라인 상태의 Storage도 Immutable하다 |
| Air-gapped | 운영 환경과 강한 격리 경계를 두는 구조 | 물리적 단절뿐 아니라 Vendor가 logical air gap이라는 이름으로 Identity·Control 격리를 구현하기도 한다 |
관측에서 복구와 개선까지 이어지는 운영 — 서비스 지표와 경보를 기준으로 대응하고 변경 이력과 사후 보고를 다음 개선에 연결합니다.
Failure Domain을 보면 ‘별도’의 의미가 달라진다
별도 Backup이라는 표현을 반드시 다른 Vendor에 하나 더 복사한다는 뜻으로 읽을 필요는 없습니다. 원본과 복구 지점이 Storage와 Region, Account, IAM, Credential, KMS 가운데 어떤 영역을 공유하는지를 그려 보면 판단이 달라집니다.
같은 Region에 있더라도 Credential 탈취나 Volume 손실에 충분히 독립적인 Backup이 있습니다. 반대로 다른 Region에 복제했더라도 같은 관리자 Credential 하나로 양쪽을 지운다면 Control Independence는 낮습니다.
Region 장애까지 막아야 하는 시스템이라면 해당 Region과 Failure Domain을 공유하지 않는 복구 지점이 필요합니다. 그러나 이 사실을 모든 시스템이 Cross-Region이나 Cross-Vendor여야 한다는 규칙으로 바꾸지는 말아야 합니다. NIST도 백업 빈도와 별도 저장 같은 통제를 조직의 요구와 위험에 맞게 정의하도록 합니다. Google Cloud Backup Vault 역시 같은 Region과 다른 Region 등 여러 배치 방식을 제공합니다.[1]
이 글에서는 같은 이유로 3-2-1을 합격선으로 쓰지 않습니다. 복사본 개수를 세기 전에 그 복사본들이 실제로 같은 사고에 함께 사라지는지를 확인하는 편이 더 중요합니다.
Failure Mode × Protection Mechanism Matrix
아래 표는 제품별 보증표가 아닙니다. 각 메커니즘의 일반적인 성격을 놓고 만든 출발점이며, 실제 결과는 저장 위치와 권한, 보존, 지연, 불변성, 일관성 설정에 따라 달라집니다.[3]
Replication은 이 표에서 특히 주의해야 합니다. 정상 데이터를 빠르게 복제하면 장애 시 가용성이 올라가지만, 잘못 삭제한 데이터나 논리적으로 손상된 데이터도 그만큼 빠르게 복제됩니다. Journal이나 지연 복제처럼 과거 상태를 따로 보존하는 구현이라면 성격이 달라집니다. 그러나 복제본이 있으니 백업도 있다고 자동으로 판단해서는 안 됩니다. SNIA 역시 Replication을 지속적인 Copy 유지와 가용성·중복성의 맥락에서 정의합니다.[3]
Failure Mode | Snapshot | Backup | Replication | Versioning | Archive |
|---|---|---|---|---|---|
| 운영자 실수 | ◎ 이전 시점이 남아 있다면 | ◎ | △ 실수도 즉시 복제된다 | ◎ | ○ |
| Credential 탈취 | △ 같은 권한으로 삭제되면 취약 | ◎ 독립 권한·삭제 통제가 있을 때 | △ 대상도 같은 권한이면 취약 | △ 버전 전체 삭제 권한 확인 필요 | ○ 독립 통제 시 |
| Ransomware | △ 접근·삭제 가능성에 좌우 | ◎ Offline·Immutable·통제 독립성이 있으면 강함 | △ 암호화된 데이터도 복제된다 | ○ 삭제 보호가 있을 때 | ○ 격리·보존 정책에 따라 |
| 논리적 데이터 손상 | ◎ 손상 전 시점이 남아 있다면 | ◎ | △ 최신 상태를 계속 복제하면 손상도 전달 | ◎ | ○ |
| Storage / Volume 손실 | ◎ 원본 Storage와 독립적으로 저장된다면 | ◎ | ◎ Secondary Copy가 살아 있다면 | △ 같은 Storage에만 있으면 함께 손실 | ○ |
| Account / 관리 Plane 문제 | △ 같은 Account라면 접근 자체가 막힌다 | ◎ 별도 통제 경계가 있을 때 | ○ 독립된 Secondary 관리 Plane이면 | △ | ○ 독립 관리 시 |
| Region / AZ Failure | △ Snapshot의 실제 배치에 따라 다름 | ○ 해당 Failure Domain과 분리돼 있다면 | ◎ 원격 복제라면 | △ | ○ 저장 위치에 따라 |
| Backup 자체 Corruption | ○ 독립된 다른 Recovery Point라면 | △ Backup이라는 이름만으로 해결되지 않음 | △ | ○ 다른 시점이 정상이라면 | ○ 독립 Copy라면 |
| Application Inconsistency | △ Application-aware Snapshot 필요 | ○ 일관된 Backup 방식일 때 | △ Replication 방식에 따라 | △ 단일 파일·Object 버전만으로는 모자람 | △ 보존 단위에 따라 |
서비스 구조에서 운영 기준까지 — 네트워크와 서버를 설계하고 배포 경로, 접근 권한과 백업 기준을 함께 갖춥니다.
실제 복원은 다섯 단계로 증거가 강해진다
Backup이 제대로 만들어졌는지 확인할 때 가장 약한 증거는 목록을 보는 것입니다. NIST는 한 단계 더 나아가 Backup Media의 신뢰성과 정보 무결성을 확인하고 Sample Backup을 실제 복원 시험에 쓰도록 요구합니다. 이를 애플리케이션 운영 관점으로 넓히면 다섯 단계의 Restore Evidence Ladder가 됩니다.[1]
1단계부터 4단계까지는 NIST의 Backup 신뢰성·무결성 확인과 선택된 시스템 기능 복원 시험을 실무 흐름으로 푼 것입니다. 5단계의 핵심 사용자 여정은 NIST 문구를 그대로 옮긴 것이 아니라, 시스템 기능 복구를 사용자 관점의 결과까지 확인하기 위한 이 글의 운영상 확장입니다. 특정 SLI나 목표 시간까지 정하는 것은 이 글의 범위가 아닙니다.[1]
이 Ladder의 목적은 매번 Production 전체를 복제해 거대한 DR 훈련을 하자는 것이 아닙니다. Backup 목록 확인만 해 온 조직과 복원된 서비스로 실제 작업이 되는지 확인한 조직의 증거 수준이 다르다는 사실을 드러내는 데 있습니다.
Level | 확인하는 것 | 무엇을 증명하는가 | 아직 증명하지 못하는 것 |
|---|---|---|---|
| 1. Backup 목록·메타데이터 확인 | Recovery Point 시간, 상태, 크기, Retention, 암호화 Key와 정책 | Backup Job과 Recovery Point가 기록상 존재한다 | 데이터를 실제로 읽는지 |
| 2. 표본 파일 복원 | 임의의 파일·Object·Volume 일부를 다른 위치에 Restore | 데이터 Retrieval, 권한·암호화 Key·기본 Restore 경로가 동작한다 | DB와 전체 애플리케이션 정합성 |
| 3. DB 무결성·정합성 검증 | DB 엔진에 맞는 Integrity Check, Transaction·Index·관계 검증 | 애플리케이션 데이터 저장소가 쓸 수 있는 상태다 | 전체 서비스가 실제로 기동되는지 |
| 4. 애플리케이션 기동 | 격리된 환경에서 설정·Secret·Dependency와 함께 실행 | 선택한 시스템 기능을 복구한다 | 사용자가 중요한 업무를 끝내는지 |
| 5. 핵심 사용자 여정 검증 | 로그인·조회·등록·처리 등 해당 서비스의 대표 여정을 실행 | 복원된 데이터와 애플리케이션이 End-to-End로 쓸 수 있는 상태다 | 모든 기능과 모든 장애 상황 |
내 Snapshot 정책이 충분한지 보는 방법
매일 Snapshot이 만들어진다면 새 제품을 찾기 전에 현재 정책에 일곱 질문을 던집니다. Production Storage가 손실돼도 Recovery Point는 남는가. Production 관리자 Credential을 탈취당했을 때 Recovery Point까지 전부 지워지는가. 손상을 며칠 뒤에 발견해도 그 이전의 정상 시점이 남아 있는가. 필요한 Recovery Point에 삭제·변경 방지 통제가 있는가. DB와 애플리케이션이 이해하는 일관된 상태로 캡처되는가. 최근 Recovery Point를 실제로 복원해 본 적이 있는가. Backup 실패와 Restore Test를 책임지는 사람이 정해져 있는가.
여기서 모두 만족한다면 스냅샷이니까 별도 Backup을 하나 더 사야 한다는 결론을 자동으로 낼 이유는 없습니다. 그 Snapshot 체계 자체가 상당한 Backup 기능을 맡고 있습니다. 반대로 여러 항목에서 답이 흐리다면 문제는 Snapshot의 생성 빈도가 아닙니다. 현재 Recovery Point가 원본의 실패와 얼마나 독립적인지 증명되지 않았다는 것입니다.
복구 전략은 이름보다 실패 조건으로 평가하는 편이 안전합니다. Snapshot은 구현과 운영 방식에 따라 훌륭한 Backup Strategy의 일부가 됩니다. 다만 그 가치는 “매일 생성됨”이라는 설정 화면이 아니라 원본과의 분리, 통제 독립성, 보존 이력, 불변성, 애플리케이션 정합성, 그리고 실제 Restore Evidence로 판단해야 합니다.
