스냅샷은 백업을 대체할 수 있을까? 차이점과 한계 정리

스냅샷은 백업과 함께 자주 언급되는 데이터 보호 기술입니다. 서버를 업데이트하기 전, NAS 파일을 되돌리고 싶을 때, 가상머신 설정을 변경하기 전, 클라우드 디스크를 특정 시점으로 복구할 때 스냅샷을 사용합니다.

그래서 많은 사람이 “스냅샷이 있으면 백업은 없어도 되는 것 아닌가?”라고 생각합니다. 스냅샷은 빠르게 만들 수 있고 복구도 간단해 보이기 때문입니다.

하지만 결론부터 말하면 스냅샷은 백업을 완전히 대체할 수 없습니다. 스냅샷은 짧은 시간 안에 특정 시점으로 되돌리는 데 매우 유용하지만, 장기 보관, 랜섬웨어 대응, 물리적 장애, 계정 탈취, 저장소 손상까지 모두 대비하는 완전한 백업 전략은 아닙니다.

이번 글에서는 스냅샷과 백업의 차이, 스냅샷의 장점과 한계, 랜섬웨어 대비 시 주의할 점, 그리고 실제로는 스냅샷과 백업을 어떻게 함께 사용해야 하는지 쉽게 정리해보겠습니다.

스냅샷이란?

스냅샷은 특정 시점의 데이터 상태를 저장해두는 기술입니다. 사진을 찍으면 그 순간의 장면이 남는 것처럼, 스냅샷은 파일 시스템, 볼륨, 가상머신, 데이터베이스, 스토리지의 특정 시점 상태를 기록합니다.

중요한 점은 스냅샷이 항상 전체 데이터를 새로 복사하는 방식은 아니라는 것입니다. 많은 스냅샷 기술은 실제 데이터 전체를 복사하기보다 메타데이터와 변경된 블록을 관리합니다. 그래서 전체 데이터를 다시 복사하는 백업보다 빠르게 생성될 수 있습니다.

예를 들어 서버에 1TB 데이터가 있다고 해서 스냅샷을 만들 때 1TB를 모두 다시 복사하는 것은 아닙니다. 스냅샷 생성 시점의 데이터 상태를 표시해두고, 이후 변경되는 데이터만 별도로 관리하는 방식이 많이 사용됩니다.

스냅샷의 기본 작동 원리가 궁금하다면 기존 글인 스냅샷의 원리 글을 먼저 보면 이해하기 쉽습니다.

백업이란?

백업은 원본 데이터가 손상되거나 삭제되었을 때 복구할 수 있도록 별도의 복사본을 만들어 보관하는 작업입니다. 백업의 핵심은 원본과 분리된 복구 가능한 복사본을 확보하는 것입니다.

백업은 단순히 데이터를 한 번 복사하는 것에서 끝나지 않습니다. 백업 주기, 보관 기간, 저장 위치, 암호화, 접근 권한, 복구 테스트까지 함께 포함해야 제대로 된 백업 전략이라고 할 수 있습니다.

대표적인 백업 방식에는 풀백업, 증분백업, 차등백업이 있습니다. 풀백업은 전체 데이터를 복사하고, 증분백업은 마지막 백업 이후 변경된 데이터만 저장하며, 차등백업은 마지막 풀백업 이후 변경된 데이터를 누적해서 저장합니다.

백업 방식의 차이는 풀백업과 증분백업 차이점 글에서 자세히 정리했습니다.

스냅샷과 백업의 핵심 차이

스냅샷과 백업은 모두 복구를 돕는 기술이지만 목적과 보관 방식이 다릅니다. 스냅샷은 빠른 시점 복구에 강하고, 백업은 원본 장애와 장기 보호에 강합니다.

구분	스냅샷	백업
목적	특정 시점으로 빠르게 되돌리기	데이터 손실에 대비한 복구 복사본 보관
생성 속도	대체로 빠름	데이터 용량과 방식에 따라 다름
저장 방식	메타데이터와 변경 블록 중심	전체 또는 변경 데이터를 별도 복사본으로 저장
보관 기간	짧은 기간에 적합	단기·중기·장기 보관 가능
원본 의존성	원본 스토리지나 볼륨에 의존하는 경우가 많음	원본과 분리된 저장소에 보관 가능
랜섬웨어 대비	권한 탈취 시 삭제될 수 있음	오프라인·이뮤터블 구성 시 더 강함
복구 목적	업데이트 실패, 실수, 짧은 시점 복구	장애, 삭제, 감염, 장기 보관, 재해복구
관리 포인트	스냅샷 수, 보관 기간, 저장 공간, 성능	백업 성공 여부, 무결성, 보관 정책, 복구 테스트

간단히 말하면 스냅샷은 “빠른 되돌리기”에 가깝고, 백업은 “독립적인 복구 수단”에 가깝습니다.

스냅샷이 빠른 이유

스냅샷이 빠른 이유는 대부분의 경우 전체 데이터를 다시 복사하지 않기 때문입니다. 스냅샷은 특정 시점의 데이터 블록 위치와 상태를 기록하고, 이후 변경되는 데이터만 별도로 관리합니다.

대표적인 방식은 Copy-on-Write와 Redirect-on-Write입니다.

Copy-on-Write 방식

Copy-on-Write는 기존 데이터가 변경되기 전에 원래 데이터를 보존해두고, 새로운 데이터를 기록하는 방식입니다. 스냅샷 시점의 데이터를 유지하기 위해 변경 전 데이터를 따로 남겨둔다고 이해하면 됩니다.

Redirect-on-Write 방식

Redirect-on-Write는 기존 데이터 위치를 바꾸지 않고, 변경된 데이터를 새로운 위치에 기록하는 방식입니다. 스냅샷은 기존 데이터를 참조하고, 원본 볼륨은 새로 기록된 데이터를 참조합니다.

이런 구조 덕분에 스냅샷은 생성 속도가 빠르고 저장 공간도 처음에는 적게 사용할 수 있습니다. 하지만 데이터 변경이 계속 누적되면 스냅샷이 차지하는 공간도 증가할 수 있습니다.

스냅샷의 장점

1. 생성 속도가 빠르다

스냅샷은 전체 데이터를 복사하지 않는 방식이 많기 때문에 빠르게 생성할 수 있습니다. 서버 패치, 프로그램 업데이트, 설정 변경 전에 스냅샷을 만들어두면 문제가 생겼을 때 빠르게 이전 상태로 되돌릴 수 있습니다.

2. 복구가 빠르다

스냅샷은 특정 시점의 상태를 기준으로 되돌리는 데 유리합니다. 파일을 실수로 삭제했거나, 업데이트 후 오류가 발생했거나, 가상머신 설정을 잘못 변경했을 때 빠른 복구가 가능합니다.

3. 짧은 RPO를 만드는 데 도움된다

RPO는 장애 발생 시 허용 가능한 데이터 손실 시간을 의미합니다. 스냅샷을 자주 생성하면 비교적 짧은 시점 간격으로 복구 지점을 만들 수 있습니다. RTO와 RPO 개념은 RTO와 RPO란? 글에서 자세히 볼 수 있습니다.

4. 테스트와 업데이트에 유용하다

스냅샷은 운영 환경을 변경하기 전 안전장치로 사용하기 좋습니다. 업데이트, 패치, 설정 변경, 앱 설치, 데이터 마이그레이션 전에 스냅샷을 생성하면 문제가 발생했을 때 되돌릴 수 있습니다.

5. 저장 공간을 효율적으로 사용할 수 있다

변경된 데이터만 관리하는 구조에서는 전체 데이터를 매번 복사하는 풀백업보다 저장 공간을 절약할 수 있습니다. 특히 짧은 기간 동안 여러 복구 지점을 유지해야 할 때 유용합니다.

스냅샷의 한계

스냅샷은 매우 유용하지만, 한계도 분명합니다. 이 한계를 모르고 스냅샷만 믿으면 장애나 랜섬웨어 상황에서 복구에 실패할 수 있습니다.

1. 원본 스토리지에 의존하는 경우가 많다

많은 스냅샷은 원본 볼륨, 원본 스토리지, 원본 가상머신과 강하게 연결되어 있습니다. 원본 스토리지 자체가 손상되거나 삭제되면 스냅샷도 함께 사용할 수 없을 수 있습니다.

예를 들어 NAS 내부 볼륨에만 스냅샷이 있고 NAS 장비가 고장 나면, 스냅샷이 있어도 복구가 어려울 수 있습니다. 이 때문에 스냅샷은 원본과 별도 위치에 저장되는 백업과 구분해야 합니다.

2. 장기 보관에 적합하지 않을 수 있다

스냅샷은 일반적으로 짧은 기간의 빠른 복구 지점으로 활용됩니다. 장기간 스냅샷을 많이 쌓아두면 저장 공간이 빠르게 증가하고 성능에도 영향을 줄 수 있습니다.

특히 가상머신 스냅샷은 오래 보관할수록 변경 데이터가 커지고, 삭제하거나 병합할 때 시간이 오래 걸릴 수 있습니다. 장기 보관 목적이라면 스냅샷보다 백업 또는 아카이브 전략을 함께 사용해야 합니다.

3. 랜섬웨어가 관리자 권한을 얻으면 삭제될 수 있다

랜섬웨어는 단순히 파일만 암호화하는 것이 아니라 백업과 스냅샷을 찾아 삭제하려고 시도할 수 있습니다. 공격자가 관리자 계정이나 백업 관리 계정을 탈취하면 스냅샷 삭제 권한까지 얻을 수 있습니다.

따라서 스냅샷이 있다고 해서 랜섬웨어에 안전하다고 볼 수는 없습니다. 랜섬웨어 대비를 위해서는 스냅샷 외에도 오프라인 백업, 오프사이트 백업, 이뮤터블 백업이 필요합니다. 기본 전략은 3-2-1 백업 원칙 글을 함께 참고하면 좋습니다.

4. 애플리케이션 일관성이 부족할 수 있다

파일 서버처럼 단순 파일 중심 환경에서는 스냅샷 복구가 비교적 단순합니다. 하지만 데이터베이스, 메일 서버, 업무 시스템처럼 데이터가 계속 쓰이는 환경에서는 스냅샷 시점의 데이터 일관성이 중요합니다.

애플리케이션이 데이터를 쓰는 도중 스냅샷을 만들면, 복구 후 데이터베이스나 서비스가 정상적으로 열리지 않을 수 있습니다. 이런 환경에서는 애플리케이션 인식 백업, VSS, 데이터베이스 백업, 트랜잭션 로그 백업 등을 함께 고려해야 합니다.

5. 저장 공간 부족과 성능 문제가 생길 수 있다

스냅샷은 처음 만들 때는 용량이 작아 보일 수 있지만, 원본 데이터가 많이 변경될수록 스냅샷 관련 데이터도 커집니다. 스냅샷을 너무 많이 만들거나 오래 유지하면 스토리지 공간이 부족해질 수 있습니다.

또한 일부 환경에서는 스냅샷이 많아질수록 쓰기 성능이나 병합 작업에 영향을 줄 수 있습니다. 따라서 스냅샷은 무제한으로 쌓아두는 것이 아니라 보관 기간과 개수를 정해야 합니다.

6. 같은 계정과 같은 장애 범위에 묶일 수 있다

스냅샷이 원본과 같은 관리자 계정, 같은 스토리지, 같은 클라우드 계정, 같은 지역에만 존재한다면 단일 장애 지점이 될 수 있습니다. 계정이 탈취되거나 스토리지가 손상되거나 클라우드 설정을 잘못 삭제하면 원본과 스냅샷이 함께 영향을 받을 수 있습니다.

좋은 백업 전략은 원본과 복구 수단을 분리합니다. 백업 스토리지 선택 기준은 백업 스토리지 기술 글에서 더 자세히 볼 수 있습니다.

스냅샷은 백업을 대체할 수 있을까?

일반적인 답은 대체할 수 없다입니다. 스냅샷은 백업 전략의 일부가 될 수 있지만, 백업 전체를 대신하기에는 부족합니다.

스냅샷이 백업을 대체하기 어려운 이유는 다음과 같습니다.

• 원본 스토리지에 의존하는 경우가 많습니다.
• 장기 보관에 적합하지 않을 수 있습니다.
• 관리자 권한 탈취 시 삭제될 수 있습니다.
• 랜섬웨어가 스냅샷까지 공격할 수 있습니다.
• 스토리지 고장이나 계정 삭제에는 취약할 수 있습니다.
• 애플리케이션 일관성이 보장되지 않을 수 있습니다.
• 정기적인 복구 테스트 없이 신뢰하기 어렵습니다.

따라서 스냅샷은 “백업의 대체재”가 아니라 “백업을 보완하는 빠른 복구 수단”으로 보는 것이 안전합니다.

스냅샷이 백업처럼 활용되는 경우도 있다

스냅샷이 백업을 완전히 대체할 수 없다고 해서 스냅샷이 백업과 무관하다는 뜻은 아닙니다. 클라우드나 스토리지 제품에 따라 스냅샷은 백업 기능의 핵심 요소로 사용되기도 합니다.

예를 들어 클라우드 디스크 스냅샷은 특정 시점의 볼륨 상태를 저장하고, 이후 변경된 블록만 저장하는 증분 방식으로 운영될 수 있습니다. 이런 환경에서는 스냅샷 자체가 백업 작업의 한 형태로 사용됩니다.

하지만 이 경우에도 중요한 것은 스냅샷이 어디에 저장되는지, 누가 삭제할 수 있는지, 다른 계정이나 지역으로 복사되는지, 보관 기간이 어떻게 되는지, 실제 복구가 가능한지입니다.

즉 “스냅샷이니까 백업이 아니다”라고 단순히 말하기보다는, 그 스냅샷이 원본과 얼마나 분리되어 있고, 얼마나 보호되며, 실제 복구 가능한 정책으로 관리되는지를 확인해야 합니다.

VM 스냅샷은 특히 오래 보관하면 안 된다

가상머신 환경에서는 스냅샷을 업데이트 전 롤백 용도로 많이 사용합니다. 예를 들어 Windows Server 업데이트, Linux 패키지 업데이트, 애플리케이션 설정 변경 전에 VM 스냅샷을 만들어두면 문제가 생겼을 때 빠르게 되돌릴 수 있습니다.

하지만 VM 스냅샷을 장기 백업처럼 계속 보관하는 것은 좋지 않습니다. 스냅샷이 오래 유지되면 변경 데이터가 커지고, 삭제와 병합 과정이 오래 걸리며, 성능 저하나 스토리지 부족 문제가 생길 수 있습니다.

VM 스냅샷은 일반적으로 다음과 같은 목적에 적합합니다.

• 업데이트 전 임시 롤백 지점 생성
• 설정 변경 전 안전장치
• 테스트 환경에서 빠른 되돌리기
• 백업 솔루션이 일관성 있는 백업을 만들기 위한 임시 보조 수단

반대로 다음 용도로는 적합하지 않습니다.

• 몇 달 이상 장기 보관
• 유일한 백업 수단
• 랜섬웨어 대비의 전부
• 운영 DB 서버의 무검증 복구 수단
• 원본 스토리지 장애 대비용 독립 백업

NAS 스냅샷은 어떻게 봐야 할까?

NAS를 사용하는 개인이나 소규모 회사에서는 스냅샷 기능을 자주 활용합니다. 공유 폴더의 특정 시점을 저장해두면 파일을 잘못 삭제하거나 덮어썼을 때 빠르게 되돌릴 수 있습니다.

NAS 스냅샷은 다음 상황에서 유용합니다.

• 직원이 실수로 파일을 삭제한 경우
• 문서를 잘못 덮어쓴 경우
• 특정 폴더를 어제 상태로 되돌려야 하는 경우
• 랜섬웨어 감염 초기에 빠르게 일부 파일을 복구해야 하는 경우

하지만 NAS 한 대 안에 원본 데이터와 스냅샷이 모두 있다면 NAS 장비 고장, 볼륨 손상, 관리자 계정 탈취, 랜섬웨어 공격에 함께 노출될 수 있습니다.

따라서 NAS 스냅샷은 NAS 내부의 빠른 복구 기능으로 사용하고, 중요한 데이터는 외장하드, 다른 NAS, 클라우드, 이뮤터블 스토리지 등으로 별도 백업하는 것이 좋습니다.

클라우드 스냅샷은 안전할까?

클라우드 스냅샷은 온프레미스 스토리지 스냅샷보다 더 독립적인 구조로 제공되는 경우가 많습니다. 예를 들어 클라우드 디스크의 스냅샷을 생성하면 해당 시점의 볼륨을 기반으로 새 디스크를 만들거나 다른 가용 영역에서 복구할 수 있습니다.

클라우드 스냅샷의 장점은 다음과 같습니다.

• 콘솔이나 API로 자동화하기 쉽습니다.
• 정책 기반으로 주기적 생성이 가능합니다.
• 증분 방식으로 저장 공간을 절약할 수 있습니다.
• 복구용 새 볼륨을 빠르게 만들 수 있습니다.
• 서비스에 따라 다른 리전이나 계정으로 복사할 수 있습니다.

하지만 클라우드 스냅샷도 계정 권한 관리가 약하면 삭제될 수 있습니다. 클라우드 계정이 탈취되면 원본 서버, 디스크, 스냅샷이 함께 위험해질 수 있습니다.

클라우드 환경에서는 스냅샷 자동화뿐 아니라 다중 인증, 권한 최소화, 삭제 방지 정책, 별도 계정 복사, 이뮤터블 보관, 복구 테스트를 함께 적용해야 합니다.

랜섬웨어 대비 관점에서 스냅샷의 위치

랜섬웨어 대비에서 스냅샷은 빠른 복구를 돕는 좋은 도구입니다. 감염 시점을 빠르게 파악하고 정상 스냅샷이 남아 있다면 일부 데이터를 빠르게 되돌릴 수 있습니다.

하지만 랜섬웨어가 관리자 권한을 획득하거나 백업 관리 콘솔에 접근하면 스냅샷을 삭제하거나 암호화된 상태의 스냅샷만 남길 수 있습니다. 최근 랜섬웨어 대응에서는 “백업본이 있는가?”보다 “공격자가 지울 수 없는가?”가 더 중요합니다.

랜섬웨어 대비를 위해서는 다음 요소를 함께 구성하는 것이 좋습니다.

• 운영 스토리지의 짧은 주기 스냅샷
• 별도 백업 저장소에 저장되는 정기 백업
• 오프사이트 또는 클라우드 백업
• 오프라인 또는 에어갭 백업
• 이뮤터블 백업 또는 WORM 보관
• 관리자 계정 분리와 다중 인증
• 정기적인 복구 테스트

변경과 삭제를 막는 백업 구조는 변경 불가 백업(Immutable Backup) 구축 가이드 글에서 더 자세히 볼 수 있습니다.

스냅샷과 백업을 함께 사용하는 추천 구조

가장 현실적인 전략은 스냅샷과 백업을 함께 사용하는 것입니다. 스냅샷은 빠른 복구용, 백업은 독립적인 복구와 장기 보호용으로 역할을 나누면 됩니다.

목적	추천 수단	예시
실수로 삭제한 파일 복구	NAS 또는 파일 시스템 스냅샷	몇 시간 전, 어제 시점으로 빠르게 복구
업데이트 실패 복구	VM 스냅샷	패치 전 스냅샷 생성 후 문제 시 롤백
서버 장애 복구	정기 백업 + 스냅샷	백업본으로 새 서버 복구, 스냅샷으로 최근 시점 보완
랜섬웨어 대비	스냅샷 + 이뮤터블 백업 + 오프라인 백업	삭제 불가능한 백업본과 여러 시점 복구 지점 확보
장기 보관	백업 또는 아카이브 스토리지	월간·연간 백업, 테이프, 클라우드 아카이브

즉 스냅샷은 빠른 대응용이고, 백업은 최종 복구 수단입니다. 장기 보관 데이터가 많다면 백업과 아카이브 전략의 통합 글도 함께 참고하면 좋습니다.

개인 사용자 예시

개인 사용자라면 스냅샷 기능이 있는 NAS나 클라우드 동기화를 사용할 수 있습니다. 하지만 중요한 사진, 문서, 작업 파일을 NAS 한 곳에만 두는 것은 안전하지 않습니다.

개인 사용자에게는 다음 구조가 현실적입니다.

• PC 또는 노트북에 원본 데이터 저장
• NAS 또는 외장하드에 정기 백업
• NAS 스냅샷으로 실수 삭제에 대비
• 중요 사진과 문서는 클라우드에도 보관
• 월 1회 외장하드는 분리 보관

이렇게 하면 파일을 잘못 삭제했을 때는 스냅샷으로 빠르게 복구하고, 장비 고장이나 랜섬웨어 감염 시에는 외장하드나 클라우드 백업으로 복구할 수 있습니다.

소규모 회사 예시

소규모 회사에서는 파일 서버, 회계 자료, 업무 문서, 고객 자료, 그룹웨어 데이터가 중요합니다. 이 경우 스냅샷만으로는 부족하고 백업 정책을 함께 만들어야 합니다.

예시 구조는 다음과 같습니다.

• 업무 파일 서버는 1~2시간 단위 스냅샷 생성
• 매일 새벽 증분백업 수행
• 주 1회 풀백업 수행
• 월 1회 외부 저장소 또는 클라우드에 보관
• 중요 백업은 이뮤터블 또는 오프라인으로 보호
• 분기별로 복구 테스트 진행

이 구조에서는 스냅샷이 빠른 파일 복구를 담당하고, 백업은 서버 장애나 랜섬웨어 피해 후 복구를 담당합니다.

서버 운영 환경 예시

서버 운영 환경에서는 스냅샷과 백업을 더 명확히 구분해야 합니다. 웹 서버, 데이터베이스 서버, 파일 서버, 가상머신은 각각 복구 기준이 다를 수 있습니다.

예를 들어 웹 서버는 설정 파일과 소스 코드 복구가 중요하고, 데이터베이스 서버는 데이터 일관성과 로그 백업이 중요합니다. 파일 서버는 사용자 파일의 여러 시점 복구가 중요합니다.

서버 운영 환경에서는 다음을 함께 고려하는 것이 좋습니다.

• OS와 애플리케이션 설정 백업
• 데이터베이스 전용 백업
• 가상머신 또는 디스크 스냅샷
• 스냅샷 보관 기간 제한
• 백업 저장소 권한 분리
• 복구 절차 문서화
• 정기적인 테스트 복구

스냅샷은 장애 전후의 빠른 복구 지점으로 사용하고, 백업은 전체 시스템을 다시 구성할 수 있는 독립 복구 수단으로 운영해야 합니다.

스냅샷 보관 정책을 정하는 방법

스냅샷은 많이 만들수록 안전해 보이지만 무제한으로 보관하면 관리가 어려워집니다. 보관 정책을 정할 때는 데이터 변경량, 저장 공간, 복구 목적, RPO를 함께 고려해야 합니다.

예시 정책은 다음과 같습니다.

환경	스냅샷 주기	보관 예시
개인 NAS	하루 1~2회	최근 7~14일 보관
소규모 파일 서버	1~4시간 단위	시간별 1~3일, 일별 2~4주 보관
업데이트 전 VM	작업 직전 1회	작업 완료 후 이상 없으면 삭제
중요 업무 시스템	짧은 주기 스냅샷 + 정기 백업	스냅샷은 단기, 백업은 장기 보관
랜섬웨어 대비	스냅샷 + 이뮤터블 백업	스냅샷만 믿지 않고 별도 보호 백업 유지

중요한 것은 스냅샷을 “얼마나 자주 만들 것인가”뿐만 아니라 “언제 삭제할 것인가”도 함께 정하는 것입니다.

스냅샷 사용 시 자주 하는 실수

1. 스냅샷을 백업이라고 생각한다

스냅샷은 빠른 복구 지점이지만 원본과 같은 장애 범위에 있을 수 있습니다. 스냅샷만 믿고 별도 백업을 하지 않으면 장비 고장이나 계정 탈취 상황에서 위험합니다.

2. 스냅샷을 너무 오래 보관한다

스냅샷이 오래 유지되면 변경 데이터가 누적되고 저장 공간을 많이 사용할 수 있습니다. 특히 VM 스냅샷은 장기간 방치하면 성능과 병합 작업에 문제가 생길 수 있습니다.

3. 스냅샷 삭제 권한을 제한하지 않는다

관리자 계정 하나로 원본 데이터와 스냅샷을 모두 삭제할 수 있다면 위험합니다. 계정 분리, 권한 최소화, 다중 인증, 삭제 방지 정책을 적용해야 합니다.

4. 복구 테스트를 하지 않는다

스냅샷 목록이 있다고 해서 복구가 된다는 보장은 없습니다. 실제로 일부 파일이나 테스트 VM을 복구해보고, 복구 시간과 데이터 정상 여부를 확인해야 합니다.

5. 데이터베이스를 일반 파일처럼 취급한다

데이터베이스는 단순 파일 복구와 다릅니다. 스냅샷만으로 복구할 경우 트랜잭션 일관성 문제가 생길 수 있으므로 DB 전용 백업과 로그 백업을 함께 고려해야 합니다.

6. 같은 저장소 안에 원본과 스냅샷만 둔다

원본과 스냅샷이 같은 장비에만 있으면 장비 장애에 취약합니다. 중요한 데이터는 다른 저장소, 다른 위치, 다른 계정에도 보관해야 합니다.

스냅샷 점검 체크리스트

스냅샷을 운영 중이라면 아래 항목을 점검해보면 좋습니다.

• 스냅샷 생성 주기가 정해져 있는가?
• 스냅샷 보관 기간이 정해져 있는가?
• 오래된 스냅샷이 방치되어 있지 않은가?
• 스냅샷 저장 공간 사용량을 모니터링하고 있는가?
• 스냅샷 삭제 권한이 제한되어 있는가?
• 관리자 계정에 다중 인증을 적용했는가?
• 스냅샷과 별도의 백업이 존재하는가?
• 백업본이 원본과 다른 위치에 보관되는가?
• 랜섬웨어 대비용 이뮤터블 또는 오프라인 백업이 있는가?
• 스냅샷 복구 테스트를 해본 적이 있는가?
• 데이터베이스와 업무 시스템은 애플리케이션 일관성을 고려했는가?
• 스냅샷 실패나 삭제 이벤트 알림을 받고 있는가?

이 체크리스트에서 부족한 항목이 많다면 스냅샷은 있지만 실제 사고 상황에서는 복구가 어려울 수 있습니다.

스냅샷과 백업을 구분하는 기준

어떤 기술이 스냅샷인지 백업인지 헷갈린다면 다음 질문을 해보면 됩니다.

• 원본 스토리지가 망가져도 복구할 수 있는가?
• 관리자 계정이 탈취되어도 삭제를 막을 수 있는가?
• 다른 장비나 다른 위치에 복사본이 있는가?
• 장기 보관 정책이 있는가?
• 복구 테스트를 통과했는가?
• 랜섬웨어 감염 시에도 정상 복구 지점을 찾을 수 있는가?

이 질문에 대부분 “아니다”라고 답한다면 그것은 완전한 백업이라기보다 빠른 롤백용 스냅샷에 가깝습니다.

자주 묻는 질문

Q1. 스냅샷은 백업인가요?

스냅샷은 백업에 활용될 수 있지만, 항상 완전한 백업이라고 보기는 어렵습니다. 원본과 분리된 복구 가능한 복사본인지, 삭제 방지와 보관 정책이 있는지에 따라 달라집니다.

Q2. 스냅샷만 있으면 랜섬웨어에 안전한가요?

아닙니다. 공격자가 관리자 권한을 얻으면 스냅샷을 삭제할 수 있습니다. 랜섬웨어 대비에는 오프라인 백업, 이뮤터블 백업, 접근 권한 분리, 복구 테스트가 필요합니다.

Q3. VM 스냅샷은 얼마나 오래 보관해야 하나요?

VM 스냅샷은 장기 보관보다는 작업 전후 임시 롤백 용도로 사용하는 것이 좋습니다. 업데이트나 설정 변경 후 문제가 없으면 가능한 빨리 정리하는 것이 안전합니다.

Q4. NAS 스냅샷은 유용한가요?

유용합니다. 실수로 삭제한 파일이나 잘못 덮어쓴 문서를 빠르게 복구하는 데 좋습니다. 다만 NAS 장비 고장이나 관리자 계정 탈취에 대비하려면 별도 백업도 필요합니다.

Q5. 클라우드 스냅샷은 백업으로 봐도 되나요?

클라우드 스냅샷은 백업 기능으로 활용될 수 있습니다. 하지만 같은 계정 안에서 쉽게 삭제될 수 있다면 위험합니다. 다른 계정, 다른 리전, 이뮤터블 보관, 권한 제한을 함께 적용하는 것이 좋습니다.

Q6. 스냅샷과 증분백업은 같은 건가요?

둘 다 변경된 데이터만 관리할 수 있다는 점에서 비슷해 보일 수 있습니다. 하지만 스냅샷은 특정 시점 상태를 빠르게 되돌리는 기술에 가깝고, 증분백업은 마지막 백업 이후 변경분을 백업 체인으로 저장하는 방식입니다.

Q7. 스냅샷을 쓰지 말아야 하나요?

그렇지 않습니다. 스냅샷은 매우 유용한 기술입니다. 다만 스냅샷만 믿지 말고 정기 백업, 이뮤터블 백업, 오프사이트 백업, 복구 테스트와 함께 사용해야 합니다.

마무리

스냅샷은 특정 시점으로 빠르게 되돌릴 수 있는 강력한 기술입니다. 파일 삭제, 설정 변경, 업데이트 실패, 짧은 RPO가 필요한 환경에서 큰 도움이 됩니다.

하지만 스냅샷은 백업을 완전히 대체할 수 없습니다. 원본 스토리지에 의존할 수 있고, 장기 보관에 적합하지 않을 수 있으며, 관리자 계정 탈취나 랜섬웨어 공격으로 삭제될 수 있습니다.

따라서 스냅샷은 빠른 복구 수단으로 사용하고, 백업은 원본과 분리된 최종 복구 수단으로 운영하는 것이 좋습니다. 중요한 데이터라면 스냅샷, 정기 백업, 3-2-1 백업 원칙, 이뮤터블 백업, 복구 테스트를 함께 구성해야 합니다.

결국 안전한 데이터 보호 전략은 하나의 기술에 의존하지 않는 것입니다. 스냅샷은 빠르게 되돌리는 도구이고, 백업은 마지막까지 데이터를 복구하기 위한 안전망입니다. 두 가지를 함께 사용할 때 데이터 보호 수준이 훨씬 높아집니다.

참고 자료

• AWS - Amazon EBS Snapshots
• Broadcom VMware - Best practices for using VMware snapshots
• Microsoft Learn - Hyper-V Checkpoints
• AWS - S3 Object Lock
• CISA - StopRansomware Guide