7.1 Backup

Backup은 실행 중인 PostgreSQL 클러스터의 데이터 디렉토리를 물리적으로 복사해 두는 작업이다. CloudNativePG에서 backup은 in-place로 되돌리는 것이 아니라, 나중에 그 사본으로 새 클러스터를 부트스트랩하기 위한 재료다. 그래서 복구 절(7.3)과 짝을 이룬다.

한 가지 원칙을 먼저 못 박아 둔다. 공식 문서는 “WAL archive만으로는 아무것도 못 한다. 물리 base backup이 없으면 클러스터를 복원할 수 없다"고 명시한다. 즉 base backup과 WAL archive(7.2)는 둘 다 있어야 의미가 있다.

백업 방식 두 가지

CNPG는 base backup을 만드는 방식을 크게 둘로 나눈다.

• object store 백업: base backup을 S3·Azure Blob·GCS 같은 오브젝트 스토리지로 보낸다. 1.30 기준 권장 경로는 Barman Cloud Plugin(CNPG-I)이다.
• volume snapshot 백업: Kubernetes CSI가 제공하는 볼륨 스냅샷으로 PVC를 통째로 뜬다. 스토리지의 copy-on-write를 활용해 대용량 DB에서 특히 빠르다.

    flowchart TD
    CL["Cluster (primary)"]
    BK["Backup 리소스"]
    OS["object store<br/>(S3·Azure·GCS)"]
    VS["volume snapshot<br/>(CSI PVC)"]
    WAL["WAL archive"]

    CL --> BK
    BK -->|method: plugin| OS
    BK -->|method: volumeSnapshot| VS
    CL -.연속 아카이브.-> WAL
    OS -.PITR 재료.-> WAL
    VS -.PITR 재료.-> WAL
  

두 방식의 성격 차이는 뚜렷하다. 아래 표로 정리한다.

정리하면, object store는 보존 정책과 연속 백업에 강하고, volume snapshot은 대용량(VLDB)에서 복구 속도에 강하다. 공식 권고는 “아주 큰 데이터베이스에는 volume snapshot이 일반적으로 낫다"이다.

Barman Cloud Plugin으로 object store 붙이기

1.30에서 object store 백업의 권장 방식은 Barman Cloud Plugin이다. 백업 대상 스토리지 설정을 ObjectStore라는 별도 리소스로 떼어 내고, Cluster는 그것을 이름으로 참조한다. 백업 설정이 클러스터 정의에서 분리되어 재사용·관리가 쉬워진다.

먼저 스토리지를 기술하는 ObjectStore를 만든다.

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: minio-store
spec:
  configuration:
    destinationPath: s3://backups/
    endpointURL: http://minio:9000
    s3Credentials:
      accessKeyId:
        name: minio
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: minio
        key: ACCESS_SECRET_KEY
    wal:
      compression: gzip

그리고 Cluster의 .spec.plugins에서 이 ObjectStore를 참조한다. isWALArchiver: true가 이 플러그인을 WAL archiver로도 지정한다(7.2).

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: minio-store
  storage:
    size: 1Gi

이렇게 하면 WAL archiving과 데이터 디렉토리 백업이 함께 활성화된다. barmanObjectName은 앞서 만든 ObjectStore의 이름과 같아야 한다.

온디맨드 백업

지금 당장 한 번 백업하려면 Backup 리소스를 만든다. method로 방식을 고른다.

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

진행 상황은 다음으로 확인한다. status는 running을 거쳐 completed로 넘어가며, Backup ID·저장 경로 등의 메타데이터를 보여 준다.

kubectl describe backup backup-example

예약 백업(ScheduledBackup)

정해진 주기로 백업을 반복하려면 ScheduledBackup을 쓴다. schedule은 초까지 포함하는 여섯 필드 cron 표현식이다(표준 cron과 달리 맨 앞 필드가 초).

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0 * * *"   # 매일 자정
  backupOwnerReference: self
  cluster:
    name: cluster-example

주요 옵션은 다음과 같다.

• schedule: 여섯 필드 cron(초 포함).
• immediate: true: 리소스를 만들 때 즉시 한 번 백업한다.
• suspend: true: 예약 백업을 잠시 멈춘다.
• backupOwnerReference: none·self·cluster 중 하나.

백업 주기는 곧 복구 목표 시간(RTO)에 직결된다. 공식 권고는 “대부분의 경우 주 1회 base backup이면 충분하고, 하루에 한 번보다 자주 full backup을 잡는 일은 드물다"이다. 나머지 간격은 WAL archive가 메운다.

standby에서 백업 뜨기

CNPG는 primary 부하를 줄이려고 기본적으로 “가장 최신 상태의 replica"에서 백업을 뜬다. primary에서 강제로 뜨게 하려면 대상을 지정한다.

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

보존 정책

오브젝트 스토리지에 백업이 무한정 쌓이지 않도록 보존 정책으로 오래된 백업과 WAL을 정리한다. 단, 이 관리 주체가 1.30에서 바뀌었다.

Cluster의 .spec.backup.retentionPolicy 필드는 deprecated이다. 공식 문서는 “사용하는 백업 플러그인이 제공하는 보존 메커니즘에 의존하라"고 안내한다. Barman Cloud Plugin을 쓰면 보존 정책은 ObjectStore의 .spec.retentionPolicy로 옮겨 정의한다.

volume snapshot은 보존 정책을 지원하지 않는다는 점을 기억한다. 스냅샷 수명 관리는 Kubernetes 쪽 스냅샷 관리나 별도 절차로 다뤄야 한다.

정리

• base backup과 WAL archive는 둘 다 있어야 복구가 성립한다.
• object store는 보존 정책·연속 백업에, volume snapshot은 대용량 복구 속도에 강하다.
• 1.30 권장 경로는 Barman Cloud Plugin이다. ObjectStore 리소스 + Cluster .spec.plugins 참조로 구성한다.
• 반복 백업은 ScheduledBackup(초 포함 여섯 필드 cron), 일회성은 Backup으로 실행한다.
• 보존 정책은 이제 플러그인(ObjectStore) 쪽으로 옮겨 관리한다.

다음 절(7.2)에서는 base backup 사이의 간격을 메우는 WAL archiving을 본다.