Lv.3 중급PostgreSQL

2026.05.1428분 읽기Lv.3 중급

시리즈PostgreSQL 백업/복구 완전 정복 · 파트 5/6시리즈 허브 보기

PostgreSQL 백업/복구 Part 5 — 엔터프라이즈 백업 도구 비교: pgBackRest vs Barman vs WAL-G

Pg_basebackup과 WAL 아카이빙은 대용량 프로덕션에서 병렬 처리, 보존 정책, 암호화, 카탈로그, 클라우드 연동이 부족하다. pgBackRest는 블록 수준 증분 백업과 델타 복구로 500GB 이상 대형 OLTP에, Barman은 전용 서버 중앙 관리로 다수 인스턴스 운영 조직에, WAL-G는 오브젝트 스토리지 직접 연동으로 Kubernetes와 클라우드 네이티브 환경에 각각 강점을 발휘하며, 도구 선택의 출발점은 기능표가 아닌 RPO/RTO·3-2-1 원칙·복구 훈련으로 구성된 백업 전략이다.

시리즈 구성

• Part 1 — 백업의 기초와 전략
• Part 2 — 논리적 백업 — pg_dump & pg_dumpall 실전 활용
• Part 3 — 물리적 백업 — pg_basebackup과 WAL 아카이빙
• Part 4 — PITR(Point-in-Time Recovery) 구현 가이드
• Part 5 — 엔터프라이즈 백업 도구 비교 — pgBackRest vs Barman vs WAL-G (현재 편)
• Part 6 — 백업 자동화 & 모니터링, 그리고 복구 훈련 (연재 예정)

목차

1. 들어가며 — 내장 도구의 한계
2. 세 도구 한눈에 보기
3. pgBackRest — 고성능 프로덕션의 사실상 표준
4. Barman — 다중 서버 중앙 관리의 강자
5. WAL-G — 클라우드 네이티브 백업의 선택
6. 심층 비교 — 결정적 차이점 4가지
7. 상황별 도구 선택 가이드
8. 실전 설정 비교 — PITR 복구 명령 한눈에 보기
9. 공통 권장 사항 — 어떤 도구를 쓰든 반드시 지킬 것
10. 마치며 — 도구보다 중요한 것은 전략

1. 들어가며 — 내장 도구의 한계

Part 3과 Part 4에서 pg_basebackup과 WAL 아카이빙으로 PITR을 구성하는 방법을 배웠다. 이 조합은 훌륭하지만, 프로덕션 규모가 커질수록 금세 한계에 부딪힌다.

pg_basebackup의 현실적인 한계

- 병렬 처리 없음 → 수백 GB 이상에서 백업 시간이 지나치게 길어짐
- 증분/차등 백업 없음 (v17의 네이티브 증분은 아직 초기 단계)
- 보존 정책(Retention Policy) 관리 없음
- 암호화 없음
- 다수 서버 중앙 관리 불가
- 백업 카탈로그/이력 관리 없음
- 클라우드 오브젝트 스토리지 직접 지원 없음

이 간극을 채우는 것이 바로 서드파티 엔터프라이즈 백업 도구들이다. 2026년 현재 PostgreSQL 생태계에서 가장 널리 쓰이는 세 가지 — pgBackRest, Barman, WAL-G — 를 이 파트에서 심층 비교한다.

2. 세 도구 한눈에 보기

3. pgBackRest — 고성능 프로덕션의 사실상 표준

3.1 개요

pgBackRest는 2026년 현재 프로덕션 PostgreSQL 백업의 사실상(de facto) 표준으로 자리 잡았다. C로 작성되어 성능이 뛰어나며, 멀티 테라바이트 규모의 데이터베이스에서도 안정적으로 동작한다. Percona Distribution for PostgreSQL에도 기본 포함되어 있다.

3.2 핵심 특징

블록 수준 증분 백업(Block Incremental) 이 pgBackRest를 경쟁 도구와 가장 크게 차별화하는 기능이다. 파일 전체가 아닌 변경된 블록만 백업하기 때문에 대형 DB에서 백업 크기와 시간을 극적으로 줄일 수 있다. --delta 옵션으로 복구 시에도 변경된 블록만 덮어쓰므로 복구 속도도 빠르다.

Stanza 개념으로 각 PostgreSQL 클러스터를 독립적으로 관리하며, 하나의 pgBackRest 설정으로 여러 클러스터를 관리할 수 있다.

다중 저장소(Multi-Repository) 를 지원하여 로컬 디스크와 S3에 동시에 백업하는 3-2-1 전략을 단일 도구로 구현할 수 있다.

3.3 설치 및 기본 설정

# Ubuntu/Debian
sudo apt install pgbackrest

# RHEL/CentOS
sudo dnf install pgbackrest

# /etc/pgbackrest/pgbackrest.conf

[global]
# 백업 저장 경로 (로컬)
repo1-path=/var/lib/pgbackrest

# S3 저장소 (선택: 다중 저장소 구성 시)
repo2-type=s3
repo2-s3-bucket=my-pg-backups
repo2-s3-region=ap-northeast-2
repo2-s3-key=AKIAIOSFODNN7EXAMPLE
repo2-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
repo2-s3-endpoint=s3.amazonaws.com
repo2-path=/pgbackrest

# 보존 정책
repo1-retention-full=4          # 전체 백업 4개 보존
repo1-retention-diff=14         # 차등 백업 14개 보존

# 압축 방식 (zstd 권장: 속도와 압축률의 균형)
compress-type=zstd
compress-level=3

# 암호화
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=MyStrongEncryptionPassphrase

# 병렬 프로세스 수 (CPU 코어 수의 절반 권장)
process-max=4

# 로깅
log-level-console=info
log-level-file=detail
log-path=/var/log/pgbackrest

[main]                          # stanza 이름
pg1-path=/var/lib/postgresql/17/main
pg1-user=postgres
pg1-port=5432

# postgresql.conf에 추가
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
wal_level = replica

보안 주의: pgbackrest.conf에 S3 자격증명을 평문으로 저장하지 말고, 가능하면 EC2 IAM Role이나 환경 변수 방식을 사용하라.

3.4 핵심 명령어

# stanza 초기화 (최초 1회)
sudo -u postgres pgbackrest --stanza=main stanza-create

# 설정 검증
sudo -u postgres pgbackrest --stanza=main check

# 전체 백업
sudo -u postgres pgbackrest --stanza=main --type=full backup

# 차등 백업 (마지막 전체 백업 이후 변경분)
sudo -u postgres pgbackrest --stanza=main --type=diff backup

# 증분 백업 (마지막 백업 이후 변경분)
sudo -u postgres pgbackrest --stanza=main --type=incr backup

# 백업 목록 확인
sudo -u postgres pgbackrest --stanza=main info

# 최신 백업으로 복구
sudo -u postgres pgbackrest --stanza=main restore

# 특정 시각으로 PITR 복구
sudo -u postgres pgbackrest --stanza=main restore \
  --type=time \
  --target="2026-04-14 14:34:59+09" \
  --target-action=promote

# 델타 복구 (변경된 파일만 복원 → 빠름)
sudo -u postgres pgbackrest --stanza=main restore --delta

# WAL 아카이브 검증
sudo -u postgres pgbackrest --stanza=main check \
  --archive-timeout=60

3.5 백업 스케줄 전략 예시

# crontab -u postgres -e

# 매주 일요일 새벽 1시: 전체 백업
0 1 * * 0 pgbackrest --stanza=main --type=full backup

# 매일 새벽 1시 (일요일 제외): 차등 백업
0 1 * * 1-6 pgbackrest --stanza=main --type=diff backup

# 매시간 정각: 증분 백업
0 * * * * pgbackrest --stanza=main --type=incr backup

3.6 적합한 환경

• DB 크기 500GB 이상의 대형 프로덕션 환경
• 블록 수준 증분 백업으로 RPO를 최소화해야 하는 미션 크리티컬 시스템
• 온프레미스 + 클라우드 하이브리드 저장소 구성
• Percona, Crunchy Data 등 PostgreSQL 전문 지원 체계와 연동

4. Barman — 다중 서버 중앙 관리의 강자

4.1 개요

Barman(Backup and Recovery Manager)은 EnterpriseDB(EDB)가 개발·관리하는 Python 기반 백업 도구다. 가장 큰 특징은 전용 백업 서버에서 여러 PostgreSQL 인스턴스를 중앙에서 관리한다는 점이다. 다수의 DB 서버를 운영하는 엔터프라이즈 환경에서 강점을 발휘한다.

4.2 핵심 특징

중앙 집중형 아키텍처: 별도의 Barman 서버가 모든 PostgreSQL 서버의 백업을 수집·관리한다. DBA 팀이 단일 지점에서 전체 인프라의 백업 상태를 모니터링하고 제어할 수 있다.

Streaming-Only 방식: Barman 2.0 이후 pg_basebackup과 pg_receivewal을 이용한 스트리밍 방식이 기본 권장 설정이다. SSH 없이도 동작하며, pg_receivewal은 WAL 세그먼트가 완성되기 전에도 실시간으로 WAL을 전송하므로 WAL 손실 위험이 줄어든다.

barman check 명령: 백업 환경의 전체 상태를 한 번에 점검할 수 있는 헬스체크 명령이 내장되어 있어 운영 편의성이 높다.

4.3 아키텍처 구성

4.4 설치 및 기본 설정

# Barman 서버에 설치
sudo apt install barman barman-cli

# PostgreSQL 서버에 클라이언트 설치
sudo apt install barman-cli

# Barman 서버: /etc/barman.conf (글로벌 설정)
[barman]
barman_user = barman
barman_home = /var/lib/barman
log_file = /var/log/barman/barman.log
log_level = INFO
compression = gzip

# /etc/barman.d/pg-primary.conf (서버별 설정)
[pg-primary]
description = "Primary PostgreSQL Server"

# PostgreSQL 접속 정보
conninfo = host=pg-primary user=barman dbname=postgres

# 스트리밍 복제 접속 정보
streaming_conninfo = host=pg-primary user=streaming_barman

# 스트리밍 방식 설정
backup_method = postgres      # pg_basebackup 사용
streaming_archiver = on       # pg_receivewal로 WAL 스트리밍
slot_name = barman            # 복제 슬롯 이름
create_slot = auto            # 슬롯 자동 생성

# 보존 정책
retention_policy = RECOVERY WINDOW OF 7 DAYS
minimum_redundancy = 1

# 압축
compression = gzip

-- PostgreSQL 서버에서 Barman 전용 사용자 생성
CREATE USER barman WITH SUPERUSER PASSWORD 'barman_pass';
CREATE USER streaming_barman WITH REPLICATION PASSWORD 'streaming_pass';

4.5 핵심 명령어

# 서버 상태 전체 점검 (헬스체크)
barman check pg-primary
# 출력 예:
# Server pg-primary:
#   PostgreSQL: OK
#   is_superuser: OK
#   streaming replication: OK
#   wal_level: OK
#   replication slot: OK
#   archive_mode: OK
#   continuous archiving: OK

# 백업 실행
barman backup pg-primary

# 백업 목록 확인
barman list-backup pg-primary

# 백업 상세 정보
barman show-backup pg-primary latest

# 특정 시각으로 PITR 복구
barman recover pg-primary latest \
  /var/lib/postgresql/17/main \
  --target-time "2026-04-14 14:34:59" \
  --remote-ssh-command "ssh postgres@pg-primary"

# 특정 트랜잭션 ID로 복구
barman recover pg-primary latest \
  /var/lib/postgresql/17/main \
  --target-xid 1234567 \
  --remote-ssh-command "ssh postgres@pg-primary"

# 백업 삭제
barman delete pg-primary 20260414T010000

# WAL 아카이브 정리 (보존 정책 적용)
barman cron

4.6 적합한 환경

• 다수의 PostgreSQL 서버(5개 이상)를 단일 백업 서버에서 중앙 관리해야 하는 환경
• DBA 팀이 있고 엔터프라이즈 수준의 컴플라이언스 요구사항이 있는 조직
• 전통적인 온프레미스 또는 하이브리드 인프라
• EDB의 상용 지원이 필요한 환경

5. WAL-G — 클라우드 네이티브 백업의 선택

5.1 개요

WAL-G는 Go로 작성된 클라우드 퍼스트(Cloud-First) 백업 도구다. Citus Data(현 Microsoft)에서 개발했으며, WAL-E의 후계자다. AWS S3, GCS, Azure Blob Storage 등 오브젝트 스토리지에 백업을 직접 전송하는 데 최적화되어 있다.

설정이 비교적 단순하고, PostgreSQL 외에 MySQL, MongoDB, Redis도 지원하는 멀티 데이터베이스 환경에 특히 강점이 있다. Kubernetes와 컨테이너 환경에서 널리 사용되며, Zalando Postgres Operator 등 여러 Kubernetes PostgreSQL Operator가 WAL-G를 기본 백업 도구로 채택하고 있다.

5.2 핵심 특징

클라우드 직접 아카이빙: archive_command를 wal-g wal-push %p로 설정하면 WAL 파일이 별도 서버를 거치지 않고 오브젝트 스토리지로 직접 전송된다. 백업 서버를 별도로 유지할 필요가 없다.

델타 백업(Delta Backup): WALG_DELTA_MAX_STEPS 환경 변수로 전체 백업과 델타 백업의 비율을 제어할 수 있다. 델타 백업은 변경된 파일 단위로 저장되어 스토리지를 절약한다.

병렬 압축/업로드: 멀티코어를 활용한 병렬 압축 및 S3 멀티파트 업로드를 지원하여 대용량 백업도 빠르게 처리한다.

5.3 설치 및 기본 설정

# GitHub Releases에서 최신 바이너리 다운로드
WAL_G_VERSION="v3.0.8"
curl -L "https://github.com/wal-g/wal-g/releases/download/${WAL_G_VERSION}/wal-g-pg-ubuntu-20.04-amd64.tar.gz" \
  -o /tmp/wal-g.tar.gz
tar -xzf /tmp/wal-g.tar.gz -C /usr/local/bin/
chmod +x /usr/local/bin/wal-g

# 환경 변수 설정 파일 (envdir 방식 권장)
mkdir -p /etc/wal-g.d/env

# AWS S3 설정
echo "s3://my-pg-backups/wal-g"  > /etc/wal-g.d/env/WALG_S3_PREFIX
echo "ap-northeast-2"             > /etc/wal-g.d/env/AWS_REGION
echo "AKIAIOSFODNN7EXAMPLE"        > /etc/wal-g.d/env/AWS_ACCESS_KEY_ID
echo "wJalrXUtnFEMI..."            > /etc/wal-g.d/env/AWS_SECRET_ACCESS_KEY

# 압축 방식 (zstd 또는 brotli 권장)
echo "zstd"                        > /etc/wal-g.d/env/WALG_COMPRESSION_METHOD

# 델타 백업 최대 단계 수 (전체 백업 사이에 허용할 델타 백업 수)
echo "5"                           > /etc/wal-g.d/env/WALG_DELTA_MAX_STEPS

# 병렬 업로드/다운로드 수
echo "4"                           > /etc/wal-g.d/env/WALG_UPLOAD_CONCURRENCY
echo "4"                           > /etc/wal-g.d/env/WALG_DOWNLOAD_CONCURRENCY

# PGDATA 경로
echo "/var/lib/postgresql/17/main" > /etc/wal-g.d/env/PGDATA

chown -R postgres:postgres /etc/wal-g.d/env
chmod 600 /etc/wal-g.d/env/*

# postgresql.conf에 추가
archive_mode = on
archive_command = 'envdir /etc/wal-g.d/env wal-g wal-push %p'
wal_level = replica

5.4 핵심 명령어

# 전체 베이스 백업 (S3로 직접 전송)
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-push /var/lib/postgresql/17/main

# 델타 백업 (변경된 파일만)
# WALG_DELTA_MAX_STEPS가 설정되어 있어야 유효하게 동작함
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-push --full=false /var/lib/postgresql/17/main

# 백업 목록 확인
sudo -u postgres envdir /etc/wal-g.d/env wal-g backup-list

# 최신 백업으로 복구
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-fetch /var/lib/postgresql/17/main LATEST

# 특정 백업 이름으로 복구
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-fetch /var/lib/postgresql/17/main base_20260414T010000Z

# 보존 정책 적용 (최근 7개 전체 백업 유지)
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g delete retain FULL 7 --confirm

# WAL 아카이브 무결성 검증
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g wal-verify integrity timeline

# postgresql.conf: 복구 설정 (PITR)
restore_command = 'envdir /etc/wal-g.d/env wal-g wal-fetch %f %p'
recovery_target_time = '2026-04-14 14:34:59 Asia/Seoul'
recovery_target_action = 'pause'

5.5 적합한 환경

• Kubernetes, 컨테이너 기반 PostgreSQL 운영 환경
• AWS, GCP, Azure 등 퍼블릭 클라우드 네이티브 인프라
• PostgreSQL 외 MySQL, MongoDB 등 혼합 DB 스택을 운영하는 팀
• 별도 백업 서버 없이 오브젝트 스토리지만으로 백업 체계를 구성하려는 팀
• 설정 단순성을 선호하는 소규모~중규모 DevOps 팀

6. 심층 비교 — 결정적 차이점 4가지

6.1 백업 방식: 블록 수준 vs 파일 수준

가장 기술적으로 중요한 차이다.

pgBackRest (블록 수준 증분)
  전체 백업: 1TB
  증분 백업: 변경된 8KB 블록만 → 수 GB 수준 가능

Barman / WAL-G (파일 수준 증분)
  전체 백업: 1TB
  증분 백업: 변경된 파일 전체 → 파일이 크면 이득 제한적

테이블 하나에 변경이 집중되는 패턴(OLTP 환경의 대형 테이블)이라면 pgBackRest의 블록 수준 증분이 압도적으로 유리하다.

6.2 복구 속도 (델타 복구)

pgBackRest의 --delta 옵션은 현재 데이터 디렉토리와 백업을 비교하여 변경된 파일/블록만 복원한다. 대부분의 파일이 손상되지 않은 경우(예: 논리적 오류, 특정 테이블 오염), 전체 복원보다 훨씬 빠르게 복구할 수 있다.

6.3 아키텍처: 중앙집중 vs 분산

Barman: 전용 백업 서버가 중앙 모니터링과 통합 정책을 제공하지만, 백업 서버 자체가 단일 장애점이 될 수 있다.

pgBackRest: 더 유연한 토폴로지를 지원하지만, 다중 서버 관리 시 설정이 복잡해진다.

WAL-G: 인프라가 가장 단순하고 서버리스에 가까운 구성이지만, 서버 간 통합 모니터링이 어렵다.

6.4 운영 복잡도 vs 기능

낮음 <------------------------------------> 높음
WAL-G          Barman          pgBackRest
(설정 단순)     (중간)           (기능 풍부, 설정 복잡)

팀의 PostgreSQL 전문성과 운영 역량에 따라 현실적인 선택이 달라진다. 기능이 풍부해도 제대로 운영하지 못하면 오히려 위험하다.

7. 상황별 도구 선택 가이드

DB 크기 < 100GB, 팀 규모 소/중, 클라우드 환경
  -> WAL-G (설정 단순, S3 직접 연동)

DB 크기 100GB~1TB, 단일 서버, PITR 필수
  -> pgBackRest (성능, 기능 균형)

DB 크기 > 1TB, OLTP, RPO 최소화
  -> pgBackRest + 블록 수준 증분 백업

PostgreSQL 서버 5대 이상, 중앙 관리 필요
  -> Barman (중앙 집중형 관리 최적)

Kubernetes / 컨테이너 환경
  -> WAL-G (Zalando Operator 등과 네이티브 통합)

멀티 DB 스택 (PostgreSQL + MySQL 등)
  -> WAL-G (다중 DB 지원)

엔터프라이즈 컴플라이언스, EDB 지원 필요
  -> Barman

8. 실전 설정 비교 — PITR 복구 명령 한눈에 보기

세 도구 모두 PITR을 지원하지만 명령 구조가 다르다. 비상 시 혼동 없도록 미리 숙지해두자.

# pgBackRest: 특정 시각으로 PITR
sudo -u postgres pgbackrest --stanza=main restore \
  --type=time \
  --target="2026-04-14 14:34:59+09" \
  --target-action=promote \
  --delta   # 델타 복구로 속도 향상

# Barman: 특정 시각으로 PITR (원격 SSH 필요)
sudo -u barman barman recover pg-primary latest \
  /var/lib/postgresql/17/main \
  --target-time "2026-04-14 14:34:59" \
  --remote-ssh-command "ssh postgres@pg-primary"

# WAL-G: 베이스 백업 복원 후 postgresql.conf에 파라미터 설정
sudo -u postgres envdir /etc/wal-g.d/env \
  wal-g backup-fetch /var/lib/postgresql/17/main LATEST

# 그 후 postgresql.auto.conf에 추가:
# restore_command = 'envdir /etc/wal-g.d/env wal-g wal-fetch %f %p'
# recovery_target_time = '2026-04-14 14:34:59 Asia/Seoul'
# recovery_target_action = 'promote'
# touch recovery.signal -> pg 재시작

9. 공통 권장 사항 — 어떤 도구를 쓰든 반드시 지킬 것

어떤 도구를 선택하든 다음 원칙은 공통으로 적용된다.

① 백업 후 반드시 검증하라

# pgBackRest
pgbackrest --stanza=main verify

# WAL-G
wal-g wal-verify integrity timeline

# Barman
barman check pg-primary

② 보존 정책을 명확히 설정하라

무제한 보존은 스토리지 폭증을 초래하고, 너무 짧은 보존은 늦게 발견된 논리적 오류 복구를 불가능하게 한다. 최소 30일, 규정이 있다면 규정에 따라 설정한다.

③ 정기적으로 실제 복구를 훈련하라

도구가 아무리 훌륭해도, 팀이 복구 절차에 익숙하지 않으면 장애 상황에서 실수가 발생한다. 분기 1회 이상의 복구 훈련을 스케줄에 고정하라.

④ 백업 모니터링에 알림을 붙여라

백업이 실패해도 아무도 모르는 상황이 가장 위험하다. Slack, 이메일, PagerDuty 등 팀이 실제로 확인하는 채널로 백업 성공/실패 알림을 설정하라.

10. 마치며 — 도구보다 중요한 것은 전략

pgBackRest, Barman, WAL-G 모두 훌륭한 도구다. 어느 것을 선택하더라도 올바르게 설정하고 운영하면 안정적인 백업 체계를 구축할 수 있다.

하지만 도구 선택 자체보다 더 중요한 것이 있다.

"백업 도구는 전략의 실행 수단이다. 도구가 전략을 대신할 수는 없다."

RPO/RTO 목표를 정의하고, 3-2-1 원칙을 지키고, 정기적으로 복구를 검증하는 백업 전략이 먼저다. 도구는 그 다음이다.

다음 파트에서는 지금까지 배운 모든 내용을 종합하여 백업 자동화, 모니터링 체계 구축, 그리고 복구 훈련 계획을 수립하는 방법으로 시리즈를 마무리한다.

참고 자료

• pgBackRest 공식 문서
• Barman 공식 문서 (v3.18)
• WAL-G GitHub
• Top Open-Source Postgres Backup Solutions in 2026 — Bytebase (Jan 2026)
• PostgreSQL Backup Tools Comparison — DEV Community (Jan 2026)
• Automating Backups and DR: pgBackRest vs Barman — Severalnines (Nov 2025)
• Best PostgreSQL Backup Solutions in 2026 — PostgresGUI (Feb 2026)
• pgBackRest File Bundling and Block Incremental Backup — Crunchy Data
• PostgreSQL Backup and Recovery Management using Barman — Stormatics (Feb 2026)