13. 백업과 아카이빙
3-2-1 백업 원칙, Full/Incremental/Differential 비교, 백업 방식 4가지(에이전트/스냅샷/이미지/NDMP)의 장단점, 백업 매체(디스크/테이프/클라우드) 비교, 테이프가 아직 살아있는 이유, 백업 SW 생태계, WORM과 컴플라이언스, 복구 테스트의 중요성, 백업과 아카이빙의 차이까지. 데이터의 마지막 보루.
시스템엔지니어가 알려주는 스토리지의 모든 것 시리즈14 / 14
- 112. 데이터 효율화 — 중복제거, 압축, 씬 프로비저닝
- 21. 스토리지, 왜 어렵고 왜 중요한가
- 32. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
- 43. 병렬 파일 시스템과 분산 스토리지 — Lustre, GPFS, HDFS
- 54. 프로토콜 깊이 파기 — FC / iSCSI / NFS / SMB / S3
- 65. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
- 76. 도입 검토 — 요구사항 분석과 벤더 선정
- 87-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
- 97-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
- 108. 구축 — 초기 설정과 호스트 연결
- 119. 인수시험(SAT) — 장비를 내 것으로 만드는 과정
- 1210. 일상 운영 1: 볼륨 할당과 변경 관리
- 1311. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
- 1413. 백업과 아카이빙
글꼴
스냅샷은 백업이 아니다.
7-2편에서 이미 말했지만, 한 번 더 강조한다. 스냅샷은 원본과 같은 스토리지에 있다. 스토리지가 통째로 죽으면 스냅샷도 같이 사라진다. 화재가 나면 원본도 스냅샷도 재가 된다. 랜섬웨어가 스토리지 관리 계정을 탈취하면 스냅샷까지 삭제할 수 있다.
백업은 "원본과 다른 곳에 복사본을 두는 것"이다. 다른 장비, 다른 매체, 다른 사이트. 이게 백업의 본질이다. 복잡한 기술이나 제품 이름에 현혹되기 전에 이 원칙만 기억하면 된다.
3-2-1 원칙 — 백업의 기본 프레임워크
3-2-1 백업 원칙:
3 — 데이터 복사본 3개 (원본 1 + 백업 2)
2 — 서로 다른 매체 2종류 (디스크 + 테이프, 디스크 + 클라우드 등)
1 — 오프사이트 1곳 (물리적으로 다른 장소)
예시:
┌──────────────────────────────────────────────────────┐
│ 복사본 1: 원본 데이터 (프로덕션 스토리지) │
│ 복사본 2: 백업 디스크 (같은 데이터센터, 다른 장비) │
│ 복사본 3: 클라우드 또는 원격 사이트 (오프사이트) │
└──────────────────────────────────────────────────────┘
왜 3개인가: 원본 + 백업 1개면 백업 장비가 죽으면 끝.
왜 2종류: 같은 매체는 같은 취약점을 가진다.
디스크만 2개면 둘 다 랜섬웨어에 감염될 수 있다.
왜 오프사이트: 화재/지진/홍수로 사이트 전체가 날아가면
온사이트 백업은 의미 없다.백업 유형 — Full, Incremental, Differential
월요일에 Full 백업 후, 매일 데이터가 변경되는 상황:
[Full Backup]
월: ████████████████ 100GB (전체)
[Incremental — 마지막 백업 이후 변경분만]
화: ██ 5GB (월→화 변경분)
수: ███ 8GB (화→수 변경분)
목: █ 3GB (수→목 변경분)
복원 시: 월(Full) + 화 + 수 + 목 = 4개 필요
→ 하나라도 깨지면 복원 실패
[Differential — Full 이후 누적 변경분]
화: ██ 5GB (월→화 변경분)
수: █████ 13GB (월→수 누적 변경분)
목: ██████ 16GB (월→목 누적 변경분)
복원 시: 월(Full) + 목(Diff) = 2개만 필요
→ 복원이 단순하고 안전. 대신 백업 크기가 날마다 커짐.┌──────────────────────────────────────────────────────────┐
│ 백업 유형 비교 │
├──────────────┬──────────┬──────────────┬─────────────────┤
│ │ Full │ Incremental │ Differential │
├──────────────┼──────────┼──────────────┼─────────────────┤
│ 백업 시간 │ 길다 │ 짧다 │ 중간 │
├──────────────┼──────────┼──────────────┼─────────────────┤
│ 백업 크기 │ 크다 │ 작다 │ 날마다 커짐 │
├──────────────┼──────────┼──────────────┼─────────────────┤
│ 복원 속도 │ 빠르다 │ 느리다 │ 중간 │
│ │ (1개) │ (Full+변경N개)│ (Full+Diff 1개)│
├──────────────┼──────────┼──────────────┼─────────────────┤
│ 복원 안정성 │ 높다 │ 체인 의존 │ 높다 │
│ │ │ (하나 깨지면 │ (2개만 있으면 됨)│
│ │ │ 이후 전부↓) │ │
├──────────────┼──────────┼──────────────┼─────────────────┤
│ 주 사용 │ 주1회 │ 매일 │ 매일 │
│ │ 기준점 │ (일반적) │ (복원 중시) │
└──────────────┴──────────┴──────────────┴─────────────────┘
현실적 조합: 주 1회 Full + 매일 Incremental (가장 흔함)
복원 안정성 중시: 주 1회 Full + 매일 Differential백업 방식 — 어디서 어떻게 가져오는가
백업 방식별 비교:
┌──────────────────────────────────────────────────────────┐
│ ① 에이전트 기반 (전통 방식) │
│ │
│ [서버] ──에이전트──► [백업 서버] ──► [백업 매체] │
│ │
│ 서버에 백업 에이전트를 설치하고, 에이전트가 파일/DB를 │
│ 읽어서 백업 서버로 전송한다. │
│ │
│ 장점: 파일/DB 레벨 세밀한 복원 가능 (특정 테이블만 등) │
│ 단점: 서버 CPU/네트워크 부하. 백업 윈도우 필요. │
│ 서버마다 에이전트 설치/관리 필요. │
├──────────────────────────────────────────────────────────┤
│ ② 스냅샷 기반 백업 │
│ │
│ [스토리지] ──스냅샷──► [백업 스토리지/클라우드] │
│ │
│ 스토리지 스냅샷을 찍고, 그 스냅샷을 다른 장비/클라우드 │
│ 로 전송한다. (NetApp SnapVault, Pure CloudSnap 등) │
│ │
│ 장점: 서버 부하 없음. 백업이 빠름 (변경분만 전송). │
│ 애플리케이션 일관성 보장 가능 (VSS, Quiesce). │
│ 단점: 스토리지 벤더 종속. 파일 단위 복원이 어려울 수 │
│ 있음 (볼륨 단위 복원이 기본). 벤더가 다르면 │
│ 스냅샷 호환이 안 됨. │
├──────────────────────────────────────────────────────────┤
│ ③ 이미지 레벨 백업 (VMware 환경) │
│ │
│ [ESXi] ──VADP/CBT──► [백업 서버] ──► [백업 매체] │
│ │
│ VM 전체를 이미지로 백업. VMware의 VADP(vStorage APIs │
│ for Data Protection)와 CBT(Changed Block Tracking)를 │
│ 활용해서 변경된 블록만 전송한다. │
│ │
│ 장점: VM 단위 백업/복원. 에이전트 없이 가능. │
│ CBT로 Incremental이 매우 빠름. │
│ 단점: 파일 단위 복원이 추가 작업 필요 (마운트 후 추출).│
│ CBT 버그로 백업 정합성 문제가 보고된 적 있음. │
│ VM 내부 DB의 일관성은 별도 처리 필요. │
├──────────────────────────────────────────────────────────┤
│ ④ NDMP 백업 (NAS 환경) │
│ │
│ [NAS 스토리지] ──NDMP──► [백업 매체(테이프/디스크)] │
│ │
│ NAS 데이터를 백업할 때 서버를 경유하지 않고 스토리지에서│
│ 직접 백업 매체로 전송한다. 네트워크 부하를 줄인다. │
│ │
│ 장점: 서버/LAN 부하 없음. 대용량 NAS 백업에 효율적. │
│ 단점: NDMP 프로토콜이 오래됨. 멀티스트림 제한. │
│ 백업 SW와 NAS 벤더 간 호환성 확인 필요. │
└──────────────────────────────────────────────────────────┘백업 매체 — 어디에 저장할 것인가
┌──────────────────────────────────────────────────────────┐
│ 백업 매체 비교 │
├────────────┬──────────────┬──────────────┬───────────────┤
│ │ 디스크(어플 │ 테이프 │ 클라우드 │
│ │ 라이언스) │ (LTO-9/10) │ (S3 Glacier) │
├────────────┼──────────────┼──────────────┼───────────────┤
│ 복원 속도 │ 빠름 (분~시간)│ 느림 (시간~일)│ 보통~느림 │
│ │ │ (테이프 로딩)│ (Glacier: 시간)│
├────────────┼──────────────┼──────────────┼───────────────┤
│ GB당 비용 │ 높음 │ 매우 낮음 │ 낮음 │
├────────────┼──────────────┼──────────────┼───────────────┤
│ 용량 │ 수십~수백TB │ 수PB 가능 │ 무제한 │
├────────────┼──────────────┼──────────────┼───────────────┤
│ 랜섬웨어 │ 네트워크 │ 오프라인이면 │ Immutable │
│ 내성 │ 접근 가능 │ 안전(에어갭) │ 설정 가능 │
│ │ → 감염 위험 │ │ │
├────────────┼──────────────┼──────────────┼───────────────┤
│ 수명 │ 5~7년 │ 30년+ │ 벤더 의존 │
├────────────┼──────────────┼──────────────┼───────────────┤
│ 적합한 용도│ 1차 백업 │ 장기 보관 │ 오프사이트 │
│ │ (빠른 복원) │ 컴플라이언스 │ DR 백업 │
└────────────┴──────────────┴──────────────┴───────────────┘테이프가 아직 살아있는 이유:
┌──────────────────────────────────────────────────────┐
│ "테이프? 아직 쓰는 데가 있어?" │
│ │
│ 있다. 그것도 많다. │
│ │
│ · GB당 비용이 가장 싸다. PB급 장기 보관에는 테이프가 │
│ 디스크/클라우드 대비 압도적으로 저렴. │
│ · 에어갭(Air Gap): 테이프를 꺼내서 금고에 넣으면 │
│ 네트워크와 물리적으로 단절. 랜섬웨어가 못 건드린다. │
│ · LTO-9: 비압축 18TB / 압축 45TB. LTO-10은 더 큼. │
│ · 전력 소비 없음. 보관만 하면 전기 안 먹음. │
│ │
│ 단점: │
│ · 복원이 느리다. 테이프 로딩 + 순차 읽기. │
│ · 테이프 라이브러리(로봇) 유지보수가 필요. │
│ · 테이프 매체의 물리적 관리(보관, 이동, 폐기). │
│ · 랜덤 접근 불가. 특정 파일 하나만 복원하려면 │
│ 테이프 전체를 읽어야 할 수 있다. │
└──────────────────────────────────────────────────────┘백업 소프트웨어 — 벤더 복제와의 역할 분담
┌──────────────────────────────────────────────────────────┐
│ 주요 백업 소프트웨어 │
├──────────────┬───────────────────────────────────────────┤
│ Veeam │ VMware/Hyper-V 환경에서 사실상 표준. │
│ │ 직관적 UI. NAS 백업도 지원. │
│ │ 장점: 학습 곡선 낮음, 복원이 간편 │
│ │ 단점: 물리 서버/유닉스는 상대적으로 약함 │
├──────────────┼───────────────────────────────────────────┤
│ Veritas │ 대규모 이기종 환경의 전통 강자. │
│ NetBackup │ 물리/가상/클라우드 모두 커버. │
│ │ 장점: 검증된 안정성, 테이프 연동 강력 │
│ │ 단점: 복잡함. 라이선스 비용 높음. │
├──────────────┼───────────────────────────────────────────┤
│ Commvault │ 통합 데이터 관리 플랫폼. │
│ │ 백업 + 아카이빙 + DR을 하나로. │
│ │ 장점: 기능이 풍부 │
│ │ 단점: 초기 구축 복잡. 가격 높음. │
├──────────────┼───────────────────────────────────────────┤
│ Dell │ Dell 생태계에서 강점. │
│ NetWorker/ │ 장점: PowerProtect DD(Data Domain)와 │
│ Avamar │ 네이티브 통합 │
│ │ 단점: Dell 외 환경에서는 장점이 줄어듦 │
└──────────────┴───────────────────────────────────────────┘
벤더 네이티브 복제 vs 백업 소프트웨어:
┌──────────────────────────────────────────────────────┐
│ 스토리지 벤더 복제 (SnapMirror, PowerProtect 등) │
│ → 볼륨 단위 복제. 빠르고 효율적. │
│ → 같은 벤더 장비 간에서만 동작. │
│ → 파일 단위 복원은 어려움 (볼륨 통째로 복원). │
│ │
│ 백업 소프트웨어 (Veeam, Commvault 등) │
│ → 파일/DB/VM 단위 세밀한 복원 가능. │
│ → 이기종 환경 지원 (벤더 무관). │
│ → 컴플라이언스 보관/검색 기능. │
│ → 벤더 복제보다 느림. │
│ │
│ 현실적 조합: │
│ · 1차 보호: 스토리지 스냅샷 + 벤더 복제 (빠른 복원) │
│ · 2차 보호: 백업 SW로 디스크/테이프/클라우드 (장기) │
│ · 두 가지를 병행하는 게 3-2-1 원칙에 부합한다. │
└──────────────────────────────────────────────────────┘장기 보관과 컴플라이언스
데이터를 10년 동안 보관해야 하는 경우가 있다. 금융, 의료, 공공기관.
┌──────────────────────────────────────────────────────┐
│ 산업별 데이터 보관 요구 │
├───────────────┬──────────────────────────────────────┤
│ 금융 (한국) │ 전자금융거래 기록 5년, │
│ │ 회계 증빙 10년 │
├───────────────┼──────────────────────────────────────┤
│ 의료 │ 진료 기록 10년 (의료법) │
│ │ 영상(PACS) 5~10년 │
├───────────────┼──────────────────────────────────────┤
│ 공공기관 │ 기록물 관리법에 따라 영구~30년 │
├───────────────┼──────────────────────────────────────┤
│ 일반 기업 │ 내부 정책에 따라 3~7년이 일반적 │
└───────────────┴──────────────────────────────────────┘장기 보관에 쓰이는 기술:
WORM (Write Once Read Many):
한번 쓰면 수정/삭제가 불가능한 스토리지.
컴플라이언스 보관의 핵심 기술이다.
┌──────────────────────────────────────────────────────┐
│ 구현 방식 │ 특징 │
├────────────────────┼─────────────────────────────────┤
│ 하드웨어 WORM │ 테이프(LTO WORM 카트리지), │
│ │ 광디스크. 물리적으로 수정 불가. │
├────────────────────┼─────────────────────────────────┤
│ 소프트웨어 WORM │ NetApp SnapLock, Dell │
│ │ Compliance Mode 등. │
│ │ 보관 기간 내 삭제/수정 차단. │
│ │ 관리자도 못 지운다. │
├────────────────────┼─────────────────────────────────┤
│ 클라우드 WORM │ AWS S3 Object Lock, │
│ │ Azure Immutable Storage. │
│ │ Compliance 모드면 루트도 삭제불가│
└────────────────────┴─────────────────────────────────┘
WORM의 장점: 랜섬웨어가 삭제 못 함. 감사/법적 요구 충족.
WORM의 단점: 실수로 잘못된 데이터를 WORM에 넣으면
보관 기간이 끝날 때까지 삭제할 수 없다.
보관 기간 설정을 신중하게 해야 한다.백업 복구 테스트 — 안 하면 백업이 아니다
백업을 매일 잘 하고 있어도, 복원이 되는지 확인 안 했으면 의미가 없다. 테이프가 있는데 테이프 드라이브가 고장나서 읽을 수 없다. 백업 파일이 있는데 DB 버전이 안 맞아서 복원이 안 된다. 이런 일이 실제로 일어난다.
백업 복구 테스트 프로세스:
┌──────────────────────────────────────────────────────┐
│ 주기: 최소 분기 1회. 미션 크리티컬은 월 1회 권장. │
│ │
│ 테스트 방법: │
│ 1. 백업에서 데이터를 실제로 복원한다 │
│ (테스트 환경으로. 프로덕션에 덮어쓰면 안 됨!) │
│ 2. 복원된 데이터의 정합성을 확인한다 │
│ · 파일: md5sum 비교 │
│ · DB: 테이블 카운트, 체크섬 │
│ 3. 복원 소요 시간을 측정한다 │
│ → 이게 실제 RTO와 부합하는지 확인 │
│ 4. 결과를 기록한다 │
│ │
│ 복원 시간 측정이 중요한 이유: │
│ "RTO 4시간"이라고 써놨는데, 실제로 복원해보면 │
│ 8시간 걸리는 경우가 있다. 이걸 장애 때 처음 발견하면 │
│ 이미 늦은 거다. 테스트 때 알아야 한다. │
│ │
│ 복원 테스트를 안 하면 벌어지는 일: │
│ · 백업 파일이 있는데 깨져서 복원 불가 │
│ · 테이프가 있는데 드라이브 호환 안 됨 │
│ · 백업은 됐는데 DB 복원 절차를 아무도 모름 │
│ · 복원에 24시간 걸리는데 RTO는 4시간 │
│ → 전부 "테스트했으면 미리 알았을 것"들이다. │
└──────────────────────────────────────────────────────┘백업 윈도우와 RPO
백업 윈도우: 백업을 실행할 수 있는 시간대.
업무 시간(09~18시)에 Full 백업을 돌리면 서비스 성능에 영향.
→ 보통 야간(22시~06시)에 백업 윈도우를 잡는다.
→ 8시간 안에 백업이 안 끝나면? 아침에 서비스와 겹침.
백업 윈도우가 부족할 때:
┌──────────────────────────────────────────────────────┐
│ · Incremental 주기 늘리기 (Full 빈도 줄이기) │
│ · 스냅샷 기반 백업으로 전환 (서버 부하 제거) │
│ · 백업 대역폭 늘리기 (10G → 25G) │
│ · 백업 스트림 수 늘리기 (병렬 백업) │
│ · 불필요한 데이터 백업에서 제외 (로그, 임시 파일) │
└──────────────────────────────────────────────────────┘
RPO와 백업 주기:
┌──────────────┬──────────────────────────────────────┐
│ RPO 요구 │ 백업 전략 │
├──────────────┼──────────────────────────────────────┤
│ RPO = 0 │ 동기 복제 (7-2편). 백업만으로는 불가.│
├──────────────┼──────────────────────────────────────┤
│ RPO < 1시간 │ 스냅샷 매시간 + 비동기 복제 │
├──────────────┼──────────────────────────────────────┤
│ RPO < 24시간 │ 일 1회 백업 (가장 일반적) │
├──────────────┼──────────────────────────────────────┤
│ RPO < 1주일 │ 주 1회 Full (비핵심 데이터) │
└──────────────┴──────────────────────────────────────┘
RPO 4시간인데 일 1회 백업만 하면?
→ 장애 시 최대 24시간치 데이터 유실. RPO 위반.
→ RPO에 맞는 백업 주기를 설계해야 한다.아카이빙 — 백업과 다르다
백업과 아카이빙은 목적이 다르다.
┌──────────────────────────────────────────────────────┐
│ 백업: "복구"가 목적. 장애 시 데이터를 되돌린다. │
│ 보관 기간이 비교적 짧다 (주~월 단위). │
│ 최신 데이터가 중요. │
│ │
│ 아카이빙: "보관"이 목적. 오래된 데이터를 저비용 매체로│
│ 옮겨서 장기 보관한다. │
│ 보관 기간이 길다 (년~영구). │
│ 검색/조회가 가능해야 한다 (컴플라이언스). │
└──────────────────────────────────────────────────────┘
아카이빙의 효과:
프로덕션 스토리지에 5년치 데이터가 쌓여있다.
최근 1년 데이터만 자주 접근하고, 나머지 4년은 거의 안 본다.
4년치를 아카이브 스토리지(Object Storage, 테이프)로 이동하면:
· 프로덕션 스토리지 용량 확보 (증설 시기 연장)
· 프로덕션 성능 개선 (데이터 양 감소 → 메타데이터 부하 감소)
· 비용 절감 (올플래시 → 저비용 매체)
아카이빙의 리스크:
· "아카이브에 있는 데이터를 급히 조회해야 하는데 느리다"
→ 아카이브 매체(테이프, Glacier)는 접근이 느리다.
접근 빈도를 잘못 판단하면 사용자 불만 발생.
· 아카이브 데이터의 무결성 검증을 안 하면
10년 뒤 "필요할 때 깨져있었다"가 될 수 있다.
→ 정기적 무결성 검증(checksum 확인) 필요.
· 포맷 호환성: 10년 뒤에 지금 백업 SW의 포맷을
읽을 수 있는가? 벤더가 존재하는가?
→ 오픈 포맷(tar, SQL dump 등) 병행 권장.백업과 아카이빙은 "또는"이 아니라 "그리고"다. 둘 다 해야 한다. 백업은 장애 대비, 아카이빙은 비용 최적화와 컴플라이언스. 목적이 다르니 대체가 안 된다.
다음 편에서는 보안과 랜섬웨어 대응을 다룬다. 암호화, 접근 제어, 그리고 랜섬웨어가 스토리지를 노릴 때 어떻게 막을 것인가.
이 글이 어떠셨나요?
관련 포스트
Infrastructure
12. 데이터 효율화 — 중복제거, 압축, 씬 프로비저닝
중복제거 동작 원리와 인라인/포스트프로세스 차이, 압축 알고리즘(LZ4 vs ZSTD) 비교, 컴팩션과 쓰기 증폭(WAF), 씬 프로비저닝의 오버프로비저닝 위험, 벤더별 효율화 구현 차이, "5:1 리덕션"의 진실과 측정 기준의 함정까지. 공짜 점심은 없다.
2026. 06. 22. PM 10:00Infrastructure11. 일상 운영 2: 모니터링, 성능 튜닝, 용량 관리
스토리지 모니터링 핵심 메트릭(Latency/IOPS/Throughput/Queue Depth), 성능 병목 분석 흐름, QoS 설정과 벤더별 차이, 씬 프로비저닝 용량 관리의 위험, 긴급 용량 확보 방법까지. 장애가 터지기 전에 잡는 일상 운영의 기술.
2026. 06. 15. PM 10:00Infrastructure10. 일상 운영 1: 볼륨 할당과 변경 관리
스토리지 운영의 70%를 차지하는 일상 업무. 볼륨 할당 워크플로우, 벤더별 프로비저닝 CLI, 볼륨 확장/삭제의 주의사항, 변경 관리 위험도 분류, 서비스 카탈로그까지. 실수 한 번이 데이터를 날리는 영역의 안전한 운영법.
2026. 06. 08. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.
댓글
댓글을 불러오는 중...