결정: 어떤 백업 전략인가?

백업 전략은 세 가지 요소의 균형으로 선택한다: 허용 가능한 데이터 손실(RPO), 데이터 크기, 복구 속도(RTO). 모든 시나리오에 맞는 단일 방법은 없다. 이 트리는 RPO 목표에서 출발해 논리 덤프, 물리 백업 + PITR, 스냅샷 중 선택을 안내하며, 3-2-1과 검증은 타협할 수 없음을 상기시킨다.

데이터 손실 목표(RPO)는 무엇인가?

가장 결정적인 제약 조건부터 시작한다: 재해 시 몇 분/몇 시간 분량의 데이터 손실을 감수할 수 있는가? 거의 제로에 가까운 데이터 손실이 요구되면 연속 로그 아카이빙(PITR)이 필수이고, 일일/주간 백업 수준이 허용되면 더 단순한 방법으로 충분하다. RPO가 전략의 틀을 정한다.

• 거의 제로 — 임의 시점으로 복구할 수 있어야 함
• 일일/주기적 백업(몇 시간의 손실) 허용
• 먼저 일반적인 모범 사례(3-2-1 / 검증)를 알려 달라

데이터 크기와 이식성 요구 사항은 무엇인가?

주기적 백업으로 충분하다면 다음 질문은 규모와 목적이다: 데이터베이스가 소/중규모이고 백업을 다른 환경/버전으로 이식하고 싶은가, 아니면 데이터가 크고 몇 분 내 복구가 주된 관심사인가? 이에 따라 논리 덤프와 스냅샷 중 선택이 결정된다.

• 소/중규모, 이식 가능하고 버전 간 호환
• 대용량 데이터, 복구가 매우 빨라야 함(낮은 RTO)

권장: 논리 덤프

데이터를 논리 수준(스키마 정의 + 행)으로 내보낸다. 출력은 SQL/텍스트(pg_dump plain 형식, mysqldump) 또는 도구별 바이너리 덤프(pg_dump -Fc, Oracle Data Pump)다. 소/중규모 데이터베이스, 마이그레이션, 버전 업그레이드, 선택한 테이블/객체의 복구에 유연하고 이식성 있는 방법이다.

권장: 물리 백업 + WAL/아카이브 로그(PITR)

정기적으로 물리 base backup을 수행하고 트랜잭션 로그(WAL/redo/binlog)를 연속 아카이빙한다. 이를 통해 임의 시점으로 Point-in-Time Recovery를 수행하고 데이터 손실을 거의 제로로 줄일 수 있다.

권장: 스냅샷

스토리지 또는 가상화 계층에서 데이터의 블록 수준 스냅샷을 생성한다. 매우 큰 데이터베이스에서도 백업과 복구가 매우 빠르지만, 인프라에 의존하며 신중한 사용이 필요하다.

권장: 3-2-1 규칙 + 오프사이트 + 필수 검증

어떤 방법을 선택하든 이 원칙은 전략의 상위에 있어야 한다. 백업이 존재하는 것만으로는 부족하며, 다른 매체와 다른 위치에 있고 정기적으로 테스트되어야 한다. 위의 모든 옵션을 보완하는 프레임워크다.