pgBackRest를 이용한 백업과 PITR

pgBackRest를 이용한 전체 / 차등 / 증분 백업, 연속 WAL 아카이브, 시점 복구(PITR). 단일 서버, 스트리밍 복제(primary + standby) 또는 Patroni 클러스터를 대상으로 하며, 리포지토리는 같은 서버, 별도 백업 서버(SSH) 또는 S3 호환 object storage에 둘 수 있습니다. 암호화, 압축, 보존 정책, cron/systemd 스케줄링, 별도 디렉터리로의 테스트 restore를 포함하며, 같은 가이드가 장애 시 제자리 restore 런북도 생성합니다(Patroni 클러스터를 백업에서 재구축하는 절차 포함). 다른 가이드와의 차이: 운영 환경에 권장되는 물리 백업 도구입니다. 별도 도구 없이 물리 백업과 PITR을 하려면 pg_basebackup + WAL 아카이브 가이드를, 논리 백업(테이블/데이터베이스 덤프, 메이저 버전 간 이전)에는 pg_dump / pg_restore 가이드를 사용합니다.

구성: 서버 1대, primary + standby 또는 Patroni 클러스터, 선택적으로 백업 서버

시나리오

• pgBackRest 설치 + 첫 백업 + 테스트 restore — pgBackRest가 아직 없는 경우: 소프트웨어, 리포지토리, WAL 아카이브, 첫 백업, 스케줄링, 테스트 restore.
• 장애 시: 제자리 restore (최신 상태 또는 특정 시점으로) — 데이터베이스를 제자리에서, 백업과 아카이브가 포함하는 시점으로 되돌립니다: 최신 시점, 특정 시각, xid, LSN 또는 restore point. 클러스터가 중지되며, 대상 시점 이후의 변경은 사라집니다.
• 데이터 디렉터리의 파일 손상 또는 삭제 (delta restore로 복구) — 서버는 정상이지만 일부 데이터 파일을 읽을 수 없거나 삭제된 경우: --delta는 백업과 다른 파일만 다시 쓰고 아카이브의 끝까지 재생합니다. 클러스터가 중지됩니다.
• 데이터베이스 하나만 복원 (--db-include) — 클러스터는 계속 운영됩니다: 데이터베이스 하나를 임시 인스턴스(별도 디렉터리와 포트)로 restore한 뒤 pg_dump로 덤프하여 운영 서버에 새 이름으로 적재합니다. 삭제된 테이블 하나를 되살릴 때도 이 카드를 사용합니다(거기서 pg_dump -t).
• 백업을 다른 서버에 복원 (복제본 / 테스트 / 리포팅) — 운영 서버는 건드리지 않습니다. 백업을 새 서버에서 엽니다. WAL 아카이브는 비활성화하여 복제본이 운영 리포지토리에 쓰지 않도록 합니다. 암호화된 리포지토리는 키가 필요합니다.
• 서버 완전 유실: 새 서버에서 백업을 열어 대체 — 디스크 또는 서버 유실: 새 서버를 백업에서 열어 새 primary로 사용하며, WAL 아카이브와 백업은 같은 stanza에서 계속됩니다. 기존 서버는 반드시 중지된 상태로 두어야 합니다.
• 백업에서 새 standby 구축 (--type=standby) — primary에 복사 부하를 주지 않는 새 standby: 파일은 백업에서 가져오고, 부족한 WAL은 아카이브와 스트리밍으로 채웁니다. primary는 계속 운영됩니다.
• 백업은 정말 온전한가? (info / check / verify와 restore 훈련) — 읽기 전용 점검과, 운영 서버를 건드리지 않는 별도 디렉터리로의 restore 훈련. 월간 검증 작업(cron)도 설정합니다.
• 보존 기간 변경과 오래된 백업 정리 (expire) — repo1-retention-full/diff 설정을 변경하고, 먼저 --dry-run으로 삭제될 대상을 보여 준 뒤 expire를 실행합니다. 삭제된 백업은 되돌릴 수 없습니다.

시작하기 전에

• PostgreSQL …이 설치되어 실행 중입니다(pg-install 가이드)…. 이 서버가 primary입니다…. 데이터 디렉터리 ….
• Patroni 클러스터 …가 실행 중입니다(Patroni 설치): Leader 하나, 나머지는 스트리밍 replica. 모든 노드에서 데이터 디렉터리는 …, Patroni 설정은 …, REST API 비밀번호는 /etc/patroni/patroni.env 파일에 있습니다.
• 다른 아카이브/백업 도구(Barman, WAL-G, 직접 작성한 archive_command)가 설정되어 있지 않아야 합니다. 있다면 먼저 제거하십시오. 두 도구가 같은 WAL을 서로 다른 곳으로 옮기면 양쪽 모두 불완전해집니다.… Patroni에서는 현재 값을 patronictl show-config 출력에서 확인할 수 있습니다.…
• 데이터베이스 크기를 알고 있습니다. 리포지토리에는 대략 (full 수 + 1) × 압축 후 크기 + WAL 아카이브 만큼의 공간이 필요합니다(zst 사용 시 대부분의 데이터베이스는 1/3–1/5로 압축됨).
• 리포지토리 디렉터리 …가 데이터베이스와 분리된 디스크/NFS 공유에 있으며 영구 마운트(fstab)되어 있습니다.
• 백업 서버에 …용으로 충분한 공간의 별도 디스크가 마운트되어 있습니다. 백업 서버는 데이터베이스와 같은 운영체제 계열입니다.
• 서버들이 서로의 이름을 해석할 수 있고(…, …), 서버 간 22/tcp(SSH)가 열려 있습니다.
• Standby(………, ……)는 primary에서 WAL을 받는 스트리밍 standby이며 primary와 같은 PGDATA 경로(…)를 사용합니다.
• Bucket …이 생성되어 있고, 이 bucket에만 읽기/쓰기/삭제 권한을 가진 액세스 키(access key + secret key)가 준비되어 있습니다. bucket에 객체를 삭제하는 lifecycle 규칙이 없습니다(보존은 pgBackRest가 관리). 서버에서 endpoint에 접근할 수 있습니다.
• 시간이 동기화되어 있습니다(NTP). PITR 대상 시각과 S3 서명은 정확한 시간에 의존합니다.
• 서버가 PGDG와 EPEL 리포지토리(또는 사내 미러)에 접근할 수 있습니다. pgBackRest의 의존성인 libssh2는 EPEL에서 제공됩니다.
• 암호화 키를 보관할 곳(비밀번호 금고 / vault)이 준비되어 있습니다. 키를 서버 외부에 보관하지 않으면 서버를 잃었을 때 백업을 열 수 없습니다.

가이드 단계

• pgBackRest 소프트웨어 설치 — PGDG 리포지토리 추가 (백업 서버) · PGDG 리포지토리 추가 (백업 서버) · EPEL 리포지토리 활성화 · pgBackRest 설치 · pgbackrest 사용자 생성 · 기존 설정 파일 제거
• 리포지토리 준비 — 리포지토리 디렉터리 생성 · 리포지토리 디렉터리 생성 · SSH 키 생성 (백업 서버) · SSH 키 생성 (데이터베이스 서버) · 백업 서버의 키 인가 · 데이터베이스 서버의 키 인가 …
• pgBackRest 설정 — 설정 파일 작성 · 설정 파일 작성 (백업 서버) · 설정 파일 작성 (데이터베이스 서버) · S3 액세스 키 입력 · 암호화 키 생성 · … 서버에 암호화 키 기록 …
• Stanza와 첫 백업 — Stanza 생성 · Stanza 생성 · 설정 검증 (check) · 첫 full 백업 수행 · 첫 full 백업 수행 · 리포지토리 상태 확인 (info) …
• 백업 스케줄링 — pgbackrest 명령 경로 확인 · 백업 스크립트 작성 · 스크립트 소유권과 권한 설정 · systemd service와 timer 생성 · 스케줄 테스트 (수동 실행) · cron 서비스 준비 …
• 검증과 복구 테스트 — WAL 아카이브 동작 확인 · 테스트 데이터 쓰기와 대상 시각 기록 · 테스트 restore 디렉터리 준비 · 대상 시각까지 별도 디렉터리로 restore · 테스트 클러스터를 별도 포트로 기동 · 복구된 데이터 확인 …
• 모니터링과 유지보수 — 리포지토리 무결성 검증 (verify) · 리포지토리 무결성 검증 (verify) · 마지막 백업 경과 시간 모니터링 · 마지막 백업 경과 시간 모니터링 · 두 번째 사본과 키 보관
• 진단: 손상된 파일인가, 없어진 파일인가? — 로그에서 오류와 해당 파일 찾기 · 손상된 객체 식별 · 온전한 백업과 아카이브가 있는지 확인
• restore 전 점검 — 백업 목록 확인 · 애플리케이션 연결 확인 · Standby 중지 · PostgreSQL 중지 · 현재 데이터 디렉터리 복사 (공간이 있으면)
• 제자리 restore — Restore (--delta) · PostgreSQL 기동과 recovery 완료 대기 · 대상 시점의 데이터 확인 (pause) · Recovery 종료와 promote
• 검증 — restore 설정 정리 · 클러스터 상태 확인 · 애플리케이션 데이터 확인 · 손상 해소 확인 (amcheck) · 아카이브 지속 확인 · 새 full 백업 수행 …
• restore 전: Patroni 클러스터 중지 — 백업 목록 확인 · 클러스터 상태와 동적 설정 저장 · 애플리케이션 중지 · Replica에서 Patroni 중지 · Leader에서 Patroni 중지 · 현재 데이터 디렉터리 복사 (공간이 있으면)
• 검증과 정리 (Patroni) — 아카이브 지속 확인 · 새 full 백업 수행 · 클러스터와 애플리케이션 접근 확인 · 옮겨 둔 데이터 디렉터리 삭제
• Patroni: 손상된 노드 재구축 (reinit) — 손상이 있는 노드 찾기 · 손상된 노드가 leader이면 리더 역할 넘기기 · 손상된 replica 재구축 (reinit)
• 백업 검증과 restore 훈련 — 백업 상태와 마지막 백업 경과 시간 (info) · 아카이브가 지금 동작하는지 확인 (check) · 리포지토리 무결성 검증 (verify) · 훈련 디렉터리 준비 · 최신 백업을 훈련 디렉터리로 restore · 훈련 인스턴스 기동과 recovery 대기 …
• 월간 검증 스케줄 — 월간 검증 스크립트 작성 · 스크립트 권한 설정과 cron 환경으로 시험 실행 · 월간 cron 작업 작성 · cron 파일 권한 설정
• 보존 정책 변경 — 현재 보존 설정과 백업 · 보존 설정 변경 · 삭제 대상 확인 (dry-run) · 오래된 백업 삭제 (expire) · 리포지토리 사용량과 스케줄 확인