본문으로 건너뛰기

Barman 보존 정책

· 약 6분

정책 한 줄이 디스크와 PITR을 결정한다​

보존 정책을 잘못 설정하면 두 방향 중 하나로 사고가 납니다. 너무 좁게 설정해서 PITR을 원하는 시점이 이미 사라져 있는 경우이거나, 너무 넓게 설정해서 Barman 서버 디스크가 폭발하는 경우입니다. 둘 다 운영에서 흔히 만나는 시나리오입니다.

이 글에서는 Barman의 두 가지 보존 정책인 REDUNDANCY n과 RECOVERY WINDOW OF n DAYS를 같은 lab에서 차례로 적용하며 어떤 backup이 언제 사라지는가를 직접 확인합니다. 처음 보는 독자도 따라올 수 있게 환경을 짧게 정리합니다.

호스트역할Barman 라벨
demo-pg01PostgreSQL 17 primary—
demo-barman01Barman 3.18 서버pg01

환경 셋업이 처음이라면 2편을 먼저 보고 오는 게 빠릅니다.

두 정책 한눈에​

항목REDUNDANCY nRECOVERY WINDOW OF n DAYS
기준보유할 backup 개수보장할 PITR 기간
문법 예REDUNDANCY 5RECOVERY WINDOW OF 4 WEEKS
적합 환경backup 빈도가 고정이고 작은 클러스터backup 빈도와 무관하게 PITR 보장이 필요한 운영 환경
함정backup 빈도 변경 시 보존 기간이 달라짐사용 디스크는 backup 빈도/크기에 따라 들쭉날쭉

Barman은 운영 환경에서 RECOVERY WINDOW OF 4 WEEKS를 기본 권장합니다. 운영자가 "몇 개 보관"보다 "몇 주간 PITR 보장"으로 사고하는 게 자연스럽기 때문입니다.

WAL은 backup 정책에 종속된다​

이 원리를 모르고 보존 정책을 만지면 함정에 빠집니다. wal_retention_policy = main(기본값)일 때, Barman은 살아 있는 가장 오래된 backup의 시작점까지 WAL을 보존합니다.

즉 보존 정책이 backup 5개를 남기라고 하면, 가장 오래된 backup의 시작 LSN부터 현재까지의 WAL이 모두 보관됩니다. backup 1개가 OBSOLETE로 정리되는 순간, 그 backup이 의존하던 WAL도 같이 정리 후보가 됩니다.

이 원리 때문에 보존 정책이 넓으면 가장 오래된 backup부터 현재까지의 WAL이 모두 남아 디스크 사용량이 크게 늘 수 있습니다.

가장 오래된 보존 백업이 WAL 보존 시작점을 정하는 구조

시나리오 A: REDUNDANCY 3​

backup 5개를 떠 둔 상태에서 REDUNDANCY 3을 적용해 봅니다.

/etc/barman.d/pg01.conf:

retention_policy = REDUNDANCY 3
sudo -u barman barman cron      # 정책 적용 트리거
sudo -u barman barman list-backup pg01

기대 출력 (요약):

pg01 20260506T130005 - F - Wed May  6 13:00:35 2026 - Size: 41.5 MiB - WAL Size: 16.0 MiB - VALID
pg01 20260506T120005 - F - Wed May  6 12:00:35 2026 - Size: 41.5 MiB - WAL Size: 16.0 MiB - VALID
pg01 20260506T110005 - F - Wed May  6 11:00:35 2026 - Size: 41.5 MiB - WAL Size: 16.0 MiB - VALID

두 번째 칸의 F는 backup 유형(full)입니다. 줄 끝의 VALID가 보존 정책 평가 결과입니다. 정책 밖으로 밀려난 20260506T100005와 20260506T090005는 목록에 없습니다. retention_policy_mode = auto(기본값)에서는 barman cron이 OBSOLETE로 판정한 backup과 그에 종속된 WAL을 같은 실행 안에서 디스크에서 제거하기 때문입니다. cron을 실행하기 전에 list-backup을 보면 두 backup 줄 끝에 OBSOLETE가 붙어 있습니다.

여기에는 함정이 있습니다. backup 빈도가 시간당이라면 REDUNDANCY 3은 지난 3시간만 PITR이 가능하다는 뜻입니다. 사고가 6시간 전에 발생했다면 이미 늦습니다.

시나리오 B: RECOVERY WINDOW OF 7 DAYS​

같은 5개 backup을 가진 상태에서 정책을 시간 기반으로 바꿉니다.

retention_policy = RECOVERY WINDOW OF 7 DAYS
sudo -u barman barman cron
sudo -u barman barman list-backup pg01

이번에는 지난 7일 동안의 어느 시점으로도 PITR이 가능하도록 backup과 WAL이 함께 보존됩니다. 보존 기간 밖에 있는 backup만 OBSOLETE로 마크됩니다.

이 정책의 강점은 backup 빈도와 무관하게 PITR 보장이 일정하다는 점입니다. 시간당으로 떠도 일주일치, 일일로 떠도 일주일치를 유지하므로 운영자는 몇 개보다 얼마나 오래된 시점까지 보장할지를 정할 수 있습니다.

다만 디스크 사용량은 backup 빈도/크기에 따라 들쭉날쭉합니다. 시간당 backup으로 7일치를 보관하면 168개의 backup이 누적됩니다(reuse_backup = link로 dedup해도 작지 않습니다).

시나리오 C: minimum_redundancy 안전망​

정책이 너무 공격적으로 잡혀 있으면 모든 backup이 사라지는 사고도 가능합니다. 이를 막는 설정이 minimum_redundancy입니다.

retention_policy = RECOVERY WINDOW OF 1 DAY
minimum_redundancy = 2

RECOVERY WINDOW OF 1 DAY만 있으면 어제 backup 한 개만 남는 시점도 가능한데, minimum_redundancy = 2가 최소 2개는 항상 유지하도록 강제합니다. 정책과 안전망이 충돌할 때 안전망이 이깁니다.

기본값은 0, 즉 안전망이 없습니다. 운영 환경에서는 항상 1 이상으로 두는 편이 안전합니다.

시나리오 D: barman keep으로 영구 보존​

특정 backup을 retention 정책에서 영구 제외하려는 경우가 있습니다. 예를 들면 마이그레이션 직전의 안전 base나 분기 마감 시점입니다.

sudo -u barman barman keep pg01 20260506T090005 --target full

--target 옵션:

값의미
full이 backup과 모든 의존 WAL을 영구 보존하므로 full PITR 가능
standalonebackup 자체만 보존(WAL은 정책 따름), 디스크를 절약하며 backup 시점 복원만 가능
# 보존 대상 확인
sudo -u barman barman list-backup pg01
# → 'KEEP' 마크가 붙은 backup은 retention 정책에서 자동 제외된다

barman keep --release pg01 <backup_id>로 보호를 해제합니다. 운영 가이드에 "위험한 마이그레이션 직전엔 keep --target full을 걸어둔다"를 정착시키면 한 단계 단단해집니다.

OBSOLETE 판정에서 삭제까지​

list-backup 줄 끝에 붙는 보존 상태는 VALID, OBSOLETE, KEEP:FULL, KEEP:STANDALONE 등입니다. backup 자체의 상태(DONE, FAILED 등)와는 별개로, 보존 정책을 평가할 때마다 계산되는 값입니다. DELETED라는 상태는 따로 없습니다. 삭제된 backup은 목록에서 사라질 뿐입니다.

DONE (VALID)  ──(barman cron 정책 평가)──▶  OBSOLETE  ──(같은 cron 실행)──▶  삭제 (디스크 정리)

Barman 백업이 OBSOLETE로 판정된 뒤 같은 cron 실행에서 삭제되는 흐름

barman cron은 매 분 한 번 도는데(/etc/cron.d/barman 기본 설정), retention_policy_mode = auto이면 한 번 실행할 때마다:

  1. 보존 정책을 평가해 정책 밖의 backup을 OBSOLETE로 판정
  2. OBSOLETE로 판정된 backup을 같은 실행 안에서 삭제
  3. 종속된 WAL도 같이 정리

정책을 바꾼 뒤 디스크가 줄어드는 시점은 다음 barman cron 실행입니다. 정책을 바꾸고 cron이 돌기 전에 list-backup을 보면 OBSOLETE 표시만 있고 디스크는 그대로라 헷갈리기 쉽습니다.

수동으로 즉시 삭제하려면:

sudo -u barman barman delete pg01 20260506T090005

상황별 결정 가이드​

상황권장
PITR 기간이 SLA에 명시된 운영 환경RECOVERY WINDOW OF N DAYS (또는 WEEKS/MONTHS), SLA 그대로 매핑
backup 빈도/크기가 안정적이고 디스크 예측이 중요한 lab/소규모REDUNDANCY n, 디스크 사용량이 거의 일정
안전망 (정책 사고 대비)minimum_redundancy = 1 또는 2 (권장)
마이그레이션/분기 마감 등 영구 보존이 필요한 시점barman keep <backup-id> --target full
WAL이 별도 정책으로 더 길게 보관 필요wal_retention_policy = main 그대로 (대부분 충분)

정리​

항목내용
두 정책REDUNDANCY n (개수) / RECOVERY WINDOW OF n DAYS (시간)
Barman 권장RECOVERY WINDOW OF 4 WEEKS (운영 환경)
핵심 원리WAL은 살아 있는 가장 오래된 backup까지 보존되며 backup이 줄면 WAL도 줄어든다
안전망minimum_redundancy ≥ 1 (정책 사고 대비)
영구 보존barman keep <backup-id> --target full 또는 standalone
라이프사이클OBSOLETE 판정 후 같은 barman cron 실행에서 삭제 (retention_policy_mode = auto)

보존 정책의 초점은 몇 개를 남기느냐보다 얼마나 오래 PITR을 보장하느냐에 있습니다. 운영자에게는 개수보다 기간으로 사고하는 편이 대체로 자연스럽습니다.

참고 자료​