server-basic(2)

김재현·1일 전

백업은 "했다"가 중요한 게 아니라 "복구할 수 있다" 가 중요합니다. 이 글에서는 백업의 기본 개념부터 3-2-1 원칙, 랜섬웨어 시대의 백업 전략, 그리고 많은 조직이 놓치는 복구 테스트까지 정리합니다.

1. 백업이 필요한 이유

서버 데이터가 사라지는 원인은 생각보다 다양합니다.

▶ 표 1. 데이터 손실의 주요 원인

원인	예시
하드웨어 장애	디스크 고장, 스토리지 장애
사람의 실수	실수로 파일·DB 삭제, 잘못된 설정 변경
소프트웨어 오류	패치 실패, 데이터 손상
악성 행위	랜섬웨어, 내부자의 고의 삭제
재해	화재, 침수, 정전, 지진

같은 서버 안에 이중화(RAID, 클러스터)가 있어도 삭제·손상·랜섬웨어는 그대로 복제됩니다. 이중화는 백업을 대체하지 못합니다.

2. 헷갈리는 개념 구분: 백업 vs 복제 vs 스냅샷 vs RAID

▶ 표 2. 비슷해 보이지만 다른 기술들

기술	목적	실수로 삭제한 데이터 복구	랜섬웨어 대응
RAID	디스크 고장 대비	불가	불가
복제 (Replication)	다른 곳에 실시간·주기적 사본 유지 (DR, 이중화)	삭제도 복제되므로 어려움	감염도 복제될 수 있음
스냅샷	특정 시점 상태 보존 (같은 스토리지 내)	가능 (보관 기간 내)	스토리지 자체가 공격당하면 위험
백업	별도 저장소에 시점별 사본 보관	가능	격리·불변 설정 시 가능

3. 핵심 지표: RPO와 RTO

백업 전략은 이 두 가지 질문에서 시작합니다.

▶ 그림 1. RPO와 RTO

  마지막 백업        장애 발생              서비스 복구
      │                 │                     │
──────●─────────────────✕─────────────────────●──────▶ 시간
      │◀───── RPO ─────▶│◀────── RTO ────────▶│
       (얼마나 데이터를      (얼마나 오래
        잃어도 되나?)        멈춰도 되나?)

▶ 표 3. RPO / RTO 정의

지표	질문	의미	예시
RPO (Recovery Point Objective)	데이터를 얼마 전 시점까지 복구해야 하나?	허용 가능한 데이터 손실 범위	RPO 24시간 → 하루 1회 백업이면 충족
RTO (Recovery Time Objective)	서비스를 얼마 안에 되살려야 하나?	허용 가능한 중단 시간	RTO 4시간 → 4시간 내 복구 가능해야 함

RPO와 RTO가 짧을수록 비용이 급격히 올라갑니다. 시스템 중요도별로 다르게 정해야 합니다. (모든 서버를 최고 등급으로 할 필요는 없어요)

4. 백업 방식: 전체 / 증분 / 차등

▶ 그림 2. 세 가지 백업 방식

        일    월    화    수    목
전체     ■     ■     ■     ■     ■    매번 전부 백업
증분     ■     ▪     ▪     ▪     ▪    직전 백업 이후 변경분만
차등     ■     ▪    ▪▪   ▪▪▪  ▪▪▪▪   전체 백업 이후 누적 변경분

■ = 전체 백업   ▪ = 변경된 데이터

▶ 표 4. 방식별 비교

방식	설명	백업 속도	저장 용량	복구
전체 백업	모든 데이터를 통째로	느림	큼	가장 간단·빠름
증분 백업	직전 백업 이후 변경분만	빠름	작음	전체 + 모든 증분 필요, 복잡
차등 백업	마지막 전체 백업 이후 변경분	중간	중간	전체 + 최신 차등 1개면 가능

실무 패턴 예시: 주 1회 전체 백업 + 매일 증분(또는 차등) 백업

5. 3-2-1 백업 원칙

가장 널리 알려진 백업 원칙입니다.

3 개의 사본을 만들고
2 가지 서로 다른 매체(저장소)에 보관하며
1 개는 물리적으로 떨어진 곳(오프사이트)에 둔다

▶ 그림 3. 3-2-1 구성 예시

① 운영 데이터 (원본)      ← 사본 1
      │
      ├──▶ ② 로컬 백업 (디스크/백업 장비)      ← 사본 2 (매체 A)
      │
      └──▶ ③ 원격 백업 (다른 사이트 / 클라우드)  ← 사본 3 (매체 B, 오프사이트)

▶ 표 5. 각 숫자가 막아주는 위험

숫자	막아주는 위험
3개 사본	하나가 손상되어도 다른 사본으로 복구
2개 매체	특정 저장 매체·기술의 결함이 동시에 영향을 주는 상황 방지
1개 오프사이트	화재·침수 등 사이트 전체 재해 대비

랜섬웨어 시대의 확장: 3-2-1-1-0

▶ 표 6. 3-2-1-1-0 원칙

숫자	의미
3-2-1	기본 원칙과 동일
+1	사본 하나는 오프라인(에어갭)이거나 변경·삭제가 불가능한(Immutable) 상태로 보관
0	백업 검증 결과 오류 0건 (복구 가능성을 확인)

랜섬웨어는 백업 서버와 백업 파일까지 노려서 암호화·삭제합니다. 그래서 공격자가 건드릴 수 없는 사본이 하나는 있어야 합니다.

6. 랜섬웨어 대응 백업 체크포인트

▶ 표 7. 백업 시스템 보호 방법

대응	설명
불변 스토리지 (Immutable)	보관 기간 동안 수정·삭제가 불가능하도록 설정 (WORM 방식 등)
오프라인·에어갭 사본	네트워크와 분리된 매체 (예: 분리 보관되는 테이프·외장 저장소)
백업 망 분리	운영망과 백업망을 분리, 백업 서버 접근 IP 제한
계정 분리	백업 관리자 계정을 운영 서버·AD 계정과 분리, MFA 적용
최소 권한	백업 저장소 삭제 권한을 최소한의 인원에게만
백업 암호화	저장·전송 시 암호화, 암호 키 별도 보관
이상 징후 알림	백업 용량 급감·대량 삭제·백업 실패 알림

7. 무엇을 백업할까? (대상 선정)

▶ 표 8. 서버 백업 대상 예시

대상	내용
데이터	DB, 파일 서버 데이터, 업로드 파일
설정	서버 설정 파일, 애플리케이션 설정, 인증서
시스템 이미지	OS 포함 서버 전체 이미지 또는 VM 백업
디렉터리·인증 정보	AD, LDAP 등 계정·권한 데이터
스크립트·코드	운영 스크립트, 배포 자동화, IaC 코드
문서	구성도, 절차서 (복구할 때 꼭 필요!)

복구 문서와 암호 키도 백업 대상입니다. 정작 복구할 때 절차서가 백업 서버 안에만 있으면 낭패입니다.

DB 백업은 "그냥 파일 복사"가 아닙니다

DB는 운영 중에 데이터가 계속 바뀌므로 파일을 그냥 복사하면 일관성이 깨진 백업이 될 수 있습니다. DB 전용 백업 도구나 일관성 있는 스냅샷 기능을 사용해야 합니다.

8. 보관 정책 (Retention)

▶ 표 9. 보관 정책 예시 (조직 정책에 맞게 조정)

주기	보관 예시
일간 백업	최근 7~14일 보관
주간 백업	최근 4~8주 보관
월간 백업	6~12개월 보관
연간 백업	법적·감사 요건에 따라 장기 보관

랜섬웨어 감염은 한참 뒤에 발견되기도 하므로, 너무 짧은 보관은 위험합니다. 감염 이전 시점의 사본이 남아 있어야 합니다.
법령·내부 규정의 보관 의무 기간을 반드시 확인하세요.
개인정보가 포함된 백업은 파기 기준도 함께 관리해야 합니다.

9. 복구 테스트: 백업의 진짜 완성

"테스트하지 않은 백업은 백업이 아니라 희망 사항이다."

백업 작업이 "성공"으로 표시되어도, 실제로 복구가 안 되는 경우가 있습니다.

▶ 표 10. 복구 실패의 흔한 원인

원인	설명
백업 파일 손상	저장 중 오류, 매체 결함
필요한 데이터 누락	백업 대상 지정 실수
암호·키 분실	암호화 백업의 키를 찾을 수 없음
절차 미숙	복구 순서, 의존 관계(예: AD 먼저)를 모름
호환성 문제	복구 환경과 버전 불일치
시간 초과	복구에 걸리는 시간이 RTO를 초과

복구 테스트 방법

▶ 그림 4. 복구 테스트 흐름

① 테스트 대상 선정 (중요 시스템 우선)
        ↓
② 격리된 테스트 환경에 복구 (운영 환경을 건드리지 않게!)
        ↓
③ 서비스 기동 및 데이터 정합성 확인
        ↓
④ 걸린 시간 측정 → RTO와 비교
        ↓
⑤ 문제점 기록, 절차서 보완
        ↓
⑥ 정기적으로 반복

▶ 표 11. 복구 테스트 수준

수준	내용	권장 주기(예시)
파일 단위 복구	임의 파일 1~2개를 골라 복구해 보기	월간
시스템 복구	VM·서버를 통째로 복구해 기동 확인	분기~반기
DR 훈련	장애 시나리오를 가정해 전체 절차 실행	연 1회 이상

10. 백업 운영 체크리스트

▶ 표 12. 체크리스트

점검 항목	확인
시스템별 RPO/RTO가 정의되어 있는가?	☐
3-2-1 원칙(사본 3, 매체 2, 오프사이트 1)을 만족하는가?	☐
변경·삭제 불가 또는 오프라인 사본이 있는가?	☐
백업 성공·실패를 매일 확인하고 알림을 받는가?	☐
백업 서버와 저장소가 운영망과 분리되어 있는가?	☐
백업 데이터가 암호화되어 있고, 키는 별도 보관되는가?	☐
정기적으로 복구 테스트를 수행하고 시간을 기록하는가?	☐
복구 절차서가 최신이고 백업 시스템 밖에도 있는가?	☐
보관 기간이 법규·내부 정책에 맞는가?	☐
백업 용량 증가 추세를 모니터링하는가?	☐

11. 정리

▶ 표 13. 핵심 키워드 요약

키워드	한 줄 요약
백업 ≠ RAID·복제	삭제·손상·랜섬웨어는 별도 백업만 막아줌
RPO / RTO	얼마나 잃어도 되나 / 얼마나 멈춰도 되나
전체·증분·차등	속도·용량·복구 편의성의 트레이드오프
3-2-1	사본 3개, 매체 2종, 오프사이트 1곳
3-2-1-1-0	+ 불변/오프라인 사본 1개, + 검증 오류 0건
복구 테스트	백업의 진짜 완성, 정기적으로 반복

"백업은 보험이고, 복구 테스트는 그 보험금이 실제로 나오는지 확인하는 일이다."

시리즈 마무리

이번 글로 서버 인프라 시리즈의 기본 흐름을 정리했습니다.

서버란 무엇인가 (구성, 종류, 이중화, 운영)
가상화: 하이퍼바이저와 VM의 원리
서버 모니터링
백업 전략

다음에는 네트워크 기본(스위치, 라우터, VLAN), Active Directory와 인증 인프라 같은 주제로 이어갈 수 있습니다.

읽어주셔서 감사합니다. 궁금한 점은 댓글로 남겨주세요! 🙌

김재현

문제를 해결하고, 더 나은 경험을 만드는 것을 즐깁니다

이전 포스트