PlanetScale 백업 복원 2026, Postgres 데이터 플랫폼 복구·비용 기준

PlanetScale 백업 복원과 Postgres 데이터 플랫폼 복구 훈련을 검토하는 회의 장면 — 백업은 파일 보관이 아니라 실제 복원, 비용, 권한, 운영 절차가 함께 검증될 때 의미가 있다.

PlanetScale 백업 복원을 검토하는 팀은 백업 버튼보다 복원 브랜치를 언제 만들고, 누가 검증하고, 얼마 동안 보관할지를 먼저 정해야 한다.

Postgres 데이터 플랫폼에서 장애 대응의 핵심은 백업이 존재한다는 사실이 아니라 원하는 시점으로 복구해 애플리케이션이 읽을 수 있는지 확인하는 것이다.

이번 후보는 GeekNews에서 발견된 PlanetScale의 병렬 Postgres 백업 글이 출발점이지만, 본문 근거는 PlanetScale 공식 엔지니어링 글과 문서로 다시 확인했다.

결론부터 말하면 PlanetScale 방식의 메시지는 단순하다.

이전 백업을 매 주기 실제로 복원하고 WAL을 재생해 다음 백업을 만들면 백업 파일 보관과 복구 가능성 검증이 같은 루프 안에 들어간다.

핵심 요약

PlanetScale Postgres 기본 백업은 문서 기준 12시간마다 생성되고 기본 보관 기간은 2일이다.
PITR은 보관 창 안에서 현재 시각 5분 전까지 특정 시점 복원을 지원하며, 복원은 새 브랜치로 시작하는 방식이 안전하다.
백업 비용은 기본 포함 용량 2x disk size를 넘는 백업·WAL 저장소, 보관 기간, 추가 브랜치, egress 정책에서 갈린다.
실무자는 복원 버튼보다 RPO, RTO, 권한, extension 재설치, smoke test, 비용 owner를 먼저 문서화해야 한다.

이 글이 필요한 사람

PlanetScale Postgres를 데이터 플랫폼 후보로 보면서 백업과 PITR 조건을 검토하는 플랫폼 담당자
MySQL 또는 Postgres 운영 DB에서 복구 훈련을 해본 적 없어 장애 대응 절차가 빈 조직
백업 보관 기간을 늘리려는데 추가 저장소 비용과 브랜치 비용을 누가 책임질지 정해야 하는 팀
샤딩 데이터베이스나 대용량 DB에서 백업이 프로덕션 IOPS에 미치는 영향을 걱정하는 SRE
감사 대응을 위해 복원 가능성, 보관 기간, 테스트 증적을 남겨야 하는 보안·컴플라이언스 담당자

PlanetScale 백업 구조에서 먼저 볼 사실

PlanetScale 공식 백업 문서는 Postgres 데이터베이스에 자동 예약 백업, 수동 온디맨드 백업, WAL 기반 point-in-time recovery가 포함된다고 설명한다.

기본 백업 일정은 production과 development branch 모두 12시간마다 실행된다고 문서화되어 있다.

기본 포함 백업은 추가 설정 없이 만들어지고, 백업과 WAL 파일은 클러스터 밖의 같은 클라우드 제공자와 같은 리전의 durable storage에 저장된다고 설명된다.

복원된 브랜치는 원본 브랜치와 독립된 새 database branch로 만들어지며, source branch와 같은 cloud region에 생성된다.

공식 확인 항목	문서 기준 숫자·조건	실무 판단	체크 질문
기본 백업 주기	production/development branch 모두 12시간마다 자동 백업	RPO 목표가 12시간보다 짧으면 PITR과 custom schedule을 같이 본다.	서비스별 허용 데이터 손실 시간이 몇 분인가
기본 보관 기간	default included backup schedule retains backups for 2 days	감사나 회계 요구가 2일을 넘으면 추가 비용 owner가 필요하다.	오래된 상태 복원이 실제로 필요한 기간은 며칠인가
PITR 가능 시점	retention window 안에서 현재 시각 5분 전까지 복원	삭제 직후 바로 0분 전으로 돌리는 기대는 위험하다.	사고 시각 기록이 초 단위로 남는가
복원 대상	restore to a new database branch	운영 브랜치를 덮지 않는 절차가 안전하다.	새 브랜치 연결과 승격 승인 절차가 있는가
extension 조건	restored branches do not restore database extensions	확장 기능을 쓰는 DB는 복원 후 재설치 체크가 필요하다.	pg extension 목록과 재설치 owner가 있는가

이 조건이면 PlanetScale 백업 복원 구조를 긍정적으로 검토할 수 있다.

서비스가 복원 브랜치에서 smoke test를 돌릴 수 있고, 사고 시각과 변경 이력이 티켓에 남는 경우다.

이 경우는 보류한다.

백업은 켜져 있지만 복원 브랜치 연결 문자열을 누가 바꾸는지, 애플리케이션 검증을 누가 하는지 정하지 못한 상태다.

이전 백업을 다시 복원해서 다음 백업을 만드는 이유

PlanetScale 엔지니어링 글은 sharded Postgres 백업에서 이전 건강한 백업을 각 shard별 임시 노드에 복원한 뒤 WAL을 재생해 현재 시점까지 따라잡는 구조를 설명한다.

이 방식은 백업 작업의 큰 IOPS와 compute 부담을 primary나 traffic-serving replica에서 떼어내기 위한 선택이다.

글에서는 8개 shard의 Neki database 예시, shard마다 새 EC2 instance를 띄우는 방식, S3 같은 object storage에서 이전 백업을 stream하는 흐름을 보여준다.

핵심은 매 백업 주기마다 이전 백업이 실제로 복원되고 WAL replay가 되는지 검증된다는 점이다.

단계	PlanetScale 글의 구조	운영 의미	실패 시 볼 것
이전 백업 복원	object storage의 prior backup을 shard별 임시 노드에 stream	백업 파일이 읽히는지 매 주기 확인된다.	저장소 접근, 압축 해제, 암호화 키, 네트워크 속도
WAL 재생	대부분은 S3 archived WAL에서 재생하고 마지막 몇 분은 primary에서 stream	primary 부담을 줄이면서 최신 시점에 접근한다.	WAL archival 지연, missing WAL, segment switch
시점 고정	모든 노드가 time T까지 따라잡으면 replication을 멈춘다.	smeared data 없이 일관된 snapshot을 만든다.	shard별 시각 불일치, lag 측정 오류
암호화 저장	완성 백업을 새 S3 bucket에 encrypt해 저장	재해 복구와 감사 증적의 기반이 된다.	key custody, retention, deletion protection
임시 노드 폐기	backup nodes are decommissioned	운영 비용과 공격 표면을 줄인다.	임시 자원 누수, 비용 태그 누락

이 방식은 기업이 자체 백업 시스템을 만들 때 그대로 복사하라는 뜻이 아니다.

대신 복구 가능성 검증을 별도 연례 훈련으로 미루지 말고 백업 주기 안에 넣어야 한다는 운영 원칙을 준다.

PITR은 삭제 직후 만능 되돌리기가 아니다

PlanetScale PITR 문서는 WAL과 주기적 백업을 결합해 지정 시점까지 복원한다고 설명한다.

기본 조건에서는 2일 전부터 현재 시각 5분 전까지 복원이 가능하다고 되어 있다.

5분 buffer는 WAL 파일이 처리되고 archive될 시간을 확보하기 위한 조건이다.

복원 시간은 cluster size, data volume, target restore point와 nearest available backup 사이의 WAL replay duration에 영향을 받는다.

복원 상황	공식 문서 기준	실무 판단	사전 준비
실수 삭제	삭제 직전 시점으로 PITR 복원 가능	새 브랜치에서 누락 행을 검증한 뒤 부분 복구 전략을 정한다.	사고 시각, 삭제 쿼리, 영향 테이블 기록
실패한 migration	문제 schema change 전으로 복구	앱 버전과 DB schema version을 같이 맞춰야 한다.	migration id, 배포 id, rollback plan
오래된 시점 복원	custom backup schedule과 긴 retention이 있으면 가능 범위가 늘어난다.	WAL replay gap이 길어지면 시간이 hours로 늘 수 있다.	복구 허용 시간과 보관 비용 승인
WAL missing 오류	WAL archival interruption이나 storage failure 가능성	nearest available backup을 대안으로 검토한다.	backup status alert와 archive 상태 모니터링
extension 사용 DB	복원 브랜치에서 extension은 자동 복원되지 않음	확장 기능 의존 서비스를 따로 검증한다.	extension 목록과 재설치 절차

이 조건이면 PITR을 운영 runbook의 중심에 둔다.

사고 시각을 로그에서 정확히 찾을 수 있고, 새 브랜치에서 데이터 검증 후 production 승격 여부를 판단할 수 있는 경우다.

이 경우는 PITR 기대치를 낮춘다.

정확한 사고 시각을 모르는 상태에서 단순히 “어제쯤”으로 복원하려는 경우다.

공식 가격표로 보는 백업 비용 항목

공식 가격 문서는 us-east-1 기준 예시이며, 실제 금액은 클라우드 제공자와 리전에 따라 달라진다고 명시한다.

PlanetScale Postgres 가격 문서는 branch마다 cluster compute와 storage resource가 millisecond 단위로 prorated billed 된다고 설명한다.

같은 문서는 backup storage, network egress data transfer, additional replicas, PgBouncer 같은 별도 과금 축을 나눈다.

비용 항목	공식 확인 숫자·단위	운영 의미	예산 질문
기본 cluster	Network-attached PS-5 single node $5/month, highly available $15/month	복원 브랜치를 오래 켜두면 테스트 비용이 누적된다.	복원 브랜치 보관 시간을 몇 시간으로 제한할 것인가
상위 cluster 예시	PS-10 single node $10 또는 $13/month, HA $30 또는 $39/month	ARM과 x86, HA 여부가 월액을 바꾼다.	운영과 복원 테스트에 같은 크기가 필요한가
백업 포함 용량	branch마다 disk size의 2x backup storage included	50 GB disk면 100 GB 백업 저장소가 포함된다.	보관 기간 증가가 included storage를 넘는가
백업 초과 저장소	included amount 초과 시 $0.023 per GB per month	긴 retention과 WAL 보관이 비용을 만든다.	감사 요구 기간을 비용표로 승인받았는가
public egress	PS-5 non-HA는 10 GB per month included public egress	복구 검증과 외부 분석 전송은 egress를 확인해야 한다.	테스트 데이터 export가 필요한가
private traffic	private connection traffic은 flat $0.01/GB	VPC 내부 검증 구조도 비용 축이 있다.	복원 검증 트래픽 경로가 private인가 public인가
PgBouncer 예시	us-east-1 PGB-5 $18/month, Seoul region PGB-5 $22/month	연결 풀러를 별도로 붙이면 월 비용이 추가된다.	복원 브랜치에 dedicated PgBouncer가 필요한가

비용 절감의 핵심은 백업을 줄이는 것이 아니다.

복원 브랜치의 수명, 보관 기간, custom schedule, 데이터 export 경로를 owner가 있는 정책으로 묶는 것이다.

이 조건이면 비용을 더 내도 맞다.

감사나 법적 보관 요구가 있고, 오래된 시점 복원이 실제 사고 대응에 필요한 경우다.

이 조건이면 비용을 줄인다.

개발자가 만든 복원 브랜치가 검증 후에도 며칠씩 켜져 있고, 보관 기간을 늘린 이유가 티켓에 남아 있지 않은 경우다.

복원 절차는 새 브랜치에서 시작한다

PlanetScale 백업 문서는 Backups page에서 백업을 선택하고 Restore to new branch를 눌러 restored branch를 만든다고 설명한다.

PITR 문서도 Backups page에서 branch dropdown과 restore backup 흐름을 통해 지정 시점 브랜치를 만든다고 안내한다.

이 흐름은 운영 DB를 직접 덮어쓰지 않는다는 점에서 안전하다.

사고 시각, 영향 테이블, 마지막 정상 배포 시간을 incident ticket에 적는다.
Backups page에서 source branch와 복원 가능한 backup 또는 PITR window를 확인한다.
현재 시각 5분 전 buffer와 retention window 안에 target time이 들어가는지 확인한다.
Restore to new branch 또는 Restore backup 흐름으로 새 브랜치를 만든다.
복원 브랜치의 연결 문자열을 별도 secret으로 만들고 production secret을 덮어쓰지 않는다.
extension 목록, migration version, 핵심 테이블 row count, 최근 주문·로그인 같은 smoke query를 확인한다.
애플리케이션은 읽기 전용 모드나 staging 환경에서 복원 브랜치와 연결해 최소 경로만 테스트한다.
production 승격, 부분 데이터 복구, 원본 유지 중 하나를 incident commander가 선택한다.
복원 브랜치 삭제 예정 시각과 비용 owner를 티켓에 남긴다.

이 순서에서 가장 위험한 실수는 복원 성공을 서비스 복구로 착각하는 것이다.

복원 브랜치가 생겼다는 사실과 애플리케이션이 그 데이터로 안전하게 동작한다는 사실은 다르다.

보안 기준: 백업은 데이터의 두 번째 복사본이다

백업과 WAL은 운영 DB의 민감 데이터가 압축·암호화되어 다른 저장 위치에 존재한다는 뜻이다.

PlanetScale 글은 완성된 백업을 encrypt해 safe keeping용 S3 bucket에 보낸다고 설명한다.

실무에서는 암호화 여부만 보지 말고 누가 백업 삭제를 막고, 누가 복원 브랜치에 접근하고, 누가 연결 문자열을 폐기하는지까지 정해야 한다.

보안 항목	확인 기준	위험 신호	조치
복원 권한	조직 관리자 또는 DB 관리자만 custom schedule과 복원을 수행	개발자 다수가 production 백업을 자유롭게 복원	권한을 분리하고 승인 티켓을 요구한다.
삭제 방지	Prevent backup deletion toggle 사용 여부를 기록	중요 백업이 자동 만료되거나 임의 삭제됨	사고·감사용 백업만 보호하고 owner를 지정한다.
연결 문자열	복원 브랜치 secret은 production secret과 분리	복원 테스트가 운영 secret을 재사용	별도 secret과 만료일을 둔다.
데이터 마스킹	개발·분석 검증은 필요한 집계만 조회	복원 브랜치를 분석가에게 원본 그대로 공유	읽기 전용 계정과 마스킹 view를 사용한다.
증적	복원 시작, 완료, 검증, 삭제 예정 시간이 티켓에 남음	누가 무엇을 복원했는지 불명확	audit trail과 change record를 묶는다.

이 조건이면 복원 권한을 넓혀도 된다.

staging 계정, 마스킹 데이터, 비용 한도, 자동 삭제 정책이 붙어 있고 production 데이터 접근이 없는 경우다.

이 경우는 강하게 보류한다.

고객 원본 데이터가 들어 있는 복원 브랜치를 편의상 분석 쿼리용으로 며칠씩 열어 두는 경우다.

실무 시나리오 1: 결제 테이블 삭제 직후

운영자가 잘못된 migration으로 최근 결제 테이블 일부를 삭제했다고 가정하자.

이 조건이면 바로 production을 되돌리기보다 삭제 직전 시각으로 새 PITR 브랜치를 만든다.

복원 브랜치에서는 영향 테이블 row count, 결제 id 범위, application read path를 확인한다.

부분 데이터 복구가 안전하면 원본 DB에 필요한 행만 검증 후 재삽입하고, 전체 승격은 마지막 선택지로 남긴다.

사고 시각이 불분명하면 WAL replay가 가능한 범위 안에서 여러 후보 시점을 비교해야 하므로 RTO가 늘어난다.

실무 시나리오 2: 대용량 SaaS의 분기별 복구 훈련

고객 데이터가 수십 TB로 커진 SaaS는 백업 목록만 캡처해도 감사 대응이 부족하다.

이 조건이면 분기마다 복원 브랜치를 만들고 smoke query, 애플리케이션 읽기 테스트, 삭제 예정 시각까지 기록한다.

PlanetScale 글의 병렬 백업 구조처럼 내부 서비스도 복구 가능성을 반복 검증해야 한다.

복원 훈련은 장애가 난 날 처음 해보면 늦다.

훈련 결과에는 RPO 목표, 실제 복원 시간, WAL replay 구간, 추가 비용, 실패 항목을 남긴다.

실무 시나리오 3: 감사 때문에 보관 기간을 늘릴 때

보안팀이 31일 또는 그 이상 보관을 요구하면 플랫폼팀은 단순히 retention만 늘리면 안 된다.

PlanetScale 문서는 custom schedule과 manual backup 보관이 추가 비용을 만들 수 있다고 안내한다.

이 조건이면 보관 기간, backup storage overage, branch별 disk size, deletion protection 대상을 표로 승인받는다.

감사 요구가 특정 월말 스냅샷이면 모든 branch에 긴 retention을 걸 필요가 없을 수 있다.

반대로 법적 분쟁이나 장기 사고 분석 요구가 있으면 비용보다 보전 증적이 우선이다.

운영 스켈레톤: 복원 훈련 runbook

아래 YAML은 실제 제품 설정 파일이 아니라 PlanetScale 백업 복원 훈련의 책임과 합격 기준을 고정하기 위한 검토 스켈레톤이다.

# planetscale-restore-runbook.yaml
# 목적: PlanetScale Postgres 백업 복원 테스트를 장애 대응 훈련으로 운영한다.
# 실제 조직명, DB명, 시간대, 책임자는 내부 변경관리 절차에 맞춰 바꾼다.

restore_drill:
  owner: data-platform-lead
  service: customer-ledger
  branch_source: production
  restore_target: new_branch_only
  planned_frequency: quarterly
  max_rpo_minutes: 30
  max_rto_minutes: 90
  forbidden_actions:
    - restore_directly_over_production
    - promote_without_application_smoke_test
    - extend_retention_without_cost_owner
    - ignore_extension_reinstall

precheck:
  required:
    - latest_backup_status_success
    - pitr_window_contains_incident_time
    - readonly_smoke_query_prepared
    - application_secret_for_restored_branch_separated
    - cost_owner_approved_temporary_branch
    - rollback_decision_owner_named

acceptance:
  - restored_branch_created == true
  - schema_migration_check_passed == true
  - row_count_sample_within_expected_range == true
  - application_readonly_smoke_test_passed == true
  - old_branch_not_modified == true
  - drill_report_written == true

이 runbook의 핵심은 restore_target을 new_branch_only로 제한하고, production 승격을 별도 의사결정으로 분리하는 것이다.

CLI 복구 리허설 예시

PlanetScale CLI 문서는 backup 하위 명령으로 create, delete, list, restore, show를 안내한다.

아래 흐름은 운영 명령이 아니라 복구 훈련 전 담당자가 어떤 정보를 확인해야 하는지 정리한 예시다.

# PlanetScale backup CLI rehearsal
# 공식 CLI 문서의 backup 하위 명령을 복구 훈련 체크리스트 형태로 정리한 예시다.
# 자리표시자는 실제 이름으로 바꾸고, 운영 브랜치에 직접 덮어쓰지 않는다.

pscale backup list <DATABASE_NAME> <BRANCH_NAME> --org <ORGANIZATION_NAME>
pscale backup show <DATABASE_NAME> <BRANCH_NAME> <BACKUP_ID> --org <ORGANIZATION_NAME>
pscale backup restore <DATABASE_NAME> <BRANCH_NAME> <BACKUP_ID> --org <ORGANIZATION_NAME>

# 복원 후에는 새 브랜치 연결 문자열, 스키마 상태, 애플리케이션 읽기 전용 동작을 별도 검증한다.
# 프로덕션 승격은 별도 변경 승인과 롤백 기준이 있을 때만 진행한다.

명령이 있는 것과 권한을 열어도 된다는 뜻은 다르다.

복원 명령은 조직 관리자와 데이터베이스 관리자 권한, 변경 승인, 비용 owner가 연결되어야 한다.

복원 브랜치 smoke query 예시

복원 성공 후에는 전체 데이터를 눈으로 확인하지 말고 짧은 쿼리로 구조와 최근 범위를 검증한다.

-- restored-branch-smoke-check.sql
-- 목적: 복원 브랜치가 읽기 가능한지 확인하는 최소 검증 예시다.
-- 고객 개인정보 원문을 출력하지 않도록 집계와 샘플 해시만 사용한다.

select current_timestamp as checked_at;

select table_schema, count(*) as table_count
from information_schema.tables
where table_schema not in ('pg_catalog', 'information_schema')
group by table_schema
order by table_schema;

select 'orders' as table_name, count(*) as row_count
from orders
where created_at >= current_date - interval '7 days';

-- 실제 서비스에서는 핵심 테이블별 행 수 범위, 최근 쓰기 시간, migration version을 추가한다.

이 SQL은 개인정보 원문을 출력하지 않는다는 점이 중요하다.

실제 서비스에서는 핵심 업무 테이블마다 expected row range와 migration version 기준을 추가해야 한다.