DB 백업·복원 Runbook

운영자 전용 페이지

RP 통합 개발자가 신경 쓸 항목이 아닙니다. logi 자체 운영 — DR (Disaster Recovery), 정기 복원 드릴, 마이그레이션 사고 복구 절차입니다.

1. 자동 스냅샷 (Render PG)

Render Postgres 가 매일 1회 자동 스냅샷을 보관합니다. 보존 기간은 인스턴스 플랜에 종속:

Plan	보존
basic_256mb (현재 logi-db, PostgreSQL 18)	7일
standard	30일
pro	30일 + point-in-time recovery

확인: Render dashboard → logi-db → Backups 탭. 가장 최근 스냅샷의 시각 + 다음 스냅샷 ETA 표시.

클라이언트 도구 버전 일치

pg_dump / pg_restore / psql 은 서버와 같거나 더 높은 major version 을 사용하세요. 현재 logi-db 는 PG 18 (verified via Render API 2026-05-15) — PG 16 클라이언트로 dump 시 새 시스템 카탈로그/확장이 silently mishandle 될 수 있습니다. macOS:

brew install postgresql@18
export PATH="/opt/homebrew/opt/postgresql@18/bin:$PATH"
pg_dump --version  # → pg_dump (PostgreSQL) 18.x

Render Postgres major-version 업그레이드는 pg_upgrade 를 통한 명시적 마이그레이션이 필요합니다 — Render docs 참조.

보존 기간 초과 백업

7일 이상 보관하려면 수동 pg_dump 를 S3 또는 다른 스토리지에 주기 push. 현재는 자동화 없음 — TODO 항목.

2. 수동 pg_dump (ad-hoc)

마이그레이션 직전, 또는 위험한 데이터 변경 직전에 수동 스냅샷 권장.

# 외부 접속 URL 은참조.
# 또는 Render dashboard → Connect → External Connection.

export LOGI_PG_URL='postgresql://USER:PASS@<LOGI_PG_INSTANCE_ID>.singapore-postgres.render.com/logi_db_783n'

# 전체 덤프 (custom format — 압축 + 선택적 복원 가능)
pg_dump --format=custom --no-owner --no-acl \
        --file=logi_backup_$(date +%Y%m%d_%H%M%S).dump \
        "$LOGI_PG_URL"

# 또는 plain SQL (인스펙션 용이)
pg_dump --format=plain --no-owner --no-acl \
        --file=logi_backup_$(date +%Y%m%d_%H%M%S).sql \
        "$LOGI_PG_URL"

압축률: custom format 이 plain 대비 ~10x 작음. 장기 보관은 custom 권장.

3. 부분 백업 (특정 테이블만)

대규모 데이터 마이그레이션 검증 시 유용:

pg_dump --format=custom --no-owner --no-acl \
        --table=logi_identity_links \
        --table=logi_webhook_deliveries \
        --table=logi_event_dlqs \
        --file=logi_partial_$(date +%Y%m%d).dump \
        "$LOGI_PG_URL"

4. 자동 스냅샷 복원 (사고 발생 시)

가장 일반적 시나리오 — 마이그가 destructive 였거나 잘못된 코드 deploy 로 데이터 손상.

4.1 Dashboard 경로 (권장)

1. Render dashboard → logi-db → Backups → 복원할 스냅샷 선택
2. "Restore to new database" 클릭 (기존 DB 덮어쓰기 X, 새 인스턴스 생성)
3. 새 DB ID 받음 (예: dpg-xxxx-a)
4. 새 DB 의 External URL 로 데이터 검증:

   psql "$NEW_DB_URL" -c "SELECT COUNT(*) FROM users;"

5. 검증 완료 후 logi-server 의 DATABASE_URL env 를 새 DB URL 로 교체 (Render dashboard → env vars, 개별 PUT)
6. logi-server 자동 redeploy 트리거됨
7. /up HTTP 200 확인 후 옛 DB suspend (수일 지난 후 삭제)

4.2 직접 덮어쓰기 (긴급, 위험)

기존 logi-db 인스턴스에 백업을 그대로 부어넣는 방식. 데이터 손실 위험 — 백업 시점 이후 모든 변경 사라짐. 최후의 수단.

# 1. logi-server 일시 정지 (Render dashboard → Suspend)
# 2. 모든 테이블 drop + 백업 복원
psql "$LOGI_PG_URL" -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
pg_restore --no-owner --no-acl --dbname="$LOGI_PG_URL" logi_backup_YYYYMMDD.dump
# 3. logi-server resume → 자동 redeploy

절대 금지

정기 backup-restore 가 아닌 incident 대응에서 위 절차를 쓸 때는 반드시 사용자 알림: "DB 가 N 시간 전 상태로 되돌아갑니다. 그 사이 가입/머지 데이터 손실 가능." Status page 또는 RP 사후 통보.

5. 정기 복원 드릴 (월 1회 권장)

DR 가 실제로 동작하는지 평소에 검증해야 합니다. 운영 중 인스턴스를 건드리지 않고 별도 검증:

# 1. 최신 스냅샷을 새 DB 로 복원 (Render dashboard, 위 4.1)
# 2. 새 DB 에 logi-server 코드 연결 (로컬 또는 staging Render)
RAILS_ENV=production DATABASE_URL="$RESTORED_DB_URL" \
  bundle exec rails runner '
    puts "users: #{User.count}"
    puts "links: #{LogiIdentityLink.count}"
    puts "last_signup: #{User.order(created_at: :desc).first&.created_at}"
  '
# 3. 결과가 사전 기대값(±이내)이면 드릴 PASS. 새 DB 삭제.
# 4. 드릴 결과 internal log 에 기록.

기준: users + links 카운트가 백업 시각 기준 ±5% 이내, last_signup 이 백업 시각 ±1시간 이내.

6. 백업 외부 보관 (장기)

basic_256mb 의 7일 보존이 부족하다고 판단되면:

# 매일 cron 에서 실행 (예: 자체 인프라 또는 GH Actions schedule)
pg_dump --format=custom --no-owner --no-acl "$LOGI_PG_URL" \
  | aws s3 cp - "s3://logi-backups/$(date +%Y%m%d).dump" \
      --storage-class STANDARD_IA

S3 lifecycle 으로 30일 후 Glacier 이행 → 비용 최소화.

7. 주의사항

• pg_dump 는 WORM trigger 가 막는 audit 테이블 도 그대로 덤프함. 복원 시 SET LOCAL logi.allow_audit_purge='yes' 필요할 수 있음 (memory: logi-eb-merge-rollout.md §"Anonymous purge audit DELETE").
• 마이그 직후 곧장 백업 받기보다, 마이그 검증 (5-10분 prod 모니터링) 후 백업 권장. 잘못된 마이그 결과를 백업해버릴 위험 회피.
• External Host 접속 시 IP 화이트리스트: <LOGI_PG_INSTANCE_ID> 는 0.0.0.0/0 허용 상태 (Render dashboard 확인). 운영팀 IP 만 허용으로 좁히는 게 보안 best practice.

관련 페이지

• 배포 Runbook — 마이그 실행 + 롤백
• Incident Response — sev1/sev2 시 백업 복원 분기 결정