백업과 복구 계획 파일 보호하기

백업과 복구 계획은 두 가지 수치로 시작합니다. RPO(복구 시점 목표, 데이터 손실 허용 시간)와 RTO(복구 시간 목표, 서비스 중단 허용 시간)입니다. 각 워크로드별로 이 수치를 정의한 후 역방향으로 설계합니다. RPO 5분인 데이터베이스는 지속적인 WAL 전송이 필요하고, RPO 24시간인 주간 마케팅 보고서는 야간 배치 작업 하나로 충분합니다. 3-2-1 규칙(세 개의 복사본, 두 가지 미디어, 하나는 오프사이트)과 분기별 복원 테스트를 병행하세요. "백업이 있다"고 말하는 많은 사례가 실패로 끝나는 이유는 실제로 복원을 연습한 적이 없기 때문입니다.

RPO와 RTO: 시작 수치

RPO(Recovery Point Objective) = 시간 단위로 측정한 최대 허용 데이터 손실량. RTO(Recovery Time Objective) = 최대 허용 서비스 중단 시간.

워크로드별 예시:

이커머스 사이트의 운영 데이터베이스: RPO 5분, RTO 1시간
고객용 파일 업로드: RPO 15분, RTO 2시간
내부 파일 서버: RPO 24시간, RTO 8시간
이메일 아카이브: RPO 24시간, RTO 48시간
마케팅 분석: RPO 24시간, RTO 72시간

RPO/RTO를 빡빡하게 설정할수록 비용이 높아집니다. RPO 5분은 지속적인 복제(고비용 인프라)를 의미하고, RPO 24시간은 야간 배치 작업 하나(저비용)로 처리됩니다. 과도하게 설계하지 마세요. 모든 워크로드에 핫 스탠바이가 필요한 것은 아닙니다.

3-2-1 규칙은 여전히 유효합니다

세 개의 데이터 복사본, 두 가지 스토리지 유형, 하나는 오프사이트. 3-2-1 규칙은 클라우드 이전부터 존재했고 지금도 통합니다:

1차: 운영 스토리지 (S3, EBS, PostgreSQL 디스크)
2차: 다른 미디어 또는 다른 리전의 백업 (복제가 적용된 별도의 S3 버킷, Glacier)
3차: 오프사이트, 가급적 다른 벤더 또는 에어갭 (Backblaze B2, 온프레미스 테이프, 금고에 보관된 물리적 디스크)

벤더 다양성이 중요합니다. 침해된 AWS 루트 계정은 모든 AWS 백업을 삭제할 수 있습니다. Backblaze, Wasabi, 또는 온프레미스에 보관된 2차 사본은 이 시나리오에서 살아남습니다. 연 매출 500억 원 미만 기업의 경우, 두 번째 벤더 사본을 추가하는 비용은 월 5만~25만 원 수준이지만 대규모 장애 위험에 대한 보험 역할을 합니다.

전체, 증분, 합성 전체 백업

세 가지 백업 전략:

전체(Full): 매번 모든 것을 복사. 단순하고 복원이 빠름(파일 하나), 스토리지 부담이 큼.
증분(Incremental): 마지막 백업 이후 변경된 것만 복사. 스토리지 효율적, 복원 시 전체 + 모든 증분 필요.
합성 전체(Synthetic Full): 서버 측에서 전체 + 증분을 새로운 가상 전체로 병합. 임의 시점에서 빠른 복원 가능.

Veeam, Rubrik, restic with prune, BorgBackup 같은 최신 백업 도구는 내부적으로 합성 전체를 활용한 영구 증분 방식을 사용합니다. 패턴: 매일 밤 증분 백업, 주 1회 합성 전체, 일별 30개 + 월별 12개 + 연별 7개 보관(할아버지-아버지-아들 로테이션).

일 변경률 5%인 2TB 파일 서버의 경우, 영구 증분 방식으로 1년 보존 시 약 3~5TB가 필요합니다. 매일 전체 백업을 하면 700TB 이상이 필요합니다.

전송 전 암호화

백업은 암호화 없이 이동하거나 보관되어서는 안 됩니다. AES-256-GCM 클라이언트 측 암호화(restic, Borg, Duplicacy, Veeam 등의 기본값)는 백업 호스트가 평문을 볼 수 없도록 보장합니다.

알고리즘 선택보다 키 관리가 더 중요합니다. 백업과 동일한 AWS 계정에 저장된 키로 암호화된 백업은 사실상 무의미합니다. IAM 접근권을 가진 공격자가 둘 다 얻을 수 있습니다. 키는 다음에 보관하세요:

별도 계정의 AWS KMS (크로스 계정 복호화)
대역 외 환경의 HashiCorp Vault
루트 키용 하드웨어 보안 모듈 (YubiKey, HSM)
매우 중요한 키에 대한 인쇄 봉인 종이 사본

정기적으로 교체(연간)하고, 모든 사용을 기록하며, 프로덕션에서 교체가 적용되기 전에 교체된 키로 복구를 테스트하세요.

불변성: 랜섬웨어 대응책

2025년 랜섬웨어 공격은 흔히 백업을 먼저 노립니다. 운영 데이터를 암호화한 후 복구를 막기 위해 백업을 삭제하거나 암호화합니다. 불변 백업이 이를 무력화합니다.

구현 방법:

S3 Object Lock (Compliance 모드): 보존 기간 동안 루트도 삭제 불가
Azure Blob 불변 스토리지: 유사 기능, 컨테이너 단위 적용
Veeam Hardened Linux Repository: 추가 전용, SSH 전용, 삭제 API 없음
금고 내 물리적 테이프: 궁극의 에어갭

비즈니스 핵심 데이터는 보존 기간 동안 최소 하나의 백업 사본이 불변 상태여야 합니다. 추가 비용은 보통 없습니다. 어차피 보관할 예정이었으니까요. 랜섬웨어가 실제로 발생했을 때 그 가치는 분명해집니다.

테스트: 선택이 아닌 필수

한 번도 복원하지 않은 백업은 백업이 아닌 희망입니다. 우선순위별 테스트 일정:

1등급 (미션 크리티컬): 분기별 전체 복원 훈련, 월별 임의 파일 복원
2등급 (비즈니스 중요): 반기별 전체 복원 훈련, 분기별 임의 파일 복원
3등급 (표준): 연간 전체 복원 훈련, 분기별 임의 파일 복원

테스트 시 기록할 항목:

복원에 걸린 시간 (RTO와 비교)
데이터가 운영 상태와 일치하는지 (알려진 시점의 체크섬 비교)
권한이나 설정 복원 실패 여부
무엇이 문제였고 어떻게 해결했는지

테스트를 건너뛰는 기업은 실제 장애 중에 손상된 백업을 발견합니다. 이것이 가장 비싼 방식으로 배우는 순간입니다.

데이터베이스 백업은 별도 계획이 필요합니다

파일과 데이터베이스는 다르게 백업됩니다. 트랜잭션 중에 복사된 .pgdata 디렉토리는 손상됩니다. 네이티브 도구를 사용하세요:

PostgreSQL: PITR을 위한 pg_basebackup + WAL 아카이빙, 논리 백업용 pg_dump
MySQL: 핫 물리 백업용 Percona XtraBackup, 논리 백업용 mysqldump
MongoDB: mongodump, 지연 세컨더리를 포함한 복제 셋
Microsoft SQL Server: BACKUP DATABASE를 활용한 네이티브 백업, PITR을 위한 로그 전달

RPO 5분인 500GB PostgreSQL 데이터베이스의 경우, 야간 베이스 백업 + S3로의 지속적 WAL 아카이빙으로 최근 30일의 임의 시점 복구가 가능합니다. 복원 시간: 베이스 백업 가져오기(30분) + 대상 시점까지 WAL 재실행(5~30분). RTO를 줄이려면 즉시 승격 가능한 웜 레플리카가 필요합니다.

애플리케이션 일관성 스냅샷

파일시스템 스냅샷(ZFS, Btrfs, AWS EBS, Azure 관리 디스크, GCP 영구 디스크)은 블록 레벨에서 특정 시점을 고정합니다. 데이터베이스의 경우 애플리케이션 정지와 함께 사용합니다:

pg_start_backup('label') (PostgreSQL) 또는 FLUSH TABLES WITH READ LOCK (MySQL)
스냅샷 생성
pg_stop_backup() 또는 잠금 해제

이 스냅샷은 애플리케이션 일관성을 보장하여 크래시 복구 없이 복원 가능합니다. AWS Backup, Azure Backup, Google Cloud Backup은 주요 데이터베이스에서 이 패턴을 자동화합니다.

제3자에게 백업 아카이브 전송

백업을 외부 당사자(감사인, 규제 기관, 후임 수탁자)에게 전달해야 할 경우, 이전 작업 자체에도 주의가 필요합니다. FTP는 구식이고, 이메일 첨부파일은 용량 제한이 있으며, USB 드라이브 전달은 느립니다.

개인정보보호법(PIPA) 준수 요건을 고려할 때, 종단간 암호화 파일 전송이 임시 백업 배포를 깔끔하게 처리합니다. HexaTransfer는 AES-256-GCM 클라이언트 측 암호화와 일회용 링크로 최대 10GB 파일을 이동할 수 있습니다. S3 버킷 접근 권한을 부여하지 않고도 감사인에게 데이터베이스 스냅샷을 전송할 때 유용합니다.

문서화도 백업의 일부입니다

세상에서 가장 좋은 백업도 복원할 수 있는 사람이 휴가 중이고 다른 사람이 방법을 모르면 쓸모없습니다. 문서화할 내용:

백업 대상과 제외 항목 (명시적 제외 목록)
워크로드별 일정과 보존 기간
키 관리와 접근 방법
단계별 명령어가 포함된 복원 런북
연락처 목록 (벤더 지원, 온콜 담당)
테스트 결과와 날짜

인쇄본을 만들고 비상 열쇠와 함께 물리적 금고에 보관하세요. 백업 런북이 방금 다운된 인프라에서 제공되는 Confluence 페이지에만 있다면 심각한 문제입니다. 아무것도 작동하지 않을 때 종이는 여전히 작동합니다.

RPO/RTO를 정의하고, 불변성이 포함된 3-2-1을 구현하고, 클라이언트 측에서 암호화하고, 분기별로 테스트하고, 철저하게 문서화하세요. 백업 성공은 기술 10%, 규율 90%입니다.

hexatransfer.com에서 무료로 시작해 보세요 — 계정 불필요, 최대 10GB.