새 Cluster로 시점 복구하기

내용 검토: 2026. 09. 28.

결론부터

원본을 보존한 채 새 Cluster로 복구하고, 목표 데이터와 앱 연결을 확인한 뒤 전환을 결정한다.

백업이 있어도 잘못된 시점으로 복원하거나 원본과 같은 아카이브 경로에 새 이력을 쓰면 복구가 꼬일 수 있다. 이 페이지는 복구 입력, 별도 출력, 검증, 전환을 나누어 설명한다.

이 장에서 처음 나오는 말3개

recovery target복구 목표: WAL을 어디까지 재생할지 정하는 시각·트랜잭션 등의 기준.
bootstrap.recovery: 새 CNPG Cluster를 기존 백업으로 초기화하는 설정.
serverName백업의 원본 이름: 저장소에서 어떤 원본 클러스터의 백업·WAL을 읽을지 식별한다.

복구 입력과 출력 분리

원본 Cluster의 베이스 백업과 WAL을 읽어 새 복원 Cluster를 만들고 검증 후 앱 연결 전환을 판단하는 흐름

복원한 Cluster는 원본과 다른 쓰기 이력을 시작할 수 있다. 원본을 계속 쓰면서 복원본도 앱에 연결하면 업무 데이터가 갈라질 수 있으므로 전환 시 쓰기 중지와 데이터 차이 처리를 정한다. (CNPG 복구)

무엇을 복구할지 표시하기

전제는 백업 구성을 마친 일회용 study-pg, 동작하는 아카이브, 추가 복원 PVC를 만들 수 있는 공간이다. 다음은 실습에서 수행할 절차이며 작성 시 실행하지 않았다.

관리 psql을 연다.

kubectl cnpg psql -n pg-study study-pg -- -d studydb

다음 두 문장을 자동 커밋 상태에서 실행한다.

CREATE TABLE public.recovery_probe (id integer PRIMARY KEY, note text NOT NULL);
INSERT INTO public.recovery_probe VALUES (1, '남아야 하는 행');

psql에서 나와 앞 페이지의 backup.yaml을 복사하되 Backup 이름을 study-pg-before-delete로 바꾸어 새 베이스 백업을 요청하고 completed를 기다린다. 이 백업 안에는 probe 테이블과 행이 있어야 한다.

다시 같은 DB의 관리 psql에 접속해 한 문장씩 실행한다.

SELECT clock_timestamp() AS restore_target;
-- 출력 시각을 시간대까지 별도로 기록한다.
SELECT pg_sleep(2);
DELETE FROM public.recovery_probe WHERE id = 1;
SELECT pg_switch_wal();

restore_target은 백업 완료 뒤, 삭제 커밋 전의 시점이다. pg_switch_wal()은 WAL 구간 전환을 요청할 뿐 업로드 완료를 보증하지 않는다. 아카이브 상태를 확인해 삭제를 포함한 구간까지 저장된 뒤 복구한다. (WAL 아카이브)

복원용 Cluster

restore.yaml로 저장하고 targetTime을 방금 기록한 실제 시각으로 바꾼다. 아래 날짜는 형태 예시이며 그대로 쓰면 실습 백업 범위를 벗어날 수 있다. StorageClass도 앞에서 사용한 실제 이름으로 맞춘다.

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: study-pg-restore
  namespace: pg-study
spec:
  instances: 1
  imageName: ghcr.io/cloudnative-pg/postgresql:18.6-standard-trixie
  storage:
    storageClass: db-lab
    size: 10Gi
  bootstrap:
    recovery:
      source: source-backup
      recoveryTarget:
        targetTime: "2026-09-28 12:00:00+00"
  externalClusters:
    - name: source-backup
      plugin:
        name: barman-cloud.cloudnative-pg.io
        parameters:
          barmanObjectName: study-backups
          serverName: study-pg

source-backup은 이 설정 안에서 사용하는 참조 이름이고, study-pg는 저장된 백업의 원본 이름이다. 원본에서 플러그인 serverName을 별도로 지정했다면 그 값을 사용해야 한다. (플러그인 복구 설정)

kubectl apply --dry-run=server -f restore.yaml
kubectl apply -f restore.yaml
kubectl cnpg status -n pg-study study-pg-restore
kubectl cnpg psql -n pg-study study-pg-restore -- \
  -d studydb -c 'TABLE public.recovery_probe;'

복원 DB에는 ID 1이 보이고 원본에는 없어야 한다. 목표 도달 전에 복구가 중단되면 백업 선택·WAL 연속성· 인증서·네트워크·목표 시각과 시간대를 확인한다. 단순히 Pod가 Running인 것으로 완료 처리하지 않는다.

검증 뒤 전환하기

이 예제의 복원본은 한 인스턴스로 검사하기 위한 것이며 새 WAL 아카이브를 구성하지 않았다. 서비스에 사용할 때는 가용성·백업·보안·관측을 갖추고, 복원본의 아카이브가 원본 백업 이름 공간에 섞이지 않도록 새 저장 대상 또는 새 serverName을 명시한다.

앱 role·Secret·인증서·풀러·서비스 주소를 확인하고 필요한 업무 쿼리를 실행한다. 복원 이후의 원본 변경을 버릴지 이행할지도 결정해야 한다. study-pg-restore-rw가 생겼다고 원본 study-pg-rw를 쓰는 앱이 자동으로 전환되는 것은 아니다.

실습 정리

검증을 마친 복원본은 kubectl delete -f restore.yaml로 삭제하고 남은 PVC/PV 정책을 확인한다. 원본 실습 DB의 probe는 관리자 psql에서 DROP TABLE public.recovery_probe;로 정리한다. 원본 백업은 보관 정책에 따라 관리한다. 새 복원본 삭제와 원본 백업 삭제를 한 작업으로 묶지 않는다.

이해 확인: targetTime을 원본 삭제 직후로 정하면 어떤 결과일까? 삭제도 정상 변경으로 재생되므로 행이 없는 상태로 복원될 수 있다. 복구 목표를 데이터 사건과 연결해야 한다.