RPO·RTO

백업·복구 전략을 정하는 두 개의 숫자. 기술 선택이 아니라 업무 요구에서 먼저 정해진다.

두 숫자의 뜻

• RPO (Recovery Point Objective) — 허용 가능한 데이터 손실량

  • "최대 5분치까지는 잃어도 된다"
  • 백업·WAL 아카이브 주기가 이 값을 결정한다

• RTO (Recovery Time Objective) — 허용 가능한 복구 시간

  • "30분 안에 다시 서비스해야 한다"
  • 백업 방식·자동화 수준이 이 값을 결정한다

값에 따라 설계가 달라진다

-- RPO 0 을 원하면 커밋이 복제본 확인까지 기다리게 한다 (그만큼 느려진다)
ALTER SYSTEM SET synchronous_standby_names = 'standby1';
ALTER SYSTEM SET synchronous_commit = 'remote_apply';

가장 흔한 오해 — 복제는 백업이 아니다

• 복제(replication) — 고가용성 — 한 대가 죽어도 다른 대가 서비스한다

• 백업(backup) — 과거 복원 — 실수·손상에 대비한다

• 목적이 다르다

결정적인 차이는 이것이다.

DELETE FROM users;    -- WHERE 를 빠뜨렸다
-- → 이 DELETE 는 모든 복제본에 즉시 전파된다
-- → 복제본 10대가 있어도 10대 모두에서 데이터가 사라진다

복제는 사람의 실수를 막아 주지 못한다. 둘 다 필요하다.

가장 중요한 한 가지

• 복원을 정기적으로 실제로 테스트한다

• 백업 파일이 깨져 있어도 뜨는 동안에는 알 수 없다

• 복원 절차를 아무도 해 본 적 없으면 RTO 는 추정치일 뿐이다

• 실제로 재 보면 대개 예상보다 오래 걸린다

복원해 본 적 없는 백업은 백업이 아니다. 분기마다 스테이징에 실제로 복원해 보고 걸린 시간을 기록하는 것이 표준 관행이다.

면접 함정

• ❌ "백업 주기를 짧게 하면 RTO가 준다" → RPO가 준다. RTO는 복원에 걸리는 시간이라 백업 방식과 자동화가 좌우한다.
• ❌ "RPO 0이 항상 좋다" → 동기 복제는 쓰기 지연을 늘린다. 업무가 요구하는 만큼만 잡는다.

실제 값을 재 본다

# 복원 리허설 — 시간을 기록한다
time pg_restore -d recovered -j 4 /backup/dump.custom
# 여기서 나온 숫자가 진짜 RTO 다. 문서에 적힌 값이 아니다

-- RPO 를 실시간으로 감시한다 — 아카이브가 얼마나 밀렸나
SELECT now() - pg_last_xact_replay_timestamp() AS replica_lag;
SELECT last_archived_time, last_failed_time FROM pg_stat_archiver;

계층을 나눠 잡는다

• 모든 데이터에 같은 RPO/RTO 를 적용할 필요가 없다

• 결제·주문 — RPO 0 · RTO 5분 → 동기 복제 + 대기 노드 상시 대기

• 회원 정보 — RPO 5분 · RTO 1시간 → PITR

• 로그·통계 — RPO 24시간 · RTO 1일 → 일 1회 백업

• 등급을 나누면 비용이 크게 준다