백업과 복구 · 전략: 전체·증분·차등 · 이론

RPO, RTO, 그리고 3-2-1

한 줄 요약

백업 설계의 모든 선택은 RPO(얼마나 잃어도 되는가) 와 RTO(얼마나 빨리 돌아와야 하는가) 두 숫자에서 나온다.

왜 이게 필요했나

"백업 주기를 어떻게 잡을까요?" 라는 질문에는 답이 없다. "데이터를 몇 분까지 잃어도 되나요?" 로 바꾸면 답이 나온다.

RPO(Recovery Point Objective) — 장애 시점에서 얼마나 과거의 데이터까지 되살릴 수 있는가. 곧 허용 가능한 데이터 손실량이다. RPO 가 1시간이면 백업 주기도 1시간 이하여야 한다.
RTO(Recovery Time Objective) — 장애부터 서비스 재개까지 허용되는 시간. 이건 백업 방식뿐 아니라 복구 절차 전체가 결정한다.

두 숫자는 비용과 직결된다. RPO 를 분 단위로 줄이려면 지속적 아카이빙이 필요하고, RTO 를 분 단위로 줄이려면 대기 시스템이 필요하다. 그래서 이 숫자는 기술이 아니라 사업이 정한다. 엔지니어의 일은 그 숫자를 받아 실현 가능한 설계로 옮기는 것이다.

어떻게 동작하나

세 가지 방식

| 방식 | 무엇을 담나 | 백업 시간 | 복구 시간 | 저장 공간 |
| --- | --- | --- | --- | --- |
| 전체(Full) | 전부 | 김 | 짧음(하나만 풀면 됨) | 큼 |
| 증분(Incremental) | 마지막 백업 이후 변경분 | 짧음 | 김(전체 + 모든 증분 순서대로) | 작음 |
| 차등(Differential) | 마지막 전체 이후 변경분 | 중간 | 중간(전체 + 마지막 차등) | 중간 |

증분과 차등의 차이가 헷갈리기 쉬운데, 기준점이 다르다. 증분은 "직전 백업" 기준, 차등은 "마지막 전체" 기준이다. 그래서 차등은 날이 갈수록 커지지만 복구할 때 두 개만 있으면 된다.

실무에서 흔한 조합은 주 1회 전체 + 매일 증분 이다. 다만 이 조합의 위험은 증분 하나가 손상되면 그 이후 전부가 무효라는 점이다. 그래서 세대 보존 정책과 정기 검증이 짝으로 따라온다.

3-2-1 규칙과 현대적 보완

고전적인 규칙: 사본 3개, 서로 다른 매체 2종, 그중 1개는 오프사이트.

여기에 요즘은 두 가지가 더 붙는다.

1개는 오프라인이거나 변경 불가(immutable) — 랜섬웨어 대응. 백업 서버가 운영망에서 접근 가능하면 백업도 함께 암호화된다.
0 오류 — 정기적으로 복구를 검증해 오류가 0 임을 확인한다.

일관성 — 백업 도중 바뀌는 데이터

파일을 복사하는 동안 애플리케이션이 그 파일을 쓰고 있으면, 백업은 어느 시점의 상태도 아닌 잡탕이 된다. 데이터베이스에서 특히 치명적이다.

해법은 세 층위다.

1. 애플리케이션 수준 덤프 — pg_dump -Fc, mysqldump --single-transaction. 가장 확실하고 이식성이 좋다.
2. 파일시스템 스냅샷 — LVM/Btrfs/ZFS. 시점을 고정한 뒤 그것을 백업한다. 단 블록 수준 시점 고정일 뿐 애플리케이션이 메모리에 들고 있던 데이터는 반영되지 않는다. 그리고 스냅샷 볼륨이 가득 차면 스냅샷이 무효화되므로 크기를 넉넉히 잡아야 한다.
3. 지속적 아카이빙 — WAL/바이너리 로그를 계속 아카이브해 임의 시점 복구. RPO 를 분 단위로 줄여야 할 때.

현장에서 만나는 모습

백업이 조용히 망가지는 다섯 가지 방식을 기억해 두면 좋다.

1. 대상에서 빠져 있다 — 새 볼륨을 추가했는데 백업 스크립트에 넣지 않았다.
2. 성공 로그만 보고 실패를 못 본다 — cron 은 기본적으로 조용하다. 종료 코드를 확인하고 실패를 알리는 장치가 필요하다.
3. 랜섬웨어가 백업까지 복제된다 — 최신 백업만 유지하는 구성은 이 상황에서 무력하다.
4. 복원 대상 환경이 다르다 — UID/GID 매핑, SELinux 컨텍스트, 커널 버전이 다르면 복원은 되는데 서비스가 안 뜬다.
5. 백업이 운영 성능을 해쳐 백업 창이 줄어든다 — 그러다 주기를 늘리고 어느 순간 RPO 를 못 지킨다.

2번에 대한 최소 방어선은 이것이다.

#!/usr/bin/env bashset -euo pipefailtrap 'echo "backup FAILED at line $LINENO" >&2; exit 1' ERRrsync -aHAX --numeric-ids --delete /srv/data/ /backup/prod/data/echo "backup OK $(date -Is)"

그리고 성공 시각을 파일에 기록해 "최근 성공이 24시간 이내인가"를 감시하는 편이 로그를 읽는 것보다 훨씬 낫다.

다음 확인에서 볼 것

이어지는 퀴즈에서는 RPO·RTO, 전체·증분·차등, 오프사이트 사본을 어떤 조건에서
선택하는지 확인한다. 그 기준을 통과한 뒤 다음 모듈부터 tar 전체·증분 백업,
rsync 세대 보존, 검증 스크립트와 시간 측정 복구 리허설로 이어진다.