pgBackRest가 멈춘 자리, Barman을 다시 본다

지난 글에서 pgBackRest의 종료를 정리하면서, 마이그레이션 평가의 가장 유력한 후보로 Barman(바만)을 짚었다. 표준이 멈췄다는 4월 말의 며칠이 시끄러웠던 동안, Barman은 평소처럼 일하고 있었다 — 3월에 v3.18.0을 조용히 릴리스했고, 깃허브 이슈는 평상시처럼 열리고 닫혔다. 14년째 그러고 있다.

오픈소스 도구의 가치는 시끄럽지 않게 잘 굴러갔다는 사실에서 가장 잘 드러난다. 그 14년이 어떻게 흘러왔는지, Barman이라는 도구가 어떤 모양으로 생겼는지 — 이 글은 1편으로 그 이야기를 정리하고, 실전 사용법은 2편(준비 중)에서 다룬다.

시작 — 토스카나 프라토에서 (2001 → 2008 → 2012)

Barman의 출발점을 이해하려면 먼저 모회사 2ndQuadrant Italia의 시작점으로 가야 한다.

시점사건
2001영국에서 2ndQuadrant Ltd. 창립 (Simon Riggs(시몬 리그스))
2008-05-212ndQuadrant Italia 설립 (이탈리아 프라토) — Gabriele Bartolini(가브리엘레 바르톨리니), Marco Nenciarini(마르코 넨치아리니) 등
2012Barman 첫 공개 (저작권 © 2012-)

토스카나 한가운데의 프라토에서 시작된 이 작은 컨설팅사가 PostgreSQL 생태계에 남긴 자취가 적지 않다. Logical Replication 초창기 구현에서 시작해 Barman, repmgr(고가용성 매니저), pglogical까지 — 그 진영에서 나온 도구가 운영 도구 라인업의 한 축을 채웠다. PG 코어팀의 Simon Riggs가 영국에서 비전을 세우고, 이탈리아 팀이 운영 도구의 실무를 채우는 분업이 16년간 이어졌다.

Barman은 그 라인업의 중심축이었다. 이름은 Backup And Recovery MANager의 머리글자에서 왔다.

1.0에서 2.0으로 — SSH 없이 살기 (2012 → 2016)

시점릴리스의미
2012Barman 1.xrsync over SSH 기반 원격 백업, archive_command로 WAL 수집
2016-09-27Barman 2.0streaming-only 백업 도입 — SSH 없이 pg_basebackup + replication slot으로 동작
2.x 후반barman-cloud-*S3·Azure·GCS 직결 명령어 도입

Barman 1.x 시대의 모델은 단순했다. Barman 서버 한 대가 SSH로 PG 서버에 붙어 rsync로 데이터 디렉토리를 가져오고, PG의 archive_command가 WAL 파일 하나하나를 Barman 서버로 밀어넣는 구조다. 1.x는 PG의 백업 절차를 원격에서 자동화했다는 점에서 의미가 있었지만, SSH 의존이라는 단단한 가정이 깔려 있었다.

2.0이 그 가정을 풀었다. 2016년 9월 27일 발표된 Barman 2.0의 핵심은 다음 한 줄이었다.

“Streaming-only backups are now possible through transparent integration with pg_basebackup and full support of replication slots for WAL streaming.”

(이제 streaming-only 백업이 가능하다 — pg_basebackup과의 투명한 통합, 그리고 WAL streaming을 위한 replication slot의 전면 지원으로.)

이 변화는 보기보다 컸다. SSH 키 분배·권한 관리·rsync 환경 구성을 매번 짜야 하던 운영자에게, *“PG의 streaming replication 프로토콜 위에 백업을 얹는다”*는 발상은 컨테이너 환경의 PG 운영을 비로소 자연스럽게 만들었다. 같은 릴리스에서 들어온 synchronous WAL streaming은 RPO=0 백업이라는 개념을 도구 수준에서 처음으로 풀어냈다.

이 시점 이후 Barman은 rsync 진영과 streaming 진영을 동시에 지원하는 도구가 됐고, 선택은 운영자에게 맡겨졌다. 2.x 후반에 들어온 barman-cloud-* 명령어 계열이 마지막 퍼즐이었다 — 백업 대상이 로컬 디스크일 수도, S3·Azure·GCS의 오브젝트 스토리지일 수도 있게 됐다.

EDB로 — 2020년 9월의 분기점

PG 생태계에서 2020년 9월 30일은 적지 않은 변곡점이다.

“EDB has acquired 2ndQuadrant, a global PostgreSQL solutions and tools company based out of the UK.” — Crunchbase, 2020-09-30

(EDB가 영국 본사의 글로벌 PostgreSQL 솔루션·도구 회사인 2ndQuadrant를 인수했다.)

EnterpriseDB(EDB, 미국 보스턴)가 2ndQuadrant(영국·이탈리아)를 인수했다. 합병 발표 당시 PostgreSQL 코어팀은 별도 성명을 냈다 — 한 회사가 PG 커미터 26명을 동시에 보유하게 된 사건이었기 때문이다. 인수가 완료된 2020-10-08의 공식 발표에는 이런 표현이 등장한다.

"…the largest dedicated provider of PostgreSQL products and solutions worldwide."

(…전 세계 최대 규모의 PostgreSQL 전문 제품·솔루션 제공사)

운영 도구 입장에서 이 사건이 의미하는 바는 분명했다. Barman의 메인테이너가 그 시점부터 EDB로 바뀌었다. GitHub 저장소도 자연스럽게 EnterpriseDB/barman으로 이관됐다. 같은 처지에 놓인 도구로는 BDR(Bi-Directional Replication), repmgr, pglogical 등이 있다.

여기서 한 가지 짚어둘 만한 점. “메인테이너가 바뀐다"는 사건의 결과는 동일하지 않다. Barman은 EDB 산하에서 활발한 유지를 이어갔다 — v2.x → v3.x 메이저 전환, 클라우드 백업 강화, 2026년 3월 v3.18.0까지. 14년째 정상 궤도에 있다.

같은 4월 pgBackRest는 같은 “메인테이너 변경” 변수 앞에서 정반대 결말을 맞았다. Crunchy Data의 Snowflake 인수 → 후원 단절 → 종료. 같은 단어가 다른 결말을 만든 셈이다. 무엇이 둘을 갈랐는가는 글 끝에서 한 번 다시 짚는다.

Simon Riggs 이후 — 2024년 3월

이 글에서 한 줄은 따로 두어야 한다. 2ndQuadrant의 창립자이자 PostgreSQL 코어 멤버였던 Simon Riggs(시몬 리그스)는 2024년 3월 26일 항공 사고로 사망했다.

EDB 인수 이후에도 Riggs는 EDB의 CTO로 PG 생태계를 이끌었던 인물이다. 그가 떠난 자리에 EDB가 — 그리고 Barman이 — 어떤 모양으로 남을지에 대해 적지 않은 사람들이 한 번씩 멈추고 들여다본 시기가 있었다. 결과적으로 도구는 흔들리지 않았다. 흔들리지 않았다는 사실이, 어쩌면 한 사람의 가장 큰 유산이다.

Bartolini의 추도글이 이 시기를 가장 잘 정리해 둔다 — 16년 전 토스카나의 작은 사무실에 둔 신뢰가, 결국 그가 떠난 뒤에도 도구를 살아 있게 만든 구조였다는 회고다.

아키텍처 — 중앙 카탈로그 모델

이제 도구 자체로 들어간다. Barman의 구조는 실은 단순하다.

flowchart LR
    PG[("PG 서버
primary 또는 replica")]
    BS["Barman 서버
(중앙 카탈로그)"]
    OS[("Object Storage
S3·Azure·GCS")]

    PG -- "rsync 또는
pg_basebackup" --> BS
    PG -- "WAL streaming 또는
archive_command" --> BS
    BS -. "barman-cloud-*" .-> OS

    classDef pg fill:#e8f0fe,stroke:#3367d6,color:#000
    classDef bm fill:#e6f4ea,stroke:#137333,color:#000
    classDef cloud fill:#fff4cc,stroke:#b08900,color:#000
    class PG pg
    class BS bm
    class OS cloud

세 레이어로 쪼개 보면 된다.

1. PostgreSQL 서버 (백업 대상) 하나 또는 여러 대. Barman 입장에서는 등록된 서버마다 별도 카탈로그 항목을 가진다. 각 서버는 두 채널로 Barman 서버와 연결된다 — base backup 채널과 WAL 채널.

2. Barman 서버 (중앙 카탈로그) Barman의 본체. 다음을 보관·관리한다.

  • 각 서버의 base backup (rsync 또는 pg_basebackup으로 생성)
  • 각 서버의 WAL archive (streaming 또는 archive_command로 수집)
  • 백업 메타데이터·보존 정책·체크 결과
  • 복구 시 사용할 recovery.signal과 설정 파일 자동 생성

설정은 /etc/barman.conf(전역)와 /etc/barman.d/<server>.conf(서버별)로 두 단계로 나뉜다. 운영 명령어는 단일 진입점 barman 한 줄에 모인다 — barman backup <server>, barman list-backups <server>, barman recover <server> <backup-id> <target>.

3. Object Storage (선택) v2.x 후반부터 들어온 barman-cloud-backup, barman-cloud-wal-archive, barman-cloud-restore 명령어를 통해 S3·Azure Blob·GCS에 직접 업로드·복원할 수 있다. PG 서버가 Barman 서버를 거치지 않고 곧바로 클라우드로 백업할 수도, Barman 서버를 거쳐 로컬 + 클라우드 2단 보관을 할 수도 있다.

백업 방식 두 갈래 — rsync 진영과 streaming 진영

Barman의 첫 인상이 *“옵션이 많다”*라면, 그 인상의 절반은 이 분기 때문이다.

항목rsync 모델streaming 모델
도입 시기1.x (2012-)2.0 (2016-)
전송 채널SSHPG streaming replication
의존SSH 키, rsync, sudoreplication slot, replication user
증분하드링크 dedup(PG17+ 블록 레벨로 점진 이행)
WAL 수집archive_commandreceive_wal (streaming)
적합 환경베어메탈·VM, SSH 통제 가능컨테이너·K8s, SSH 미허용

어느 쪽이 더 좋다고 단언하긴 어렵다. 베어메탈·VM에서 SSH 통제가 명확한 환경이라면 rsync 진영의 하드링크 dedup이 디스크를 덜 먹는다. 반대로 K8s에서 PG를 운영 중이라면 SSH 키 관리 자체가 부담이라 streaming 진영이 자연스럽다. CNPG가 Barman Cloud Plugin을 채택한 이유도 거기에 있다 — PG의 streaming 프로토콜 위에 백업을 얹는다는 발상이 K8s의 역할 분리에 잘 맞물린다.

도구의 철학 — PG에 위임한다는 결정

pgBackRest 종료 글에서도 인용한 Bartolini의 한 줄이 Barman을 이해하는 가장 짧은 길이다.

“Barman delegates data copy mechanisms to PostgreSQL primitives and rsync, focusing instead on orchestration, retention, and recovery management.”

(Barman은 데이터 복사 메커니즘 자체는 PG의 기본 기능과 rsync에 위임하고, 자기는 오케스트레이션·보존·복구 관리에 집중한다.)

이 한 문장을 풀면 이렇다. Barman은 *“파일을 어떻게 빠르게 복사할 것인가”*를 직접 풀지 않는다. 그건 PG의 pg_basebackup과 archive_command, 그리고 rsync가 이미 잘 풀어둔 문제다. Barman은 *“여러 PG 서버의 백업을 어떻게 한 곳에서 카탈로그화하고, 보존 정책을 적용하고, 복구 시점을 결정하고, 명령어 한 줄로 PITR을 실행시킬 것인가”*에 집중한다.

pgBackRest는 정확히 반대 결정을 한 도구였다 — 복사·압축·암호화·전송을 자체 C 구현체로 끝까지 통제했다. 그래서 빨랐고, 그래서 깔끔했고, 그래서 한 사람의 13년이 필요했다. Barman은 PG 자체의 진화에 올라타는 길을 골랐고, 결과적으로 EDB라는 모회사 변경을 견뎌낸 도구가 됐다.

둘 중 어느 쪽이 옳다고 단정할 일은 아니다. 다만 **“외부 의존을 줄이는 도구”**와 **“외부 의존에 올라타는 도구”**가 메인테이너 변경이라는 변수 앞에서 어떻게 다르게 반응하는지를, 같은 4월의 두 사건이 한 화면에 보여주었다는 점은 짚어둘 만하다.

정리

항목내용
첫 릴리스2012, 이탈리아 프라토 (2ndQuadrant Italia)
메인테이너 전환2020-10-08 EDB의 2ndQuadrant 인수 완료
백업 방식rsync (1.x~) / streaming (2.0~) / cloud (2.x 후반~) — 3가지 모드
최신 릴리스v3.18.0 (2026-03-12)
라이선스GPL-3.0
정체성PG에 복사를 위임하고 오케스트레이션에 집중하는 백업 매니저

Barman의 14년이 조용했다는 사실이, 이 도구의 가장 큰 광고다.

다음 편(준비 중)에서는 실제로 한 대의 Barman 서버를 세우고, 한 PG 인스턴스를 등록해 첫 백업을 떠 보고, 임의의 시점으로 복구하는 5개 명령어 시나리오를 다룬다. 이 글이 왜 Barman인가에 대한 답이라면, 다음 글은 어떻게 Barman인가에 대한 답이다.

참고 자료