PostgreSQL 실전 강좌 #9 백업·PITR·업그레이드: 장애 직전으로 돌아가는 기술

인프라 PostgreSQL 데이터베이스
4 분 소요

마지막 편의 주제는 최악의 날을 위한 준비입니다. 기초 9편의 pg_dump는 좋은 출발점이지만 “어제 새벽 이후의 데이터는 없다"는 한계가 있었습니다. 운영 DB의 목표는 더 높습니다. 사고 직전 시점으로 돌아가기. 그 기술이 PITR이고, 재료는 지난 편에서 만난 WAL입니다.

복제는 백업이 아닙니다 #

먼저 흔한 오해부터 정리하겠습니다. “스탠바이가 있으니 백업은 됐다"는 틀립니다. 복제는 장애를 막고, 백업은 실수를 되돌립니다. DELETE FROM users를 실수로 커밋하면 그 DELETE는 밀리초 뒤 스탠바이에도 충실히 재생됩니다. 페일오버해 봤자 이미 지워진 DB가 하나 더 있을 뿐입니다. 하드웨어 장애의 답이 복제라면, 사람의 실수와 소프트웨어 버그의 답은 시간을 되감는 백업입니다. 둘 다 필요합니다.

PITR: 베이스 백업 + WAL 재생 #

원리는 지난 편의 복제와 정확히 같은 재료의 다른 사용법입니다. 스트리밍 복제가 WAL을 실시간으로 재생해 “현재의 사본"을 만든다면, PITR은 보관해 둔 WAL을 원하는 시각까지만 재생해 “과거의 사본"을 만듭니다. 필요한 것은 두 가지입니다.

PITR 구성 
# 1) 주기적 베이스 백업(실행 중에 뜰 수 있습니다. 예: 매일 새벽)
pg_basebackup -D /backup/base -Ft -z -P

# 2) postgresql.conf: WAL을 계속 보관소로 복사
archive_mode = on
archive_command = 'cp %p /backup/wal/%f'   # 실무에서는 S3 등 원격 스토리지로

복구는 “베이스 백업을 풀고, 목표 시각을 지정해 WAL을 재생"입니다.

복구 설정 
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '2026-08-31 14:29:00+09'   # 사고가 14:30이었다면 그 직전으로

이 조합이 있으면 복구 지점은 “어제 새벽"이 아니라 WAL이 남아 있는 임의의 시각이 됩니다. 사고 시각을 알아내는 것(로그, pg_stat_statements의 흔적)까지가 복구 작업의 일부입니다. 실무에서는 이 전체를 손으로 엮는 대신 pgBackRest 같은 전용 도구로 관리하는 것이 표준이고, 관리형 서비스의 “특정 시점 복원” 기능이 정확히 이 구조를 상품화한 것입니다. 그리고 기초 9편의 문장은 여기서도 유효합니다. 복원 리허설 없는 PITR 구성은 구성이 아니라 희망 사항입니다. 주기적으로 실제 복구 훈련을 돌려야 합니다.

메이저 업그레이드: 세 가지 길 #

PostgreSQL은 매년 메이저 버전이 나오고 각 버전은 5년 지원입니다. 미루면 한 번에 여러 버전을 건너야 하니, 업그레이드는 운영 캘린더의 정기 행사로 두는 것이 맞습니다. 길은 세 가지입니다.

방법중단 시간특징
pg_dump → 새 버전에 복원김(크기 비례)가장 단순, 작은 DB 전용
pg_upgrade짧음(분 단위)제자리 변환. --link 모드면 대용량도 분 단위
논리 복제초 단위새 버전 서버를 구독자로 세우고 전환. 가장 정교, 가장 손이 큼

실무 기본값은 pg_upgrade입니다. 데이터 파일 포맷의 호환성을 이용해 카탈로그만 변환하므로, 수백 GB DB도 분 단위 중단으로 끝납니다. 중단조차 어려운 서비스라면 지난 편의 논리 복제로 새 버전 서버를 나란히 세워 두고 접속만 바꾸는 방법이 남아 있습니다. 어느 길이든 공통 규율은 같습니다. 스테이징에서 같은 경로로 리허설하고, 업그레이드 직후 ANALYZE를 돌리고(통계는 이관되지 않습니다), 확장(extension)들의 호환 버전을 미리 확인하는 것입니다.

트랙을 마치며 #

이것으로 실전 9편, 기초부터 18편의 트랙이 끝났습니다. 무중단 마이그레이션에서 출발해 커넥션, 진단, 인덱스 전략, VACUUM, 잠금, 파티셔닝, 복제, 그리고 PITR까지. 돌아보면 하나의 원리가 계속 반복됐습니다. MVCC와 WAL이라는 두 기둥을 이해하면, 운영의 문제들은 그 귀결로 설명됩니다. dead tuple도, 잠금의 규칙도, 복제도, PITR도 그렇습니다. 다음에 낯선 증상을 만나면 이 두 기둥으로 돌아와 “버전은 어떻게 쌓이고, 로그는 어디로 흐르는가"를 물으세요. 이 트랙이 그 질문의 지도가 되기를 바랍니다.

정리 #

  • 복제는 장애용, 백업은 실수용입니다. DELETE 사고는 스탠바이에도 재생되므로 페일오버로 못 돌립니다.
  • PITR = 베이스 백업(pg_basebackup) + WAL 아카이빙 + 목표 시각 재생입니다. 복구 지점이 “임의의 시각"이 됩니다.
  • 실무 구성은 pgBackRest 같은 도구가 표준이고, 관리형의 특정 시점 복원이 같은 구조의 상품입니다. 리허설은 필수입니다.
  • 메이저 업그레이드의 기본값은 pg_upgrade(분 단위 중단)이고, 무중단이 필요하면 논리 복제 전환입니다. 직후 ANALYZE를 잊지 않습니다.
  • 트랙의 결론은 두 기둥입니다. MVCC와 WAL을 이해하면 운영의 문제들이 원리의 귀결로 풀립니다.
X