Barman 보존 정책 워크북 — REDUNDANCY와 RECOVERY WINDOW

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

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

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

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

두 정책 한눈에

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이 무한히 누적된다. Barman 디스크 폭발의 90%는 여기서 비롯된다.

시나리오 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 - 2026-05-06 13:00:35 - Size: 41.5 MiB - WAL Size: 16 MiB
pg01 20260506T120005 - F - 2026-05-06 12:00:35 - Size: 41.5 MiB - WAL Size: 16 MiB
pg01 20260506T110005 - F - 2026-05-06 11:00:35 - Size: 41.5 MiB - WAL Size: 16 MiB
pg01 20260506T100005 - O - OBSOLETE        # 정책 위반
pg01 20260506T090005 - O - OBSOLETE

F(FULL/DONE)는 보존, O(OBSOLETE)는 삭제 후보. 다음 barman cron 사이클이 OBSOLETE 백업과 그에 종속된 WAL을 실제로 디스크에서 제거한다.

함정 — 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 옵션:

# 보존 대상 확인
sudo -u barman barman list-backup pg01
# → 'KEEP' 마크가 붙은 backup은 retention 정책에서 자동 제외된다

barman keep --release pg01 <backup_id>로 보호 해제. 운영 가이드에 “위험한 마이그레이션 직전엔 keep --target full을 박는다“를 정착시키면 한 단계 단단해진다.

OBSOLETE → DELETED 라이프사이클

backup이 정책 위반에서 디스크 제거까지 두 단계로 흐른다.

DONE  ──(barman cron 평가)──▶  OBSOLETE  ──(다음 cron)──▶  DELETED (디스크 정리)

barman cron은 매 분 한 번 도는데(/etc/cron.d/barman 기본 설정), 매 사이클마다:

1. 정책 위반 backup을 OBSOLETE로 마크
2. 이전 사이클에서 OBSOLETE로 마크된 backup을 실제로 삭제
3. 종속된 WAL도 같이 정리

즉 정책을 적용한 직후가 아니라 cron 한두 사이클 뒤에 디스크가 줄어든다. “왜 안 줄어들지“라고 헷갈리는 흔한 지점이다.

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

sudo -u barman barman delete pg01 20260506T090005

결정 가이드 — 언제 무엇을 쓰나

정리

“보존 정책은 몇 개 남기느냐가 아니라 얼마나 오래 PITR을 보장하느냐의 문제다. 시간으로 사고하는 게 운영자에게 자연스럽다.”

참고 자료

• Barman 3.18 — Configuration / Retention Policies (공식)
• Barman 3.18 — User Guide
• Barman 시리즈 1편 — 14년의 발자취
• Barman 시리즈 2편 — 5명령어 quickstart
• Barman 시리즈 3편 — rsync 모드와 하드링크 dedup
• Barman 시리즈 5편 — PITR 워크북