업무용 NAS에서 삭제한 파일을 스냅샷으로 되살렸다면, 장비가 고장 나도 같은 방법으로 복구할 수 있을 것처럼 느껴질 수 있다. 그러나 같은 저장 공간에 남겨 둔 복구 시점은 그 저장 공간을 잃는 사고까지 해결해 주지 않는다. 데이터 보호를 설계할 때는 복구 메뉴의 유무보다 원본이 사라져도 복구에 필요한 데이터와 권한이 남는지부터 확인해야 한다.
스냅샷은 시점 보존 기술, 백업은 복구를 위한 체계
스냅샷은 특정 시점의 데이터 상태를 보존하는 기술이다. 파일시스템이나 스토리지의 로컬 스냅샷은 원본과 데이터 블록을 공유하고, 변경 전 블록이나 참조 정보를 유지하는 방식으로 구현되는 경우가 많다. 생성할 때마다 전체 데이터를 다른 장치에 복사하는 방식과는 다르며, 구현에 따라 저장 위치와 복구 조건도 달라진다.
백업은 손실에 대비해 복구용 데이터를 만들고 보관하며, 필요한 시점에 되살릴 수 있도록 관리하는 체계다. 복사 작업뿐 아니라 보존 기간, 접근 권한, 암호화 키, 복구 절차와 검증까지 포함한다. 따라서 스냅샷과 백업을 서로 배타적인 기술로 구분하면 실제 제품의 동작을 잘못 이해할 수 있다.
예를 들어 AWS는 EBS 스냅샷을 시점 복사본이자 증분 백업으로 설명하며, 일반적인 리전의 EBS 스냅샷은 원본 볼륨과 별도로 S3에 저장한다. ‘스냅샷은 언제나 원본 장비 안에만 있다’는 설명은 맞지 않는다. 이 글에서 주의하는 대상은 원본과 같은 장애 범위에만 존재하는 로컬 스냅샷이다. AWS EBS 스냅샷 문서에서 이 차이를 확인할 수 있다.
비교 기준은 복사본의 이름보다 의존성
| 판단 항목 | 원본 저장소의 로컬 스냅샷 | 별도 저장소에 보관하는 백업 |
|---|---|---|
| 주된 용도 | 최근 삭제·수정의 빠른 되돌리기 | 원본 손실과 장기 보존에 대비한 복구 |
| 원본 저장소 의존성 | 같은 풀·볼륨의 정상 동작에 의존할 수 있음 | 필요한 데이터가 모두 전송됐다면 원본 없이 복구하도록 설계 가능 |
| 저장 공간 | 변경량·보존 기간에 따라 사용량 증가 | 데이터량·버전·압축·중복 제거 등에 따라 달라짐 |
| 관리자 계정 침해 | 삭제 권한까지 탈취되면 함께 손실될 수 있음 | 별도 계정·삭제 제한이 없으면 함께 손실될 수 있음 |
| 복구 시간 | 파일 단위 복원은 빠를 수 있음 | 전송량·복원 대상·검증 범위에 따라 달라짐 |
| 반드시 확인할 사항 | 지원 대상, 보존 정책, 여유 용량 | 원본 독립성, 키·카탈로그 확보, 실제 복원 가능성 |
이 표는 대표적인 구성의 비교이며 모든 제품에 동일하게 적용되는 성능 보장은 아니다. 스냅샷 복제본을 다른 장비에 보관하면 장애 범위를 넓힐 수 있고, 백업 소프트웨어로 만든 파일도 원본과 같은 디스크에만 저장하면 장비 손실에 취약하다. 다른 폴더나 볼륨으로 나눴다는 사실만으로 물리적 분리가 성립하지는 않는다.
스냅샷은 공짜 저장 공간도 아니다. 변경이 많은 데이터의 과거 블록을 오래 유지하면 공간이 계속 필요하다. 파일을 지워도 스냅샷이 해당 블록을 참조하면 기대만큼 여유 공간이 늘지 않을 수 있다. Synology의 DSM 7.2 사양도 스냅샷 보존 규칙과 공간 관리 기능을 제공하며 모델별 한계가 다르다고 설명한다. 구체적인 지원 범위는 Snapshot Replication 기술 사양을 기준으로 확인한다.
사고 유형에 따라 달라지는 사용 복구 수단
문서 하나를 잘못 덮어썼다면 해당 파일의 과거 버전을 찾아 별도 경로로 복원하는 방법이 적합하다. 반면 스토리지 풀 손상이나 NAS 분실로 로컬 스냅샷까지 접근할 수 없다면 다른 장비나 외부 저장소의 복구본이 필요하다. 공유 폴더 전체를 과거 시점으로 되돌리면 사고 이후 정상적으로 수정한 파일도 영향을 받을 수 있으므로 복구 범위를 먼저 결정해야 한다.
랜섬웨어 사고에서는 감염 전 복구 시점이 남아 있는지와 공격자가 그 시점을 삭제할 수 있는지가 관건이다. 일반 사용자에게 수정 권한이 없는 스냅샷은 도움이 될 수 있지만, 관리자 권한 탈취나 저장소 파괴까지 자동으로 막아 주지는 않는다. 원격 복제도 오염된 최신 데이터를 전달할 수 있으므로 과거 버전과 보존 정책을 함께 확인한다.
CISA는 중요 데이터의 오프라인·암호화 백업과 정기적인 가용성·무결성 시험을 권고한다. 이를 운영에 적용할 때는 접근 가능한 복구본 외에 공격자의 권한으로 지우기 어려운 사본을 마련하고, 복구 전에 감염 원인과 복구 데이터의 상태를 확인하는 절차를 둔다. 불변 보관은 설정된 기간의 변경·삭제를 제한하는 수단이고, 오프라인 보관은 연결을 끊는 수단이므로 같은 의미로 취급하지 않는다. 근거는 CISA의 랜섬웨어 대응 가이드다.
파일 복구와 업무 시스템 복구를 구분
파일이 열리는 것과 업무 시스템이 정상 동작하는 것은 다르다. 데이터베이스는 메모리에 남아 있던 변경 사항, 트랜잭션 로그, 여러 볼륨 사이의 시점 차이 때문에 단순한 디스크 시점 보존만으로 원하는 복구 상태를 보장하기 어렵다. 장애 직후처럼 복구 절차가 필요한 상태와 애플리케이션이 정합성을 맞춘 상태를 구분해 설계해야 한다.
AWS도 EBS 스냅샷에는 애플리케이션이나 운영체제의 캐시에만 있던 데이터가 포함되지 않는다고 명시한다. 실제 환경에서는 DB가 지원하는 백업, 로그 보관, 쓰기 일시 정지나 애플리케이션 연계 기능 중 적합한 방식을 선택한다. EBS 스냅샷 생성 시 고려사항은 특정 제품의 예이며, 이를 모든 DB의 공통 작업 절차로 그대로 적용해서는 안 된다.
복구 데이터만 남고 암호화 키나 관리자 접근 수단을 잃어도 복원은 막힐 수 있다. 백업 대상 목록에 데이터 외에 필요한 설정, 키의 복구 경로, 계정, 라이선스와 복구 도구를 함께 기록한다. 다만 이 정보를 누구나 접근하는 백업 폴더에 평문으로 모아 두는 방식은 피하고 별도의 접근 통제를 적용한다.
소규모 기업 NAS에 적용하는 보호 정책 예시
다음은 실제 운영 결과가 아닌 설계 검토용 가상 예시다. 부서 공유 문서를 NAS에 보관하고, 최근 실수의 빠른 복구와 장비 손실 시 복구를 모두 원한다고 가정한다. 주기와 보존 기간은 데이터 변경량, 업무상 허용 손실, 용량에 맞춰 조정한다.
| 계층 | 가상 정책 | 확인할 조건 |
|---|---|---|
| 빠른 복구 | 업무 시간에 1시간 간격 로컬 스냅샷, 최근 7일 보존 | 대상 폴더 포함 여부와 변경량에 따른 용량 |
| 장비 손실 대비 | 매일 별도 장비로 버전 백업, 일별 30일 보존 | 원본 없이 복원 가능한지, 계정이 분리됐는지 |
| 동일 장소 사고 대비 | 외부 장소에 추가 사본 보관 | 같은 전원·화재·침수 범위를 벗어나는지 |
| 삭제·변조 대비 | 지원되는 불변 보관 또는 오프라인 사본 운영 | 잠금 기간, 삭제 권한, 연결·반출 절차 |
| 복구 검증 | 월별 표본 복원과 주요 변경 후 추가 시험 | 문서 내용·권한·복원 시간·실패 원인 기록 |
이 구성에서 로컬 스냅샷이 매시간 생성돼도 NAS 전체가 손실되면 일별 백업이 복구 기준이 될 수 있다. RPO는 허용할 데이터 손실의 시간 범위이고, RTO는 복구에 허용할 시간 목표다. 스케줄만으로 실제 달성 여부가 정해지지 않으며 마지막 성공 시점, 전송 지연, 복구 환경을 함께 확인해야 한다.
예를 들어 마지막 정상 백업의 기준 시점이 전날 23시이고 다음 날 15시에 원본을 잃었다면, 다른 복구 수단이 없을 때 되돌리지 못할 수 있는 업무 구간은 16시간이다. 이는 설정 화면의 ‘매일 백업’이라는 표현보다 구체적인 손실 범위다. 업무가 1시간 손실만 허용한다면 장비 손실에 대비한 별도 사본의 생성·전송 주기도 다시 설계해야 한다.
실무자 관점: 성공 알림보다 원본 없는 복구를 확인
운영 관점에서 가장 먼저 확인할 것은 ‘어제 작업 성공’ 표시보다 ‘원본 NAS를 사용할 수 없어도 복구를 시작할 수 있는가’다. 같은 관리자 계정으로 운영 NAS와 백업 장비를 모두 지울 수 있다면 물리적 분리의 효과가 권한 측면에서 약해진다. 반대로 장비를 무작정 늘리면 계정·패치·용량·복구 절차를 관리하지 못해 복잡성만 커질 수 있다.
최소한 다음 네 가지를 실제 시험 기록으로 남기는 편이 유용하다. 첫째, 운영 경로와 분리된 장소로 파일을 복원한다. 둘째, 복원한 내용과 권한을 확인한다. 셋째, 준비부터 검증까지 걸린 시간을 측정한다. 넷째, 원본 계정이나 장비를 사용할 수 없는 상황에서도 필요한 키와 절차를 확보할 수 있는지 점검한다. 서비스 전체 복구는 이 파일 시험과 별도로 애플리케이션 기동과 업무 기능까지 확인한다.
스냅샷은 최근 변경을 빠르게 되돌리는 계층에, 독립된 복구본은 원본을 잃는 사고에 대응하는 계층에 배치한다. 구매나 설정 변경의 판단 기준은 기능 이름보다 어떤 사고 이후에도 어떤 시점의 데이터를 얼마 만에 복구할 수 있는가다. 그 답을 시험으로 확인할 수 있어야 보호 전략이 실제 운영 절차가 된다.