백업(Backup)

원문 보기 위키 갱신 2026.10.03

CloudNativePG에서 PostgreSQL 클러스터의 물리적 백업을 다루는 방법을 살펴볼게요. WAL 아카이브, 핫/콜드 백업, 예약/온디맨드 백업, 백업 방법 선택, 스탠바이 백업까지 정리해 드릴게요.

출처: 문서

본문

:::info 이 섹션은 PostgreSQL의 물리적 백업을 다뤄요. PostgreSQL은 pg_dump 유틸리티를 사용한 논리적 백업도 지원하지만, 이는 비즈니스 연속성에 적합하지 않고 CloudNativePG가 관리하지 않아요. 그래도 pg_dump를 사용하고 싶다면 Troubleshooting / Emergency backup 섹션을 참고하세요. :::

:::info[Important] 버전 1.26부터 네이티브 백업/복구 기능은 코어 오퍼레이터에서 점진적으로 단계적으로 제거되고 공식 CNPG-I 플러그인으로 이동하고 있어요. 이 전환은 CloudNativePG의 백업 독립적(backup-agnostic) 아키텍처로의 이동과 일치하며, 확장 가능한 인터페이스인 CNPG-I가 WAL 아카이빙, 물리적 기본 백업, 해당 복구 프로세스 관리를 표준화해요. :::

CloudNativePG는 현재 PostgreSQL 클러스터의 물리적 백업을 두 가지 주요 방식으로 지원해요:

CNPG-I 플러그인을 통한 방식: CloudNativePG 커뮤니티는 오브젝트 스토리지 서비스와의 통합을 위해 Barman Cloud Plugin을 공식적으로 지원해요.
네이티브 방식, 다음을 지원:
- Barman Cloud를 통한 오브젝트 스토리지 (1.26부터 Barman Cloud Plugin을 위해 deprecated)
- Kubernetes 볼륨 스냅샷, 기본 스토리지 클래스가 지원하는 경우

CloudNativePG로 백업 전략을 선택하기 전에 "Main Concepts" 섹션에서 다루는 기본 개념에 익숙해지는 것이 중요해요. 여기에는 WAL 아카이빙, 핫/콜드 백업, 스탠바이에서의 백업 등이 포함돼요.

주요 개념

PostgreSQL은 파일 시스템 레벨(물리적) 복사에 기반한 일급 백업 및 복구 기능을 네이티브로 제공해요. 이는 15년 이상 미션 크리티컬 프로덕션 데이터베이스에서 성공적으로 사용되어 왔고, 전 세계 조직이 Postgres로 재해 복구 목표를 달성하도록 도왔어요.

CloudNativePG에서 각 PostgreSQL 클러스터의 백업 인프라는 다음 리소스로 구성돼요:

WAL 아카이브: Postgres가 지속적으로 쓰고 데이터 내구성을 위해 아카이브하는 WAL 파일(트랜잭션 로그)을 포함하는 위치
물리적 기본 백업(Physical base backups): PostgreSQL이 데이터베이스의 데이터를 저장하는 데 사용하는 모든 파일의 복사본(주로 PGDATA와 모든 테이블스페이스)

CNPG-I는 WAL 아카이빙(아카이브와 복원 작업 모두)과 기본 백업 및 해당 복원 프로세스를 관리하기 위한 일반적이고 확장 가능한 인터페이스를 제공해요.

WAL 아카이브

PostgreSQL의 WAL 아카이브는 연속 백업의 핵심이며, 다음 이유로 근본적으로 중요해요:

핫 백업(Hot backups): 서버를 종료하지 않고 Postgres 클러스터의 임의의 인스턴스(프라이머리 또는 스탠바이)에서 물리적 기본 백업을 찍을 수 있는 가능성; 온라인 백업이라고도 해요
시점 복구(PITR): 시스템에서 사용 가능한 첫 번째 기본 백업부터 임의의 시점에서 복구할 수 있는 가능성

:::warning WAL 아카이브 단독으로는 쓸모가 없어요. 물리적 기본 백업 없이는 PostgreSQL 클러스터를 복원할 수 없어요. :::

일반적으로 WAL 아카이브의 존재는 PostgreSQL 클러스터의 복원력을 향상시켜, 각 인스턴스가 필요 시 아카이브에서 필요한 WAL 파일을 가져올 수 있게 해줘요(보통 WAL 아카이브는 해당 파일을 재활용하는 Postgres 인스턴스보다 더 긴 보존 기간을 가져요).

이 사용 사례는 복제 클러스터로도 확장할 수 있어요. 장거리에 걸쳐 동기화하기 위해 WAL 아카이브에 의존할 수 있고, 다른 리전에 걸쳐 재해 복구 목표를 확장할 수 있기 때문이에요.

WAL 아카이브를 구성하면 CloudNativePG는 리전을 넘나들어도 재해 복구를 위해 RPO ≤ 5분을 기본 제공해요.

:::info[Important] 프로덕션에서는 항상 WAL 아카이브를 설정할 것을 권장해요. 위 혜택이 필요 없는 알려진 사용 사례(보통 스테이징 및 개발 환경을 포함)에서는 WAL 아카이브가 필요하지 않아요. 이 경우 RPO는 24시간(일일 백업)이나 무한(백업 없음) 같은 임의의 값이 될 수 있어요. :::

콜드 및 핫 백업

핫 백업은 이전 섹션에서 이미 정의했어요. WAL 아카이브의 존재를 요구하며, 현대 데이터베이스 관리 시스템에서 표준이에요.

콜드 백업, 오프라인 백업이라고도 하며, PostgreSQL 인스턴스(스탠바이 또는 프라이머리)가 종료되었을 때 찍는 물리적 기본 백업이에요. 정의상 일관성이 있으며, 데이터베이스가 종료된 시점의 스냅샷을 나타내요.

결과적으로 PostgreSQL 인스턴스는 WAL 아카이브 없이도 콜드 백업에서 재시작할 수 있어요. 단, WAL 아카이브가 있다면 그 이점을 활용할 수 있어요(복구 측면의 모든 이점은 이전 섹션에서 강조했어요).

RPO가 더 높고(예: 1시간 또는 24시간) 보존 기간이 더 짧은 상황에서 콜드 백업은 재해 복구 계획에 고려할 가치가 있는 실행 가능한 옵션이에요.

사용 가능한 백업 옵션 비교: 오브젝트 스토어 vs 볼륨 스냅샷

CloudNativePG는 현재 물리적 백업에 두 가지 주요 접근 방식을 지원해요:

오브젝트 스토어 기반 백업, Barman Cloud Plugin 또는 deprecated 네이티브 통합을 통해
볼륨 스냅샷, Kubernetes CSI 인터페이스와 지원되는 스토리지 클래스를 사용

:::info[Important] CNPG-I는 제3자가 자체 백업 플러그인을 구축하고 통합할 수 있도록 설계됐어요. 시간이 지나면서 지원되는 백업 솔루션의 생태계가 성장할 것으로 기대해요. :::

오브젝트 스토어 기반 백업

오브젝트 스토어(예: AWS S3, Azure Blob, GCS)에 대한 백업:

항상 WAL 아카이빙을 요구해요
핫 백업만 지원해요
증분 또는 차등 복사를 지원하지 않아요
보존 정책을 지원해요

볼륨 스냅샷

네이티브 볼륨 스냅샷:

WAL 아카이빙을 요구하지 않지만, 프로덕션에서는 여전히 그 사용을 강력히 권장해요
기본 스토리지 클래스의 기능에 따라 증분 및 차등 복사를 지원해요
핫 및 콜드 백업을 모두 지원해요
보존 정책을 지원하지 않아요

둘 사이의 선택

최상의 접근 방식은 환경과 운영 요구사항에 따라 달라져요. 다음 요소를 고려하세요:

오브젝트 스토어 가용성: Kubernetes 클러스터가 안정적인 네트워킹 레이어를 포함한 신뢰할 수 있는 오브젝트 스토리지 솔루션에 접근할 수 있는지 확인하세요.
스토리지 클래스 기능: 스토리지 클래스가 증분/차등 기능이 있는 CSI 볼륨 스냅샷을 지원하는지 확인하세요.
데이터베이스 크기: 매우 큰 데이터베이스(VLDB)의 경우 볼륨 스냅샷이 일반적으로 선호돼요. copy-on-write 기술 덕분에 더 빠른 복구가 가능해지고, 이것이 Recovery Time Objective(RTO)를 크게 개선해요.
데이터 이동성: 오브젝트 스토어 기반 백업은 리전이나 환경 간에 백업을 복제하거나 저장하는 데 더 큰 유연성을 제공할 수 있어요.
운영 친숙도: 팀의 경험과 스토리지 관리에 대한 자신감에 가장 잘 맞는 방법을 선택하세요.

비교 요약

Feature	Object Store	Volume Snapshots
WAL archiving	Required	Recommended^1^
Cold backup	❌	✅
Hot backup	✅	✅
Incremental copy	❌	✅^2^
Differential copy	❌	✅^2^
Backup from a standby	✅	✅
Snapshot recovery	❌^3^	✅
Retention policies	✅	❌
Point-in-Time Recovery (PITR)	✅	Requires WAL archive
Underlying technology	Barman Cloud	Kubernetes API

Notes:

WAL archiving must currently use an object store through a plugin (or the deprecated native one).

Availability of incremental and differential copies depends on the capabilities of the storage class used for PostgreSQL volumes.

Snapshot recovery can be emulated by using the bootstrap.recovery.recoveryTarget.targetImmediate option.

예약 백업(Scheduled Backups)

예약 백업은 CloudNativePG에서 신뢰할 수 있는 백업 전략을 구현하는 권장 방법이에요. ScheduledBackup 커스텀 리소스를 사용해 정의해요.

:::info 전체 구성 옵션 목록은 API 참조의 ScheduledBackupSpec을 참고하세요. :::

Cron 스케줄

schedule 필드는 초(seconds)를 포함하는 여섯 필드 cron 표현식을 사용해 백업이 언제 발생할지 정의해요. 이 형식은 Go cron 패키지 사양을 따르며, 전통적인 Unix/Linux crontab과 다르다는 점을 유의하세요.

:::warning 이 형식은 전통적인 Unix/Linux crontab과 다르며, 첫 번째 항목으로 초(seconds) 필드를 포함해요. :::

일일 예약 백업 예시:

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0 * * *"  # At midnight every day
  backupOwnerReference: self
  cluster:
    name: pg-backup
  # method: plugin, volumeSnapshot, or barmanObjectStore (default)

스케줄 "0 0 0 * * *"은 매일 자정(00:00:00)에 백업을 트리거해요. Kubernetes CronJob에서 동등한 표현식은 0 0 * * *이에요. 초를 지원하지 않기 때문이에요.

:::warning spec.cluster 필드는 생성 후 변경할 수 없어요(immutable). 다른 Cluster에 대한 백업을 예약하려면 기존 리소스를 업데이트하는 대신 새 ScheduledBackup 리소스를 만들세요. :::

백업 빈도와 RTO

:::tip[Hint] 백업 빈도는 **Recovery Time Objective(RTO)**에 직접적인 영향을 미쳐요. :::

연속 백업에 기반한 재해 복구 전략을 최적화하려면:

백업에서 복원하는 것을 정기적으로 테스트하세요.
전체 복구에 필요한 시간을 측정하세요.
검색하고 재생해야 하는 기본 백업의 크기와 WAL 파일 수를 고려하세요.

대부분의 경우 주간 기본 백업이 충분해요. 일일 1회보다 더 자주 전체 백업을 예약하는 것은 드물어요.

즉시 백업

ScheduledBackup이 생성될 때 즉시 백업을 트리거하려면:

spec:
  immediate: true

예약 백업 일시 중지

예약 백업이 실행되지 않도록 일시적으로 중지하려면:

spec:
  suspend: true

Backup 소유자 참조 (`.spec.backupOwnerReference`)

백업 리소스의 소유자로 설정할 Kubernetes 오브젝트를 제어해요:

none: 소유자 참조 없음 (레거시 동작)
self: ScheduledBackup 오브젝트가 소유자가 됨
cluster: PostgreSQL 클러스터가 소유자가 됨

온디맨드 백업(On-Demand Backups)

온디맨드 백업은 언제든지 Backup 리소스를 만들어 백업 작업을 수동으로 트리거할 수 있게 해줘요.

:::info 사용 가능한 옵션의 전체 목록은 API 참조의 BackupSpec을 참고하세요. :::

예시: 온디맨드 백업 요청

온디맨드 백업을 시작하려면 다음과 같은 Backup 요청 커스텀 리소스를 적용하세요:

apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: backup-example
spec:
  method: barmanObjectStore
  cluster:
    name: pg-backup

이 예시에서 오퍼레이터는 barman-cloud-backup 도구를 사용해 백업 프로세스를 오케스트레이션하고 백업을 구성된 오브젝트 스토어에 저장해요.

백업 진행 상황 모니터링

다음을 사용해 백업 상태를 확인할 수 있어요:

kubectl describe backup backup-example

백업이 진행 중일 때 다음과 유사한 출력을 볼 수 있어요:

Name:         backup-example
Namespace:    default
...
Spec:
  Cluster:
    Name:  pg-backup
Status:
  Phase:       running
  Started At:  2020-10-26T13:57:40Z
Events:        <none>

백업이 성공적으로 완료되면 phase가 completed로 설정되고, 출력에 추가 메타데이터가 포함돼요:

Name:         backup-example
Namespace:    default
...
Status:
  Backup Id:         20201026T135740
  Destination Path:  s3://backups/
  Endpoint URL:      http://minio:9000
  Phase:             completed
  S3 Credentials:
    Access Key Id:
      Name:  minio
      Key:   ACCESS_KEY_ID
    Secret Access Key:
      Name:  minio
      Key:   ACCESS_SECRET_KEY
  Server Name:       pg-backup
  Started At:        2020-10-26T13:57:40Z
  Stopped At:        2020-10-26T13:57:44Z

:::info[Important] 온디맨드 백업은 PostgreSQL 수퍼유저 또는 애플리케이션 사용자용 Kubernetes 시크릿을 포함하지 않아요. 이러한 시크릿이 더 넓은 Kubernetes 클러스터 백업 전략에 포함되도록 해야 해요. :::

백업 방법

CloudNativePG는 현재 예약 및 온디맨드 백업에 다음 백업 방법을 지원해요:

plugin – CNPG-I 플러그인 사용 (.spec.plugins 필요)
volumeSnapshot – 네이티브 Kubernetes 볼륨 스냅샷 사용
barmanObjectStore – 오브젝트 스토리지용 Barman Cloud 사용 (v1.26부터 Barman Cloud Plugin을 위해 deprecated, 하지만 하위 호환성을 위해 여전히 기본값)

.spec.method 필드로 방법을 지정해요(기본값은 barmanObjectStore).

클러스터가 볼륨 스냅샷을 지원하도록 구성되어 있다면 다음과 같이 예약 스냅샷 백업을 활성화할 수 있어요:

spec:
  method: volumeSnapshot

Barman Cloud Plugin을 백업 방법으로 사용하려면 method: plugin으로 설정하고 플러그인을 그에 따라 구성하세요. 예시는 플러그인 문서의 "Performing a Base Backup" 섹션에서 찾을 수 있어요.

스탠바이에서 백업하기

기본 백업을 찍는 것은 PostgreSQL 인스턴스의 온디스크 데이터 세트 전체를 읽는 것을 수반하며, I/O 경합을 유발하고 활성 워크로드의 성능에 영향을 줄 수 있어요.

이 영향을 줄이기 위해 CloudNativePG는 스탠바이 인스턴스에서 백업을 찍는 것을 지원해요. PostgreSQL의 읽기 전용 복제본에서 백업을 수행하는 내장 기능을 활용해요.

기본적으로 백업은 클러스터에서 가장 최신 상태의 복제본에서 수행돼요. 복제본이 없으면 백업은 프라이머리 인스턴스로 폴백해요.

:::note 이 섹션의 예시는 백업 대상 선택에 초점을 맞추며, 논의 중인 범위와 관련이 없으므로 백업 방법(spec.method)을 고려하지 않아요. :::

동작 방식

prefer-standby가 대상일 때(기본 동작) CloudNativePG는 다음을 시도해요:

가장 동기화된 스탠바이 노드를 식별한다.
해당 스탠바이에서 백업 프로세스를 실행한다.
스탠바이가 없으면 프라이머리로 폴백한다.

이 전략은 프라이머리의 워크로드에 대한 간섭을 최소화해요.

:::warning 스탠바이가 항상 프라이머리와 최신 상태가 아닐 수 있지만, 첫 번째 사용 가능한 백업에서 마지막 아카이브된 WAL까지의 시간 연속체에서 이는 보통 무관해요. 기본 백업은 실제로 PITR을 포함한 복구 작업을 시작할 시작점을 나타내요. pg_basebackup에서와 마찬가지로 온라인 스탠바이에서 백업할 때 프라이머리에서 WAL 전환을 강제하지 않아요. 이는 쓰기 활동이 낮은 배포에서 단기간(archive_timeout이 발동하기 전) 예기치 않은 결과를 초래할 수 있어요. :::

프라이머리에서 백업 강제하기

항상 프라이머리 인스턴스에서 백업을 실행하려면 클러스터 구성에서 백업 대상을 primary로 명시적으로 설정하세요:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
  [...]
spec:
  backup:
    target: "primary"

:::warning 볼륨 스냅샷을 사용한 콜드 백업에서 primary를 대상으로 사용할 때는 주의하세요. 프라이머리 인스턴스를 일시적으로 종료해야 하며, 이는 모든 쓰기 작업을 중단하게 해요. 대상(target)을 명시적으로 설정하지 않은 경우에도 단일 인스턴스 클러스터에는 동일한 주의가 적용돼요. :::

클러스터 전체 대상 오버라이드하기

Backup 또는 ScheduledBackup 리소스를 사용해 백업별로 클러스터 레벨 대상을 오버라이드할 수 있어요. 다음은 온디맨드 백업 예시예요:

apiVersion: postgresql.cnpg.io/v1
kind: Backup
metadata:
  name: backup-example
  [...]
spec:
  cluster:
    name: [...]
  target: "primary"

이 예시에서 클러스터의 기본 대상이 prefer-standby여도 백업은 프라이머리 인스턴스에서 수행돼요.

보존 정책

CloudNativePG는 백업 책임이 외부 CNPG-I 플러그인에 위임되는 백업 독립적 아키텍처로 진화하고 있어요. 이 플러그인들은 CloudNativePG의 내장 기능과 범위를 넘어서는 정교한 보존 관리를 포함한 고급 및 커스터마이즈 가능한 데이터 보호 기능을 제공할 것으로 기대돼요.

이 전환의 일환으로 Cluster 리소스의 spec.backup.retentionPolicy 필드는 deprecated이며 향후 릴리스에서 제거될 거예요.

사용 가능한 보존 기능에 대한 자세한 내용은 선택한 플러그인의 문서를 참고하세요. 예: Barman Cloud Plugin의 "Retention Policies".

:::info[Important] 사용 중인 백업 플러그인이 제공하는 보존 메커니즘에 의존할 것을 권장해요. 이는 사용 중인 백업 방법과의 더 나은 유연성과 일관성을 보장해요. :::