BarmanはpgBackRestの素直な置き換えではなかった

DEV Communityに、本番PostgresバックアップをpgBackRestからBarmanへ移した実録 が出ていた。
Railway上のPostgreSQL 16、DBサイズ約4.2GB、pgBackRest時代のリストア実測18分という環境で、Barmanに移したら何が起きたかという話だ。

背景には pgBackRest のアーカイブ化がある。
Perconaも2026年4月28日の記事で、4月27日にpgBackRestがアーカイブ扱いになったこと、ただしPercona Distribution for PostgreSQLでは引き続きpgBackRestを推奨し、今後の支援方法を協議中だと書いている。
なので「明日からpgBackRestが危険」という話ではない。
ただ、新規導入や長期運用で「保守されるバックアップ基盤を選びたい」という圧はかなり強くなった。

このブログでも、Supabase 2026年4月アップデート でMultigres OperatorがpgBackRestを使ったPITRバックアップを持っている件に触れた。
pgBackRestはPostgres周辺の基盤に深く入っている。
だからこそ、置き換え先を見るときは「コマンド名を差し替えれば終わり」では済まない。

Barmanの立ち位置

Barman（Backup and Recovery Manager）はPostgreSQL専用のオープンソースバックアップツールで、EDBが開発・メンテナンスしている。
Pythonで書かれていて、フルバックアップ、差分バックアップ、WALアーカイブによるPITR（Point-in-Time Recovery）に対応する。
PITRがあると「障害の10秒前」のように任意の時点までDBを巻き戻せるので、pg_dumpの論理バックアップとは復旧の粒度が違う。

設計上の特徴は、DBサーバーとは別にバックアップ専用のサーバーを立てる前提になっていること。
BarmanサーバーがSSHかstreaming replicationを通じてPostgreSQLからデータとWALを収集し、ローカルディスクやS3、Azure Blob Storage、Google Cloud Storageに保存する。
DB内部からダンプを吐くpg_dumpとも、PostgreSQL本体付属のpg_basebackupとも運用の形が異なる。
pg_basebackupはフルバックアップしか取れず差分・増分やパラレルリストアの機能がないので、本番環境ではBarmanかpgBackRestを選ぶのが一般的だった。

pgBackRestがアーカイブ化される前は、物理バックアップの選択肢としてBarmanとpgBackRestがほぼ二択の状態で、構成の好みや環境で分かれていた。
pgBackRestはCで書かれていてパフォーマンス寄り、Barmanは運用管理の機能が厚い、という棲み分けだった。

バックアップの取り方はrsync/SSH方式とstreaming方式の2つがある。

rsync/SSH方式は、BarmanサーバーからSSH経由でPostgreSQLのデータディレクトリをrsyncで転送する。
PostgreSQL側の archive_command に barman-wal-archive を設定して、WALファイルが切り替わるたびにBarmanサーバーへ送る仕組みだ。
PostgreSQLサーバーとBarmanサーバーの間でSSH公開鍵認証を通しておく必要がある。

streaming方式は、PostgreSQLのreplicationプロトコルでベースバックアップを取得し、WALは pg_receivewal 相当のBarman内蔵機能で常時受信する。
SSH接続がいらないので、コンテナ環境やSSHポートを開けられない構成でも使える。
ただしreplication slotが必須で、Barman側が停止するとPostgreSQLがWALを溜め続ける。
原典のRailway環境ではこちらが採用されていた。

flowchart LR
    subgraph PostgreSQL
        A[データベース]
        B[WAL]
    end
    subgraph Barmanサーバー
        C[バックアップカタログ]
        D[WALアーカイブ]
        E[ベースバックアップ]
    end
    A -->|rsync/SSH or<br/>streaming| E
    B -->|archive_command or<br/>receive-wal| D

日常の運用は barman cron を定期実行して回す。
WALのアーカイブ処理、古いバックアップの自動削除、retention policyの適用がこのコマンドにまとまっている。
barman backup がフルバックアップ取得、barman recover がリストア、barman check が構成と整合性の検査だ。
後述する barman check の問題は、この検査コマンドがSSH方式の項目まで含んでいるためにstreaming構成でFAILEDが出る話になる。

バックアップカタログという管理層があるのもBarmanの特徴で、いつ取ったバックアップがどのWAL範囲に対応するかを追跡する。
barman list-backup でバックアップ一覧、barman show-backup で個別のサイズや所要時間、WAL範囲が確認できる。
pg_basebackupだとこの管理は全部自前になるので、複数世代のバックアップを回す環境ではカタログが効いてくる。

原典の設定にあった RECOVERY WINDOW OF 14 DAYS は、過去14日間の任意の時点へPITRできるだけのバックアップとWALを保持するretention policyだ。
barman cron の実行時にこのポリシーより古いバックアップが削除される。
世代数で管理したい場合は REDUNDANCY 3（直近3世代保持）のような指定もできる。

置き換わったのはツール名ではなく運用モデル

原典の結論はかなり現場寄りだった。
Barman自体は堅い。ドキュメントも整っていて、EDBがメンテナンスしている。2026年2月にはBarman 3.17.0もリリースされ、S3 Object Lock対応やリストア時の運用改善が入っている。

でも、Barmanが前提にしている絵は「PostgreSQLサーバー」と「バックアップサーバー」が分かれていて、SSHで素直につながる構成だ。
VPSやベアメタルなら分かりやすい。
一方でRailway、Render、Fly.ioのようなコンテナ寄りの環境だと、SSH前提のモデルが急に重くなる。

原典では backup_method = streaming を選んでSSHを避けている。

[railway-postgres]
conninfo = host=<RAILWAY_HOST> user=barman dbname=postgres
streaming_conninfo = host=<RAILWAY_HOST> user=streaming_barman
backup_method = streaming
streaming_archiver = on
slot_name = barman_streaming_slot
streaming_archiver_name = barman_receive_wal
retention_policy = RECOVERY WINDOW OF 14 DAYS

これでバックアップは動く。
ただし、運用の見え方は変わる。

flowchart TD
    A[pgBackRest構成] --> B[ファイルベースのWAL archiving]
    B --> C[リストア実測18分]
    D[Barman構成] --> E[streaming backup]
    E --> F[replication slotでWAL保持]
    F --> G[リストア実測23分17秒]

原典の測定では、フルバックアップはBarmanが12分34秒、pgBackRestが14分程度。
バックアップだけ見るとBarmanのほうが少し速い。
でもリストアはBarmanが23分17秒、pgBackRestが18分で、約5分遅くなった。

DBサイズ4GB台で5分差なら、個人サービスや小規模SaaSでは許容できるかもしれない。
ただ、これはサイズが大きくなるほど「移行前に測るしかない」種類の数字だ。
PostgreSQLは業務データだけでなく、AirflowやGitLabのメタデータDBのように他サービスの状態保存にも使われる。
業務DBではなくても、止まるとパイプライン全体が詰まるDBはある。

Barmanのstreaming構成で一番怖いのはWAL slot

Barmanの公式マニュアルでは、WAL streamingを使う場合に streaming_conninfo、streaming_archiver = on、必要に応じて slot_name を設定する流れが説明されている。
replication slotは、Barmanが受け取るまでPostgreSQL側がWALを消さないための仕組みだ。

これは安全装置でもある。
同時に、バックアップ側が止まったときのディスク消費装置にもなる。

原典では、Barmanコンテナ再起動後にslotが非アクティブになり、WAL lagが847MBまで溜まった例が出ていた。
PostgreSQLは「まだBarmanが受け取っていない」と判断してWALを保持し続ける。
コンテナが復帰しなければ、WALがディスクを埋める。

確認するクエリはこういう形になる。

SELECT
  slot_name,
  active,
  restart_lsn,
  confirmed_flush_lsn,
  pg_size_pretty(
    pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
  ) AS lag
FROM pg_replication_slots
WHERE slot_name = 'barman_streaming_slot';

「バックアップが成功したか」だけでは足りない。
slotがactiveか、lagが増え続けていないか、Barmanの receive-wal が生きているかまでセットで見る。

flowchart TD
    A[PostgreSQL] --> B[WAL生成]
    B --> C{Barman receive-wal稼働中}
    C -->|yes| D[WAL受信]
    D --> E[archive-walで保存]
    C -->|no| F[replication slotがWAL保持]
    F --> G[pg_wal肥大化]
    G --> H[ディスク逼迫]

ここは、クラウドDBの自動バックアップより自前バックアップを選ぶときの分岐点になる。
マネージドPostgresのバックアップは細かい制御が効かないことも多いが、運用責任の一部をプロバイダに寄せられる。
Barmanを自前で持つなら、柔軟性と引き換えに、WAL slot、バックアップ保存先、リストア手順、監視ノイズを自分で引き受ける。

barman checkをそのままアラートにしない

原典で地味にきついのが barman check の扱いだ。
streaming backupで動いているのに、SSH関連のcheckが FAILED になり、全体として失敗扱いになるケースがある。

これはBarmanが壊れているというより、checkの粒度と構成の前提が合っていない。
でも監視にそのまま載せると、毎日ノイズになる。

見るなら、少なくとも以下は分けたい。

対象	異常時に起きること
最新フルバックアップの時刻	リストア起点が古くなる
receive-wal の稼働	WALがBarman側へ流れなくなる
replication slotのlag	PostgreSQL側のディスクを食う
リストア演習の所要時間	RTOが現実からずれる
保存先容量	バックアップ成功後に保持できなくなる

「checkコマンドが0か1か」より、この5つのほうが復旧時の意思決定に近い。
特にRTOは、ドキュメントに書いた希望値ではなく、リストアを実際に走らせた時間で見るしかない。

AWSのDR記事 で書いたBackup & Restore戦略も、結局は「データだけは残すが、復旧には時間がかかる」という割り切りだった。
PostgreSQL単体でも同じで、バックアップがあることと、許容時間内に戻せることは別の話だ。

pgBackRestから逃げるか残るか

pgBackRestのアーカイブ化を見て即Barmanへ移る、という判断は少し早い。
PerconaはpgBackRestを成熟した選択肢として扱い続ける姿勢を出しているし、既存環境でリストア手順まで検証済みなら、慌てて壊す理由は薄い。

逆に、新規でPostgreSQLバックアップ基盤を組むならBarmanは有力だ。
特にSSHできるVPS、ベアメタル、社内VMのような環境では、Barmanの設計と運用モデルが噛み合いやすい。

判断が割れるのは、Railwayのようなコンテナ環境だ。

環境	Barman移行の見え方
VPS / ベアメタル	SSH前提の構成が素直に組める
Kubernetes	専用Pod、PVC、NetworkPolicy、slot監視まで設計対象
Railway / Render / Fly.io	streaming構成に寄りやすく、slot lag監視が重要
Supabase / RDSなどのマネージドDB	まずプロバイダ標準のPITRとリストア条件を確認

バックアップ移行の判断材料はTPSでもレイテンシでもなく、バックアップ完了時間、WAL lag、リストア時間だ。

移行前に1回だけ本当に戻す

原典の一番よいところは、バックアップ成功ではなくリストア時間を測っているところだった。
バックアップツールの比較は、圧縮率や差分バックアップやクラウド保存先の話に寄りがちだが、事故の瞬間に必要なのは「いつ戻るか」だ。

Barmanへ移るなら、最低でもこの流れを移行作業に入れたい。

1. 本番相当のサイズでフルバックアップを取る
2. 別環境へリストアする
3. アプリケーションを接続して読み取り確認する
4. WAL適用後の時刻とデータ整合性を確認する
5. 所要時間を記録してRTOに反映する
6. Barman停止時のreplication slot lagアラートを試す

ここまでやると、Barmanが「pgBackRestの代替」なのか「運用モデルの作り直し」なのかが見える。
RailwayやRenderのような環境では、たぶん後者に近い。

参照

• Barman reemplaza a pgbackrest: migré mis backups de Postgres en producción y esto encontré
• pgBackRest is archived, what now?
• Barman 3.17 Released
• Barman Manual 3.0.1