
외장 HDD 하나만 믿고 몇 년을 버텼습니다. 그러다 어느 날 PC가 드라이브를 아예 인식하지 못했고, 복구 업체 견적은 수십만 원이었습니다. 그 사건 이후 백업을 처음부터 다시 설계했는데, 그때 처음 제대로 들여다본 것이 3-2-1 백업 전략이었습니다. 알고 보니 "백업을 하고 있다"는 착각과 "실제로 복구 가능한 백업"은 완전히 다른 이야기였습니다.
3-2-1 원칙이해 — 규칙은 단순한데 왜 지키기가 어려울까
3-2-1 백업 전략의 구조 자체는 단순합니다. 데이터의 복사본을 총 3개 유지하고, 서로 다른 미디어 유형 2가지에 나눠 저장하며, 그중 1개는 오프사이트(off-site), 즉 물리적으로 다른 장소에 보관하는 것입니다. 이 원칙은 사진작가이자 디지털 자산 관리 전문가인 Peter Krogh가 《The DAM Book》(O'Reilly, 2009)에서 공식화한 프레임워크로, 현재 미국 CISA(사이버보안 및 인프라 보안청)의 백업 가이드에서도 표준 기준으로 인용될 만큼 공신력을 인정받고 있습니다(출처: SentinelOne).
여기서 '오프사이트'란 단순히 다른 드라이브가 아니라, 화재나 침수 같은 물리적 재난이 발생했을 때 함께 소실되지 않는 장소를 의미합니다. 저처럼 외장 HDD를 책상 서랍에 넣어두는 것은 오프사이트가 아닙니다. PC 옆에 NAS를 두는 것도 마찬가지입니다. 같은 공간에 있는 순간, 재난 앞에서는 같은 운명입니다.
일반적으로 "외장 HDD 하나면 백업은 충분하다"고 생각하는 분들도 있는데, 저는 그게 착각이라는 걸 하드웨어 고장으로 직접 배웠습니다. HDD는 기계식 장치라 언제든 예고 없이 멈춥니다. 3-2-1은 그 단일 장애점(Single Point of Failure)을 구조적으로 없애는 전략입니다. 쉽게 말해, 한 곳이 망가져도 다른 두 곳이 살아있도록 설계하는 것입니다.
- 복사본 1 (원본) — PC 또는 노트북 내장 스토리지
- 복사본 2 (로컬 백업) — NAS 또는 외장 HDD (다른 미디어 유형)
- 복사본 3 (오프사이트) — Backblaze B2, 구글 드라이브 같은 클라우드, 또는 외장 드라이브를 다른 장소에 보관
복구테스트 — 설정해 놓고 잊어버리는 백업의 함정
백업을 설정해 두면 안심이 됩니다. 그런데 제가 직접 써봤는데, 그 안심이 얼마나 위험한 착각인지 꽤 늦게 깨달았습니다. 시놀로지 NAS를 구축하고 나서 실제로 복원 테스트를 해본 건 딱 한 번이었는데, 그 첫 테스트에서 바로 문제가 터졌습니다. 백업된 폴더에서 파일을 꺼내려 했더니 권한 설정 오류로 파일이 열리지 않았습니다. 백업은 분명히 돌아가고 있었는데, 복구는 안 됐습니다.
이 경험이 저한테는 꽤 충격적이었습니다. 백업 소프트웨어가 매일 밤 작업 완료 알림을 보내줬으니 당연히 이상 없다고 생각했거든요. 그런데 "파일이 복사되어 있다"는 것과 "그 파일을 실제로 꺼내 쓸 수 있다"는 건 전혀 다른 이야기였습니다. 복구 테스트 없는 백업은 있는 척하는 백업입니다.
개인용 백업에서 또 흔히 놓치는 부분이 있습니다. 처음 설정만 해두고 몇 달씩 방치하는 경우입니다. 클라우드 스토리지 용량이 꽉 차거나, 네트워크 오류로 동기화가 멈춰도 모르고 지나치는 일이 생각보다 잦습니다. 어느 날 갑자기 파일이 필요한 상황이 됐을 때, 마지막 백업이 6개월 전이라는 걸 발견하는 상황이 실제로 발생합니다.
이후 저는 분기마다 임의 파일 하나를 골라 직접 복원해보는 루틴을 만들었습니다. 거창한 게 아니라, 캘린더에 "백업 복원 테스트" 일정을 넣고 파일 하나를 꺼내 열어보는 것입니다. 최근 권장되는 3-2-1-1-0 전략에서 마지막 '0'이 바로 이 복구 오류 제로, 즉 검증된 복구를 의미합니다. 여기서 3-2-1-1-0이란 기존 3-2-1에 변경 불가능한 이뮤터블(immutable) 백업 1개와 복구 테스트 완료(오류 0건)를 추가한 확장 전략입니다.
랜섬웨어대응 — NAS도 이제 안전하지 않습니다
일반적으로 "NAS에 백업해두면 안전하다"고 알려져 있지만, 제 경험상 이건 좀 다릅니다. 랜섬웨어(ransomware)는 이제 NAS와 백업 어플라이언스까지 직접 표적으로 삼습니다. 여기서 랜섬웨어란 피해자의 파일을 암호화한 뒤 복호화 키를 댓가로 금전을 요구하는 악성 소프트웨어를 말합니다. 공격자 입장에서는 백업이 살아있으면 몸값 협상력이 없어지기 때문에, 최근 공격 패턴은 주 시스템과 연결된 백업 저장소를 동시에 노리는 방식으로 진화하고 있습니다(출처: SentinelOne).
NAS가 PC와 상시 연결된 상태라면, PC가 감염되는 순간 NAS의 공유 폴더도 함께 암호화될 수 있습니다. 이 문제를 막는 핵심 개념이 에어갭(air-gap) 백업입니다. 에어갭이란 네트워크나 물리적 연결이 완전히 차단된 상태를 의미하는데, 쉽게 말해 평소에는 연결되어 있지 않고 백업할 때만 잠깐 연결했다가 분리하는 방식입니다. 외장 드라이브를 백업 후 물리적으로 뽑아두는 것이 가장 단순한 에어갭 구현입니다.
또 NIST 사이버보안 프레임워크(NIST CSF)는 PR.DS-11 제어를 통해 데이터 백업의 무결성을 강화하도록 요구하고 있는데, 이 원칙의 핵심 중 하나가 바로 이뮤터블(immutable) 백업입니다. 이뮤터블 백업이란 일정 기간 동안 누구도 수정하거나 삭제할 수 없도록 잠긴 상태로 저장되는 백업을 말합니다. Backblaze B2 같은 클라우드 스토리지는 오브젝트 락(Object Lock) 기능으로 이 이뮤터블 백업을 구현할 수 있어, 랜섬웨어 공격이 클라우드 백업까지 손을 뻗더라도 해당 데이터만큼은 보호됩니다.
RAID는 백업이 아닙니다 — 가장 많이 하는 오해
솔직히 이건 저도 처음에 헷갈렸습니다. NAS를 2베이로 구성하고 RAID 1로 설정해두면 "드라이브 두 개에 같은 데이터가 있으니 백업 아닌가?"라고 생각했습니다. 결론부터 말하면, RAID는 백업이 아닙니다.
RAID(Redundant Array of Independent Disks)란 여러 개의 디스크를 하나처럼 묶어 드라이브 장애에 대비하는 폴트 톨러런스(fault tolerance) 메커니즘입니다. 쉽게 말해, 드라이브 하나가 고장 났을 때 서비스가 멈추지 않도록 해주는 기술이지, 데이터를 별도 장치에 복사해두는 백업과는 근본적으로 다릅니다. RAID 1로 미러링되어 있어도 실수로 파일을 삭제하면 두 드라이브에서 동시에 사라지고, 랜섬웨어가 파일을 암호화하면 두 드라이브 모두 암호화됩니다(출처: ASUSTOR).
마찬가지로 스냅샷(snapshot)도 종종 백업으로 오해받습니다. 스냅샷이란 특정 시점의 파일 시스템 상태를 기록해두는 기능인데, 별도의 물리적 장치에 데이터를 복사하는 것이 아니라 같은 장치 안에서 변경 이력을 관리하는 방식입니다. 스냅샷이 저장된 NAS가 통째로 망가지거나 도난당하면 스냅샷도 함께 사라집니다. 3-2-1 원칙에서 말하는 "2가지 다른 미디어 유형"이 의미하는 것은 바로 이 물리적 분리를 전제로 합니다.
제가 NAS를 도입하면서 가장 먼저 확인한 것이 바로 이 부분이었습니다. RAID 구성과 별도로, 중요 폴더는 Backblaze B2에 자동 복제되도록 설정했고, 스마트폰 사진은 구글 포토와 NAS에 동시 업로드되도록 구성했습니다. RAID는 "운영 안정성"을 위한 것이고, 클라우드 복제는 "재해 복구"를 위한 것이라고 구분하니 구성이 훨씬 명확해졌습니다.
자주 묻는 질문
Q. NAS 하나 있으면 3-2-1 백업 완성되는 거 아닌가요?
A. NAS는 로컬 백업 역할(복사본 2)은 담당하지만, 오프사이트 복사본(복사본 3)이 없으면 3-2-1이 완성되지 않습니다. NAS와 PC가 같은 공간에 있으면 화재, 침수, 또는 랜섬웨어 공격 시 동시에 피해를 입을 수 있습니다. Backblaze B2나 구글 드라이브 같은 클라우드 백업을 추가해야 비로소 3-2-1 구조가 갖춰집니다.
Q. RAID 1로 NAS 구성하면 백업되는 거 맞지 않나요?
A. RAID 1은 드라이브 한 개가 고장 났을 때 데이터를 보존하는 폴트 톨러런스 기술이지, 백업이 아닙니다. 파일을 실수로 삭제하거나 랜섬웨어가 파일을 암호화하면 미러링된 두 드라이브 모두 동시에 영향을 받습니다. 제 경험상 이걸 가장 많이 헷갈리더라고요. RAID 구성과 별개로 외부 복사본이 반드시 필요합니다.
Q. 백업 복구 테스트는 얼마나 자주 해야 하나요?
A. 최소 분기 1회를 권장합니다. 매번 전체 복원을 할 필요는 없고, 임의 파일 하나를 골라 실제로 복원해서 열어보는 것으로 충분합니다. 저는 캘린더에 고정 일정으로 넣어뒀는데, 그냥 생각날 때 하다 보면 몇 달씩 건너뛰기 일쑤였습니다. 3-2-1-1-0 전략의 마지막 '0'이 바로 이 복구 오류 제로를 의미한다고 이해하면 기억하기 쉽습니다.
Q. 클라우드 백업만으로 3-2-1을 대체할 수 있나요?
A. 클라우드 하나만으로는 부족합니다. 3-2-1은 2가지 다른 미디어 유형을 요구하기 때문에, 클라우드 서비스 두 곳에 올리는 것만으로는 미디어 다양성 요건을 완전히 충족하기 어렵습니다. 또 클라우드는 인터넷 연결이 없을 때나 서비스가 중단됐을 때 접근이 불가능하다는 약점이 있어, 로컬 백업과 조합하는 것이 가장 안정적입니다.
결론
외장 HDD 하나를 믿었다가 수십만 원짜리 견적서를 받아든 그날 이후로, 저는 백업을 "설정"이 아니라 "운영"으로 바라보게 됐습니다. 3-2-1 백업 전략은 복잡한 개념이 아닙니다. 하지만 원칙을 안다고 해서 저절로 실천되지는 않습니다. 용량이 꽉 찼는지, 동기화가 멈추지 않았는지, 그리고 실제로 복구가 되는지를 주기적으로 확인하는 루틴이 없으면, 아무리 잘 설계된 백업도 언젠가는 빈껍데기가 됩니다.
지금 당장 할 수 있는 가장 간단한 첫 걸음은 이렇습니다. 현재 백업 구성을 3-2-1 체크리스트에 맞춰 한 번 점검해보고, 오프사이트 백업이 없다면 Backblaze B2나 구글 드라이브 중 하나를 추가하는 것입니다. 그리고 파일 하나를 복원해 보십시오. 그 한 번의 테스트가 나중에 정말 필요한 순간에 얼마나 큰 차이를 만드는지, 저는 이미 알고 있습니다.
참고: SentinelOne, "3-2-1 백업 전략이란 무엇인가?" | ASUSTOR, "3-2-1 준거 백업 도입" | Zmanda, "3-2-1-1-0 백업 규칙 이해" | Dropbox, "3-2-1 백업 전략"
'IT적응기' 카테고리의 다른 글
| 2단계 인증 완전 정복 (보안 강도, TOTP 앱, 패스키) (0) | 2026.07.04 |
|---|---|
| 피싱 이메일 분석 (메일 헤더, 발신자 확인, 모의 훈련) (0) | 2026.07.03 |
| 제로 트러스트 (ZTA 원칙, VPN 한계, MFA 실천) (0) | 2026.07.01 |
| 재택근무 보안 (네트워크, VPN, 제로트러스트) (1) | 2026.06.30 |
| IT 프리랜서 네트워크 외주 (현실, 범위 크리프, 생존전략) (0) | 2026.06.29 |