백업은 단순히 파일을 복사해두는 작업이 아니라, 목표 복구시점(RPO)과 목표 복구시간(RTO)을 충족하도록 설계된 재해복구 전략의 핵심 구성요소다. 서비스 특성과 데이터 가치에 따라 어떤 데이터를 언제, 어디에, 어떻게, 얼마나 오래 보관할지 명확히 정해야 한다. 아래 가이드는 실무에서 바로 적용할 수 있는 백업 원칙, 유형, 저장 위치 전략, 자동화·보안·검증 방법까지 체계적으로 정리한다.
핵심 원칙: RPO/RTO와 3-2-1-1-0
RPO는 복구 시점 기준으로 허용 가능한 데이터 손실량, RTO는 서비스가 다시 가동되기까지 허용 가능한 시간이다. 이 두 지표를 먼저 정의하면 백업 주기, 매체, 아키텍처가 자연스럽게 결정된다. 권장되는 보편 원칙은 3-2-1-1-0 규칙이다. 서로 다른 3개의 사본을, 2종 이상의 매체에 저장하고, 1개는 오프사이트(다른 위치)에, 1개는 오프라인·불변(Immutable)으로 유지하며, 0은 정기 검증으로 오류가 0이어야 함을 뜻한다. 이 원칙을 만족하면 랜섬웨어·시설재해·사고 삭제에 모두 강하다.
백업 유형: 전체/증분/차등과 스냅샷/이미지/파일
전체(Full) 백업은 기준점을 만들고, 증분(Incremental)은 마지막 백업 이후 변경분만, 차등(Differential)은 마지막 전체 백업 이후 변경분을 보관한다. 변화량이 많은 서비스는 증분으로 저장 효율을 높이고 주 1회 전체 백업으로 복구 체인을 짧게 유지한다. 데이터 표현 방식도 중요하다. 파일 레벨 백업은 개별 복원에 유리하고, 이미지 백업은 시스템 단위 신속 복구(P2V/V2V)에 적합하며, 스냅샷은 LVM/ZFS/클라우드 블록 스토리지(EBS 등)의 시점 복제 기능으로 매우 빠르다. 스냅샷은 동일 스토리지 장애에 취약하므로 반드시 다른 계정·리전·미디어로 2차 복제를 둔다.
저장 위치 전략: 온프레미스·오프사이트·클라우드·오프라인
온프레미스 NAS/테이프는 대역폭 부담이 적고 대용량 장기보관에 유리하다. 오프사이트는 화재·침수 등 지역 재해 리스크를 분산한다. 클라우드는 내구성(예: 11 9’s)을 바탕으로 오브젝트 스토리지와 수명주기(핫→아카이브) 전환으로 비용을 최적화할 수 있다. 오프라인(테이프·WORM·S3 Object Lock/Immutable 스토리지)은 랜섬웨어 대비 최후의 보루다. 생산망과 백업망은 라우팅·계정·자격증명을 분리하고, 백업 저장소는 쓰기-일시잠금 정책을 병행한다.
설계 체크리스트
백업 범위(시스템 이미지, 애플리케이션 구성, 데이터, 로그), 보존정책(GFS: 일간·주간·월간), 암호화(AES-256, 전송 중 TLS), 키 관리(KMS·HSM), 압축·중복제거, 스로틀링(업무시간 대역폭 보호), 태그·카탈로그 관리, 접근통제(RBAC), 감사로그, 알림·리포트까지 정의한다. 장애 시 실행할 런북(runbook)과 연락망, 의사결정 권한도 문서화한다.
워크로드별 실전 예시
리눅스 파일 서버
변경량이 많은 디렉터리는 rsync로 증분 복제, 주간 전체 백업은 borg/restic과 같은 중복제거 백업툴로 원격 보관한다.
# 변경분 동기화(권한/소유/하드링크 보존, 삭제 동기화)rsync -aHAX –delete /data/ backup@nas:/backup/data/# borg로 암호화+중복제거 백업borg init –encryption=repokey-blake2 backup@repo:/srv/borg/databorg create –stats –compression zstd,6 backup@repo:/srv/borg/data::”{now:%Y-%m-%d}” /databorg prune -v –keep-daily=7 –keep-weekly=4 –keep-monthly=12 backup@repo:/srv/borg/data
윈도우 서버
시스템 상태와 볼륨 이미지를 함께 백업해 OS 장애 시 신속 복구한다.
# Windows Server Backupwbadmin start backup -backupTarget:E: -include:C:,D: -allCritical -quiet
데이터베이스(MySQL/PostgreSQL)
일관성 보장을 위해 논리 백업과 스냅샷을 병행한다. 트랜잭션 로그(바이너리 로그/WAL) 보관으로 시점 복구를 지원한다.
# MySQL 논리 백업mysqldump –single-transaction –routines –triggers –master-data=2 \
-u backup -p DBNAME | gzip > /backup/mysql/DBNAME_$(date +%F).sql.gz
# PostgreSQL 전체 백업 및 WAL 아카이브
pg_dump -Fc DBNAME > /backup/pg/DBNAME_$(date +%F).dump
클라우드 RDS 계열은 자동 스냅샷 보존 정책과 크로스 리전 복제를 활성화한다.
가상머신/컨테이너
하이퍼바이저(ESXi/Hyper-V) API 기반 스냅샷과 이미지 백업을 사용하고, 컨테이너는 상태 저장 볼륨을 스냅샷·파일 백업한다. 쿠버네티스는 Velero로 오브젝트와 볼륨을 동시에 백업한다.
자동화와 스케줄링
운영시간을 피해 야간 백업을 실행하고, 네트워크·스토리지 부하에 따라 스로틀링을 적용한다. 리눅스는 cron/systemd timer, 윈도우는 작업 스케줄러를 활용한다.
# 매일 02:00 rsync, 03:00 borg 백업
0 2 ***rsync -aHAX –delete /data/ backup@nas:/backup/data/ >> /var/log/rsync.log 2>&1
0 3 ***borg create –stats backup@repo:/srv/borg/data::”$(date +%F)” /data \
&& borg prune -v –keep-daily=7 –keep-weekly=4 –keep-monthly=12 backup@repo:/srv/borg/data
조기 실패 감지를 위해 작업 종료 코드와 로그를 수집하고, 실패 시 슬랙/이메일로 알림을 발송한다.
보안: 암호화·키·격리
전송 중에는 TLS/SSH, 저장 시에는 AES-256으로 암호화한다. 암호화 키는 백업 데이터와 분리해 보관하며, KMS/HSM에 저장하고 주기적으로 로테이션한다. 백업 계정은 읽기 전용 최소권한으로 분리하고, 생산망 자격증명이 백업 저장소에 접근하지 못하도록 정책을 강제한다. 랜섬웨어 대응을 위해 불변 스토리지(Object Lock, WORM) 또는 오프라인 매체를 필수로 포함한다.
무결성 검증과 복구 리허설
백업은 복구가 되어야 의미가 있다. 해시 검증(SHA-256)과 백업 소프트웨어의 verify 기능으로 카탈로그-데이터 일치 여부를 확인한다. 월 1회 샘플 파일 복원, 분기 1회 시스템 단위 복구 리허설을 별도 격리 네트워크에서 수행한다. RTO 목표 내 복구가 이뤄지는지 타이머로 측정하고, 결과를 기록해 설정을 보정한다.
# restic 예: 백업 무결성 체크와 샘플 복원
restic checkrestic
restore latest –target /restore-test –include “/data/critical/*”
보존 정책과 비용 최적화
GFS 전략으로 일간 7, 주간 4, 월간 12 보관을 기본값으로 두고, 규제 산업은 연간 스냅샷 보관 기간을 정책에 맞춘다. 오브젝트 스토리지는 수명주기 정책으로 핫→인프리퀀트→아카이브 전환을 자동화한다. 중복제거·압축을 통해 저장량을 줄이고, 변경율이 낮은 워크로드는 증분 영구 체인+주기적 합성 전체 백업으로 I/O와 비용을 절감한다.
운영 지표와 관측
백업 성공률, 복구 성공률, 평균 RTO/RPO 준수율, 저장소 사용량, 중복제거 비율, 전송 속도, 실패 사유 톱5를 대시보드로 상시 관찰한다. 경향 분석을 통해 저장소 증설 시점을 예측하고, 대역폭 병목 구간을 찾아 스케줄과 압축률을 조정한다. 감사 요구에 대비해 백업·복구 활동 로그를 중앙 수집한다.
체크리스트 요약
- RPO/RTO 정의 2) 3-2-1-1-0 충족 3) 전체·증분·차등 혼합 4) 온프레미스·오프사이트·오프라인 병행 5) 암호화·키 분리 6) 자동화·알림 7) 불변 스토리지 적용 8) 정기 무결성 검사 9) 복구 리허설 10) 보존·비용 정책 수립. 이 순서대로 구축하면 데이터 손실 위험을 최소화하면서 현실적인 비용으로 견고한 백업 체계를 운영할 수 있다.