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-21 | 2ndQuadrant Italia 설립 (이탈리아 프라토), Gabriele Bartolini(가브리엘레 바르톨리니), Marco Nenciarini(마르코 넨치아리니) 등 |
| 2012 | Barman 첫 공개 (저작권 © 2012-) |
토스카나 한가운데의 프라토에서 시작된 이 작은 컨설팅사가 PostgreSQL 생태계에 남긴 자취가 적지 않습니다. Logical Replication 초창기 구현에서 시작해 Barman, repmgr(고가용성 매니저), pglogical까지, 그 진영에서 나온 도구가 운영 도구 라인업의 한 축을 채웠습니다. PostgreSQL 코어팀의 Simon Riggs가 영국에서 비전을 세우고, 이탈리아 팀이 운영 도구의 실무를 채우는 분업이 16년간 이어졌습니다.
Barman은 그 라인업의 중심축이었습니다. 이름은 Backup And Recovery MANager의 머리글자에서 왔습니다.
1.0에서 2.0으로 (2012 → 2016)
이 시기에 Barman은 SSH 없이도 동작하는 길을 열었습니다.
| 시점 | 릴리스 | 의미 |
|---|---|---|
| 2012 | Barman 1.x | rsync over SSH 기반 원격 백업, archive_command로 WAL 수집 |
| 2016-09-27 | Barman 2.0 | streaming-only 백업 도입, SSH 없이 pg_basebackup + replication slot으로 동작 |
| 2.x 후반 | barman-cloud-* | S3, Azure, GCS 직결 명령어 도입 |
Barman 1.x 시대의 모델은 단순했습니다. Barman 서버 한 대가 SSH로 PostgreSQL 서버에 붙어 rsync로 데이터 디렉토리를 가져오고, PostgreSQL의 archive_command가 WAL 파일 하나하나를 Barman 서버로 밀어넣는 구조입니다. 1.x는 PostgreSQL의 백업 절차를 원격에서 자동화했다는 점에서 의미가 있었지만, 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 환경 구성을 매번 짜야 하던 운영자에게, “PostgreSQL의 streaming replication 프로토콜 위에 백업을 얹는다“는 발상은 컨테이너 환경의 PostgreSQL 운영을 비로소 자연스럽게 만들었습니다. 같은 릴리스에서 들어온 synchronous WAL streaming은 RPO=0 백업이라는 개념을 도구 수준에서 처음으로 풀어냈습니다.
이 시점 이후 Barman은 rsync 진영과 streaming 진영을 동시에 지원하는 도구가 됐고, 선택은 운영자에게 맡겨졌습니다. 2.x 후반에 들어온 barman-cloud-* 명령어 계열이 마지막 퍼즐이었습니다. 백업 대상이 로컬 디스크일 수도, S3, Azure, GCS의 오브젝트 스토리지일 수도 있게 됐습니다.
EDB로 향한 2020년 9월의 분기점
PostgreSQL 생태계에서 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 코어팀은 별도 성명을 냈습니다. 한 회사가 PostgreSQL 커미터 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로 PostgreSQL 생태계를 이끌었던 인물입니다. 그가 떠난 자리에 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 입장에서는 등록된 서버마다 별도 카탈로그 항목을 가집니다. 각 서버는 두 채널, base backup 채널과 WAL 채널로 Barman 서버에 연결됩니다.
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에 직접 업로드, 복원할 수 있습니다. PostgreSQL 서버가 Barman 서버를 거치지 않고 곧바로 클라우드로 백업할 수도, Barman 서버를 거쳐 로컬 + 클라우드 2단 보관을 할 수도 있습니다.
rsync와 streaming, 두 갈래 백업 방식
Barman의 첫 인상이 “옵션이 많다“라면, 그 인상의 절반은 이 분기 때문입니다.
| 항목 | rsync 모델 | streaming 모델 |
|---|---|---|
| 도입 시기 | 1.x (2012-) | 2.0 (2016-) |
| 전송 채널 | SSH | PG streaming replication |
| 의존 | SSH 키, rsync, sudo | replication slot, replication user |
| 증분 | 하드링크 dedup | (PG17+ 블록 레벨로 점진 이행) |
| WAL 수집 | archive_command | receive_wal (streaming) |
| 적합 환경 | 베어메탈/VM, SSH 통제 가능 | 컨테이너/K8s, SSH 미허용 |
어느 쪽이 더 좋다고 단언하긴 어렵습니다. 베어메탈/VM에서 SSH 통제가 명확한 환경이라면 rsync 진영의 하드링크 dedup이 디스크를 덜 먹습니다. 반대로 K8s에서 PostgreSQL을 운영 중이라면 SSH 키 관리 자체가 부담이라 streaming 진영이 자연스럽습니다. CNPG가 Barman Cloud Plugin을 채택한 이유도 거기에 있습니다. PostgreSQL의 streaming 프로토콜 위에 백업을 얹는다는 발상이 K8s의 역할 분리에 잘 맞물립니다.
PostgreSQL에 위임한다는 철학
pgBackRest 종료 글에서도 인용한 Bartolini의 한 줄이 Barman을 이해하는 가장 짧은 길입니다.
“Barman delegates data copy mechanisms to PostgreSQL primitives and rsync, focusing instead on orchestration, retention, and recovery management.”
(Barman은 데이터 복사 메커니즘 자체는 PostgreSQL의 기본 기능과 rsync에 위임하고, 자기는 오케스트레이션·보존·복구 관리에 집중한다.)
이 한 문장을 풀면 이렇습니다. Barman은 “파일을 어떻게 빠르게 복사할 것인가"를 직접 풀지 않습니다. 그건 PostgreSQL의 pg_basebackup과 archive_command, 그리고 rsync가 이미 잘 풀어둔 문제입니다. Barman은 “여러 PostgreSQL 서버의 백업을 어떻게 한 곳에서 카탈로그화하고, 보존 정책을 적용하고, 복구 시점을 결정하고, 명령어 한 줄로 PITR을 실행시킬 것인가"에 집중합니다.
pgBackRest는 정확히 반대 결정을 한 도구였습니다. 복사, 압축, 암호화, 전송을 자체 C 구현체로 끝까지 통제했습니다. 그래서 빨랐고, 그래서 깔끔했고, 그래서 한 사람의 13년이 필요했습니다. Barman은 PostgreSQL 자체의 진화에 올라타는 길을 골랐고, 그 덕에 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년을 조용히 굴러왔다는 사실은, 백업 도구에 기대하는 안정성을 그대로 보여줍니다.
2편에서는 실제로 한 대의 Barman 서버를 세우고, 한 PostgreSQL 인스턴스를 등록해 첫 백업을 떠 보고, 임의의 시점으로 복구하는 5개 명령어 시나리오를 다뤄요. 이 글이 왜 Barman인가에 대한 답이라면, 다음 글은 어떻게 Barman인가에 대한 답이에요.
참고 자료
- Barman 공식 (pgbarman.org)
- EnterpriseDB/barman: GitHub
- Barman 2.0 Released: postgresql.org/about/news (2016-09-27)
- 16 Years After The Launch of 2ndQuadrant Italy: Gabriele Bartolini (2024-05)
- Statement from the PostgreSQL Core Team on the EDB acquisition of 2ndQuadrant
- EDB Completes Acquisition of 2ndQuadrant: EDB Press Release (2020-10-08)
- Remembering Simon Riggs: postgresql.org/about/news (2024)
- pgBackRest의 종료: 13년 단독 메인테이너 시대의 끝 (지난 글)
- 2ndQuadrant: PostgreSQL Wiki
- CloudNativePG: Barman Cloud Plugin