17.5 클라우드 백업·HA 패턴

매니지드 클라우드 PostgreSQL의 백업·HA는 자체 운영 (Part XI·XII)과 다른 패턴이 있습니다. 클라우드가 제공하는 것 vs 추가로 해야 하는 것을 정리합니다.

매니지드 백업 — 공통점

이 정도면 대부분 RPO·RTO 요구 만족.

매니지드 HA — 공통

    flowchart TD
  P["primary"]
  S["standby (동기 또는 비동기)"]
  AZ1["AZ-1"]
  AZ2["AZ-2"]
  P --- AZ1
  S --- AZ2
  P -.-> S

  classDef pri fill:#ede9fe,stroke:#6d28d9,color:#3b0764
  classDef std fill:#d1fae5,stroke:#047857,color:#064e3b
  class P pri
  class S std
  

• Multi-AZ (AWS RDS·Aurora), Zone-redundant HA (Azure), Regional (Cloud SQL)
• 자동 failover 12분
• 한 region 안 — region 자체 장애엔 cross-region replica 필요

자체 운영과의 차이

매니지드도 3-2-1 룰(11.1) 보장 안 됩니다. 클라우드 콘솔 안에만 있으면:

• 계정 해킹·실수로 instance 삭제 → 백업도 같이
• region 자체 장애 → 같은 region 백업 손실

대응:

• 별도 region/계정으로 백업 복사
• 외부 객체 저장소(다른 클라우드 또는 on-prem)에 logical dump
• snapshot 보존 정책에 수동 백업 정기 추가

cross-region DR 패턴

AWS

us-east-1 primary
├── us-east-1 Multi-AZ (HA)
├── us-west-2 cross-region snapshot 복사 (백업)
└── us-west-2 read replica (또는 Aurora global database)

cross-region snapshot은 별도 비용 + 데이터 전송. 비교적 저렴하지만 region 장애 시 분 단위 RPO.

read replica·Aurora global database는 초 단위 RPO.

Azure

West US (primary)
├── Zone-redundant HA
├── Geo-redundant backup (다른 region)
└── Read replica in East Asia

Geo-redundant backup은 자동입니다. read replica는 별도 비용입니다.

GCP

asia-northeast3 primary
├── Regional HA (3 zone)
├── Cross-region replica (또는 backup 복사)

외부 logical dump

매니지드 자체 백업과 별도로 정기 pg_dump:

#!/bin/bash
# 매일 새벽 — RDS/Cloud SQL에서 외부 저장소로
pg_dump -Fd -j 4 -h myrds.amazonaws.com -U admin app_main -f /tmp/app_main
aws s3 sync /tmp/app_main s3://different-account-backup/$(date +%F)/

다른 계정·다른 클라우드에 둠 = 최후의 안전망.

logical replication 기반 분석

primary (Cloud SQL) → logical replication → 자체 운영 standby (분석용)

매니지드의 제약(pg_repack 미지원·일부 확장 등)에서 자유로운 분석 환경 별도 운영.

RPO·RTO 정리

백업 검증 — 매니지드도 필수

11.7의 정기 시뮬레이션을 매니지드에서도:

# AWS — staging clone으로 PITR
aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod \
  --target-db-instance-identifier prod-staging \
  --restore-time '2026-05-23T09:50:00Z'

# Azure
az postgres flexible-server restore \
  --resource-group rg \
  --name myserver-staging \
  --source-server myserver \
  --restore-time '2026-05-23T09:50:00Z'

# GCP
gcloud sql instances clone myinstance myinstance-staging \
  --point-in-time='2026-05-23T09:50:00Z'

분기마다 staging clone에 검증 쿼리 실행 — 자동화합니다.

HA 토글의 함정

RDS Multi-AZ enable
Azure Zone-redundant HA enable
Cloud SQL Regional

콘솔 토글로 활성화하지만 뒤에 standby instance가 실제로 동작하는지 정기 점검합니다. 매니지드도 자동 failover 시뮬레이션을 분기 실행해 실제 작동 검증합니다.

# AWS — 강제 failover
aws rds reboot-db-instance \
  --db-instance-identifier mydb \
  --force-failover

failover 후 DNS·application 연결 정상 확인합니다.

매니지드의 HA 한계

운영 권장 — 매니지드 추가 작업

1. 자동 백업 활성화 + 보존 35일
2. 수동 snapshot 월 1회(중요 시점 영구 보존)
3. cross-region 백업 복사(DR)
4. 외부 계정·외부 클라우드에 logical dump(3-2-1)
5. 분기 PITR 시뮬레이션 — 자동화
6. HA 사용 + 분기 강제 failover 테스트
7. application의 connection retry·timeout 설정

정리

• 매니지드 백업은 편하지만 3-2-1 룰 자동 보장 X
• HA·PITR·snapshot은 콘솔 토글로 활성
• cross-region DR은 별도 비용 + 설정
• 외부 계정·외부 클라우드에 logical dump가 마지막 안전망
• HA·복원은 분기 시뮬레이션으로 실제 동작 검증

다음 절(17.6)에서는 클라우드 비용을 줄이는 최적화 패턴을 봅니다.