가상화 인프라를 운용할 때 데이터 보호와 시스템 복구성은 엔지니어가 가장 신경 써야 하는 요소입니다. 그러나 실무 현장에서는 의외로 많은 관리자가 가상머신(VM) 스냅샷(Snapshot)을 백업(Backup)의 일종으로 오해하고 백업 체계 대신 스냅샷에만 의존하다가 대규모 데이터 손실 장애를 겪는 경우가 빈번하게 발생합니다.
스냅샷과 백업은 특정 시점의 가상머신 상태를 저장한다는 점에서 겉보기에 유사해 보이지만, 내부 동작 메커니즘, 데이터 저장 형태, 그리고 사용 목적에서 완전히 다른 기술입니다.
이번 글에서는 가상머신 스냅샷과 백업의 핵심 차이점을 기술적 원리 수준에서 명확히 구분하고, 실제 운영 경험을 바탕으로 시스템 안정성을 극대화할 수 있는 올바른 운용 전략을 상세히 알아보겠습니다.
1. 가상머신 스냅샷(Snapshot)의 원리와 특징
스냅샷은 특정 시점(Point-in-time)의 가상머신의 상태, 디스크 데이터, 그리고 메모리 상태(선택 사항)를 그 순간 즉시 기록해 두는 일종의 ‘상태 저장’ 기능입니다.
스냅샷의 내부 작동 원리
KVM, VMware 등 하이퍼바이저에서 가상머신의 스냅샷을 생성하면 원래 쓰던 가상 디스크 파일(예: vmdk, qcow2)은 그 즉시 읽기 전용(Read-only) 상태로 고정됩니다. 이후 변경되거나 새로 생성되는 모든 데이터는 별도의 델타 디스크(Delta Disk 또는 차등 디스크) 파일에 기록됩니다.
이 방식의 가장 큰 장점은 생성 속도가 거의 즉각적이라는 점입니다. 하이퍼바이저가 원본 데이터를 어디론가 복사하는 것이 아니라 단순히 변경 사항을 기록할 새로운 차등 디스크 파일 헤더만 생성하기 때문입니다.
스냅샷의 주요 목적 및 한계
스냅샷의 주 목적은 시스템에 큰 변화를 주기 전 임시 복구 포인트를 만드는 것입니다. OS 패치, 애플리케이션 업그레이드, 설정 파일 수정 작업 전 스냅샷을 찍어두면 작업 중 문제가 발생했을 때 몇 초 만에 이전 상태로 되돌릴(Rollback) 수 있습니다.
그러나 스냅샷은 절대로 백업이 될 수 없습니다. 차등 디스크 구조상 원본 디스크 파일과 델타 디스크 파일이 동일한 스토리지 볼륨에 종속되어 존재하기 때문입니다. 만약 원본 디스크가 저장된 하드웨어나 스토리지 볼륨 자체가 파손되면 스냅샷이 존재하더라도 데이터는 복구할 수 없습니다.
또한 스냅샷을 오랫동안 지우지 않고 방치하면 델타 파일의 크기가 가상머신 원본 크기 이상으로 커지며 스토리지 공간을 압박하고, 디스크 I/O 처리 성능을 심각하게 저하하는 원인이 됩니다.
2. 가상머신 백업(Backup)의 원리와 특징
백업은 가상머신의 설정 정보, 가상 디스크 데이터 전체를 원본 스토리지와 물리적으로 완전히 분리된 별도의 저장 매체(백업 전용 NAS, 2차 스토리지, 타 데이터센터, 클라우드 스토리지 등)로 복사하여 저장하는 데이터 보존 과정입니다.
백업의 내부 작동 원리와 유형
백업은 원본 데이터의 딥 카피(Deep Copy)를 수행합니다. 데이터 양에 따라 전체 백업(Full Backup), 증분 백업(Incremental Backup), 차분 백업(Differential Backup) 등의 전략을 사용합니다.
현대 가상화 백업 솔루션(Veeam, Cohesity 등)은 CBT(Changed Block Tracking) 기술을 활용하여 마지막 백업 이후 변경된 블록 데이터만 백업 저장소로 빠르게 동기화함으로써 백업 시간과 네트워크 대역폭 소비를 대폭 줄입니다.
백업의 주요 목적
백업의 핵심 목적은 재난 복구(Disaster Recovery) 및 데이터 장기 보관입니다. 물리 서버 랙의 붕괴, 스토리지 볼륨 완전 파손, 랜섬웨어 감염, 데이터 센터 화재 등 최악의 재앙이 발생하더라도 물리적으로 독립된 장소에 보관된 백업본이 있다면 가상 인프라 전체를 완벽하게 재건할 수 있습니다.
3. 스냅샷 vs 백업 기술적 차이점 비교
| 구분 | 스냅샷 (Snapshot) | 백업 (Backup) |
| 주요 목적 | 임시 작업 전 변경 사항 즉시 롤백 | 시스템 재난 복구 및 데이터 장기 보존 |
| 데이터 저장 위치 | 원본 스토리지 내 동일 볼륨 (종속적) | 원본과 격리된 2차/3차 독립 스토리지 |
| 생성 및 복구 속도 | 즉시 생성 및 수초 내 즉각 롤백 가능 | 데이터 크기에 비례하여 데이터 전송 시간 소요 |
| 하드웨어 장애 대비 | 데이터 보호 불가 (원본 파손 시 함께 손실) | 데이터 보호 완벽 (독립 복사본 존재) |
| 장기 보관 적합성 | 부적합 (성능 저하 및 용량 과다 점유) | 매우 적합 (압축/중복제거를 통한 장기 보관) |
| 시스템 성능 영향 | 오랫동안 유지 시 디스크 I/O 성능 저하 | 백업 실행 시점에 잠시 I/O 부하 발생 |
4. 실무 인프라 운영 경험과 올바른 운용 전략
과거 금융권 및 E-커머스 가상화 인프라를 운영하던 시절, 스냅샷과 백업의 운용 정책을 철저히 구분하지 않아 발생했던 인프라 장애 사례를 목격한 적이 있습니다.
한 운영자가 애플리케이션 업데이트 작업을 진행하면서 만든 스냅샷을 삭제하지 않은 채 한 달 이상 방치했습니다. 시간이 흐름에 따라 델타 디스크 파일이 무섭게 커졌고, 결국 물리 스토리지의 전체 데이터스토어 용량이 100% 차오르며 해당 스토리지에 묶여 있던 주변 VM 20여 대가 한순간에 멈춰 버리는 대형 장애로 이어졌습니다.
게다가 스냅샷 파일이 커진 상태에서 스냅샷 삭제(Delete/Consolidate) 명령을 내리자 델타 데이터를 원본 디스크로 병합하는 고부하 I/O 작업으로 인해 수 시간 동안 가상머신 성능이 바닥을 치는 후폭풍을 겪어야 했습니다.
이러한 실무 낭패를 방지하고 시스템 안정성을 확보하기 위한 올바른 운용 전략은 다음과 같습니다.
첫째, 스냅샷 라이프사이클 72시간 제한 규칙 수립
스냅샷은 반드시 ‘임시 안전장치’로만 사용해야 합니다. 커널 업데이트, 데이터베이스 마이그레이션 등 위험 작업 직전에 생성하고, 작업이 성공적으로 종료되고 서비스 안정성이 확인되면 최소 24시간~72시간 이내에 반드시 스냅샷을 삭제(Consolidate)하여 델타 파일이 커지는 것을 원천 차단해야 합니다.
둘째, 백업에 대한 3-2-1 법칙 적용
중요 운영 데이터는 스냅샷에 의존하지 않고 standard 3-2-1 백업 원칙을 준수해야 합니다.
- 데이터 사본 3개 유지 (원본 1개 + 백업 2개)
- 2가지 서로 다른 매체에 저장 (예: 고성능 NAS 및 클라우드 객체 스토리지)
- 1개는 반드시 물리적으로 떨어진 오프사이트(Off-site) 또는 에어갭(Air-gapped) 공간에 보관하여 랜섬웨어 감염에 대비합니다.
셋째, 정기적인 백업 복구 테스트(Restore Test) 수행
백업 데이터가 제대로 생성되고 있는지 확인하는 것만으로는 부족합니다. 실제 복구 작업 시 가상머신이 정상 boot되어 서비스가 동작하는지 분기별로 복구 전용 클러스터에서 실증 테스트를 거쳐야 실제 재난 발생 시 RTO(복구 목표 시간)와 RPO(복구 목표 시점)를 준수할 수 있습니다.
5. 최종 요약
- 스냅샷은 시스템 변경 작업 전 수 분~수 시간 동안 단기적으로 사용하는 ‘작업용 안전 밧줄’입니다.
- 백업은 하드웨어 파손 및 재난 상황으로부터 비즈니스를 지키는 ‘최후의 보루’이자 독립된 복사본입니다.
두 기술의 메커니즘 차이를 올바르게 이해하고, 스냅샷의 즉각적인 롤백 능력과 백업의 안정적인 장기 보존 능력을 보완적으로 함께 조합하여 운영할 때 비로소 철통같은 가상화 인프라 보장 체계를 완성할 수 있습니다.