Lv.2 초급PostgreSQL

2026.05.0915분 읽기Lv.2 초급

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

PostgreSQL 백업/복구 Part 1 — 백업의 기초와 전략

크론잡이 돌고 파일이 쌓여도 복구 테스트를 통과하지 못하면 백업이 있다고 말하기 어렵다. PostgreSQL에는 근본적으로 다른 세 가지 백업 방식이 존재한다. 논리적 백업(pg_dump, pg_dumpall)은 이식성과 선택적 복구에 강하고, 물리적 백업(pg_basebackup)은 클러스터 전체 재해 복구에 최적이며, WAL 아카이빙은 RPO를 수 초 수준까지 낮춘다. 어떤 방식을 선택할지는 도구 자체가 아닌 RPO와 RTO에서 역산해야 한다. Part 1에서는 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. PostgreSQL 백업의 세 가지 방식
3. RPO & RTO — 백업 전략의 출발점
4. 백업의 3-2-1 원칙
5. 2026년 현재 PostgreSQL 백업 생태계
6. 가장 흔한 백업 실수 5가지
7. 어떤 백업 방식을 선택해야 하는가
8. 마치며 — 복구 가능성이 곧 백업이다

1. 들어가며 — "백업이 있다"는 착각

많은 팀이 이런 상황을 경험한다.

"크론잡이 돌고 있고, 파일도 생기고, 대시보드도 초록불이야. 백업 있지."

하지만 실제 장애가 발생했을 때 복구에 성공하는 팀과 실패하는 팀의 차이는 백업 파일의 존재 여부가 아니라, 복구 절차의 검증 여부에 있다.

PostgreSQL 공식 문서도 이 점을 명확히 짚는다.

백업은 정기적으로 수행되어야 하며, 절차는 본질적으로 단순하지만 기반 기술과 가정에 대한 명확한 이해가 중요하다. — postgresql.org/docs/current/backup

2026년 현재, PostgreSQL은 SaaS 플랫폼, 분석 파이프라인, 고가용성 데이터베이스의 근간을 이루는 시스템이 됐다. 그만큼 백업 실패의 비용도 기하급수적으로 커졌다. Part 1에서는 백업을 단순한 파일 보유가 아닌 검증된 복구 가능성으로 재정의하고, 전략을 세우기 위한 전체 지도를 그린다.

2. PostgreSQL 백업의 세 가지 방식

PostgreSQL에는 근본적으로 다른 세 가지 백업 방식이 존재한다. 각각은 서로 다른 문제를 해결하며, 어느 하나만으로 모든 상황을 커버할 수 없다.

2.1 논리적 백업 (Logical Backup)

데이터를 SQL 구문 형태로 추출하는 방식이다. pg_dump와 pg_dumpall이 대표 도구다.

핵심 특징

• 특정 테이블, 스키마 단위의 선택적 백업/복구 가능
• 다른 PostgreSQL 버전 간 이식성이 뛰어남 (낮은 버전 → 높은 버전 복구 가능)
• 대용량 데이터베이스에서는 속도가 느림
• 전체 클러스터 복구(roles, tablespaces 포함)에는 부적합

# 단일 데이터베이스 백업 (custom 형식 — 병렬 복구 가능)
pg_dump -U postgres -d mydb -Fc -f mydb.dump

# 전체 클러스터 (roles, tablespaces 포함)
pg_dumpall -U postgres > full_cluster.sql

2.2 물리적 백업 (Physical Backup)

PostgreSQL 데이터 디렉터리 전체를 파일 시스템 수준에서 복사하는 방식이다. pg_basebackup이 기본 도구다.

핵심 특징

• 대용량 데이터베이스에서도 속도가 빠름
• 클러스터 전체 복구에 최적 (재해 복구 시나리오)
• PITR(Point-in-Time Recovery)의 필수 기반
• 단일 테이블/객체 선택 복구는 불가능
• 동일 PostgreSQL 메이저 버전 내에서만 사용 가능

# 기본 물리 백업 (-R: recovery.conf 자동 생성, -P: 진행률 표시)
pg_basebackup -h localhost -U replicator \
  -D /backups/basebackup \
  -Fp -Xs -P -R

2.3 연속 아카이빙 (Continuous Archiving / WAL Archiving)

WAL(Write-Ahead Log) 파일을 지속적으로 아카이빙해 특정 시점으로 복구하는 방식이다. PITR의 핵심 메커니즘이다.

핵심 특징

• 백업 스케줄과 무관하게 임의 시점으로 복구 가능
• RPO를 수 초 수준까지 줄일 수 있음
• 물리 백업(Base Backup)과 함께 사용해야 효과적
• 구성 및 운영 복잡도가 높음

# postgresql.conf — WAL 아카이빙 활성화
archive_mode = on
archive_command = 'cp %p /mnt/wal-archive/%f'
# 클라우드 환경이라면:
# archive_command = 'wal-g wal-push %p'

방식별 비교 요약

3. RPO & RTO — 백업 전략의 출발점

도구를 고르기 전에 반드시 정의해야 할 두 가지 개념이 있다.

이 두 목표가 백업 방식, 빈도, 도구 선택을 결정한다. 도구 선택이 먼저가 아니라, RPO/RTO에서 역산하는 것이 올바른 순서다.

RPO가 24시간이라면?  → 일별 pg_dump로 충분
RPO가 1시간이라면?   → 시간별 백업 또는 WAL 아카이빙 필요
RPO가 수 초라면?     → 연속 WAL 아카이빙 (PITR) 필수

레플리카는 백업이 아니다. 레플리카는 가용성을 높이지만, 주 서버에서 데이터를 잘못 삭제하면 그 작업이 레플리카에도 즉시 복제된다. RPO 관점에서 레플리카는 백업 대체재가 될 수 없다.

4. 백업의 3-2-1 원칙

프로덕션 PostgreSQL 환경에서 업계 표준으로 자리 잡은 백업 보관 원칙이다.

실제 적용 예

• 프로덕션 DB (원본)
• 로컬 NAS 또는 별도 서버 (물리적 분리)
• AWS S3 / GCS / Azure Blob (지역적 분리)

이 원칙은 하드웨어 장애, 우발적 삭제, 화재·홍수와 같은 물리적 재해까지 모두 커버한다. 세 조건을 모두 충족하지 않는 백업 구성은 특정 장애 시나리오에서 전부 소실될 수 있다.

5. 2026년 현재 PostgreSQL 백업 생태계

PostgreSQL 18과 장기 운영 현장에서 여전히 널리 쓰이는 17 기준으로 백업 도구 생태계는 크게 성숙했다.

내장 도구

주요 오픈소스 서드파티 도구

각 도구는 "항상 최선"인 선택지가 없다. 데이터 규모, RPO/RTO 목표, 클라우드/온프레미스 환경, 운영 인력 수준에 따라 조건부로 선택한다.

6. 가장 흔한 백업 실수 5가지

❌ 실수 1: 복구 테스트를 한 번도 해본 적 없다

백업 파일이 있어도 복구에 실패한다면 백업이 없는 것과 같다. 정기적인 복구 테스트는 백업 과정의 일부여야 하며, 장애가 났을 때의 "나중"이 되어서는 안 된다. 분기 1회 이상의 전체 복구 드릴을 루틴으로 포함시켜야 한다.

❌ 실수 2: 레플리카를 백업으로 착각한다

레플리카는 가용성을 높이지만 백업을 대체하지 못한다. 주 서버에서 데이터를 실수로 삭제하면 그 삭제 작업이 레플리카에도 즉시 복제된다. 레플리카와 백업은 역할이 다르다.

❌ 실수 3: pg_dump만으로 충분하다고 생각한다

pg_dump는 단일 데이터베이스의 논리적 스냅샷만 뜬다. 클러스터 수준의 설정(roles, tablespaces 등)은 포함되지 않는다. 전체 클러스터 복구가 필요한 재해 복구 시나리오에서는 pg_dumpall 또는 물리적 백업이 필요하다.

❌ 실수 4: 백업 모니터링을 하지 않는다

크론잡이 실패했는지, WAL 아카이빙이 지연되고 있는지 알림 없이는 알 수 없다. 백업 프로세스에는 반드시 성공/실패 모니터링이 따라야 한다. 장애 시점에야 백업이 며칠째 실패했다는 사실을 알게 되는 것이 가장 흔한 패턴이다.

❌ 실수 5: 보관 정책(Retention Policy)이 없다

오래된 백업을 무기한 보관하면 스토리지 비용이 폭증하고, 반대로 너무 짧게 보관하면 늦게 발견된 논리적 오류를 복구하지 못한다. 명확한 보관 주기(예: 일별 백업 30일, 주별 백업 3개월, 월별 백업 1년)를 정책으로 수립해야 한다.

7. 어떤 백업 방식을 선택해야 하는가

RPO/RTO 목표와 운영 환경에 따른 선택 흐름이다.

실전에서는 단일 도구보다 논리 + 물리 백업의 병행이 권장된다.

• 물리 백업 → 빠른 전체 복구 (재해 복구 시나리오)
• 논리 백업 → 이식성과 선택적 복구 (테이블 단위, 버전 간 이전)

두 방식은 서로 다른 문제를 해결하기 때문에 이중화하면 커버 범위가 넓어진다.

8. 마치며 — 복구 가능성이 곧 백업이다

"백업의 목적은 복사본을 만드는 것이 아니라, 장애 시점에 원하는 데이터 상태로 예측 가능한 시간 안에 돌아가는 것이다."

백업 전략은 도구 선택이 아닌 복구 시나리오의 정의에서 시작한다. RPO와 RTO를 먼저 정의하고, 3-2-1 원칙으로 보관 구조를 설계하고, 모니터링과 보관 정책으로 지속 가능하게 운영하며, 정기 복구 테스트로 전략을 검증한다. 이 네 요소가 함께 갖춰졌을 때 비로소 "백업이 있다"고 말할 수 있다.

다음 편(Part 2)에서는 가장 많이 쓰이는 pg_dump와 pg_dumpall의 실전 활용법을 포맷 선택부터 자동화까지 상세히 다룬다.

참고 자료

• PostgreSQL 공식 문서 — Chapter 25: Backup and Restore
• pgBackRest User Guide
• Barman Documentation
• WAL-G GitHub