なぜ本番環境では pg_dump だけでは不十分なのか？
Postgres の管理を始めたばかりの頃、私は毎晩 pg_dump を実行するだけで十分だと思っていました。しかし、システムのデータベースが 500GB に達し、顧客からバックアップの中間点である午前 10:15 のデータを復元するよう要求されたとき、その考えは打ち砕かれました。この時、pg_dump は前夜の状態に戻すことしかできず、午前中の 10 時間分のトランザクションはすべて失われてしまったのです。
これが、私が Barman (Backup and Recovery Manager) に移行した理由です。これは企業標準の PostgreSQL バックアップ管理を行うオープンソースツールです。Barman の最大の利点は、Point-in-Time Recovery (PITR) をサポートしていることです。障害が発生する直前の特定の時点まで、秒単位の精度でデータベースを簡単に復元できます。
Quick Start: 5分で Barman をインストール
安全性を確保するため、Barman は独立したサーバーにインストールすることをお勧めします。これにより、データベースサーバーのハードウェア故障や火災などのトラブルが発生しても、バックアップを保護できます。
1. Barman のインストール
# Ubuntu/Debian の場合
sudo apt update
sudo apt install barman barman-cli -y2. パスワードなし SSH の設定
Barman は、生のデータをコピーするために postgres ユーザー経由で DB サーバーにアクセスする必要があります。以下のコマンドでキーを作成し、DB サーバーにコピーしてください。
# Barman サーバー上の barman ユーザーに切り替え
sudo su - barman
ssh-keygen -t rsa
ssh-copy-id postgres@<IP_DB_SERVER>3. Barman でのサーバー設定
/etc/barman.d/pg_production.conf に設定ファイルを作成します：
[pg_production]
description = "Main PostgreSQL Production Database"
conninfo = host=<IP_DB_SERVER> user=barman dbname=postgres
ssh_command = ssh postgres@<IP_DB_SERVER>
retention_policy = RECOVERY WINDOW OF 2 WEEKS
archiver = on4. 初回バックアップの実行
# 接続を確認
barman check pg_production
# バックアップを実行
barman backup pg_productionWAL アーカイブメカニズム – PITR の核心
Barman の真価は、WAL (Write-Ahead Logging) の処理方法にあります。Postgres では、すべてのデータ変更が小さなログファイル（通常は 16MB）に記録されます。Barman はこれらのファイルをストレージサーバーに継続的に収集（アーカイブ）します。
復元が必要な際、Barman は Base Backup（フルバックアップ）を取得し、WAL ファイルを時系列順に適用していきます。このプロセスは、ビデオを見たいシーンまで巻き戻すようなものです。これが Point-in-Time Recovery (PITR) の本質です。
PostgreSQL サーバーからのログ転送設定
DB サーバー上の postgresql.conf を編集して、Barman へのログ転送を有効にします：
wal_level = replica
archive_mode = on
archive_command = 'rsync -a %p barman@<IP_BARMAN_SERVER>:/var/lib/barman/pg_production/incoming/%f'実務経験から、WAL ファイルは非常に速く蓄積されることがわかっています。適切に管理しないと、ピーク時には数時間でディスクがいっぱいになってしまいます。Barman は、設定された保存ポリシー（retention policy）に基づいて古いファイルを自動的に圧縮および削除することで、この問題を解決します。
Point-in-Time Recovery の秘訣（土壇場での救済）
悪夢のようなシナリオを想像してみてください。午前 2 時にマイグレーションスクリプトが失敗し、customers テーブルが空になってしまいました。Barman があればパニックになる必要はありません。エラーが発生する直前の「01:59:59」という時点を特定するだけです。
特定の時点に復元するコマンド：
barman recover --target-time "2023-10-27 01:59:59" \
pg_production \
/path/to/new/data/directoryこの時、Barman は復元に必要なバックアップと WAL ファイルを自動的に計算します。完了後、データベースを新しいディレクトリに向けて再起動するだけです。システムは、エラーがなかったかのように正常に動作します。
Barman 運用の実践的な経験
ストレージ容量の最適化
当初、私の 1TB のデータベースはバックアップに膨大なスペースを消費していました。設定ファイルで compression = gzip を有効にした後、バックアップ容量は 65% 以上削減され、約 350GB になりました。これにより、復元プロセスを大幅に遅らせることなく、ストレージコストを節約できました。
モニタリングを忘れない
自動バックアップだからといって、放置していいわけではありません。私は常に 1 時間ごとに barman check を実行する cron ジョブを設定しています。ステータスが OK でない場合（ディスクフルや SSH エラーなど）、システムは即座に Telegram 経由でアラートを送信します。信じてください、データベースがダウンした時にバックアップの失敗に気づくより、余裕がある時に気づく方がはるかに良いです。
復元後のデータ処理
デバッグのためにリストアした後、比較のためにデータを CSV としてすばやく抽出する必要があることがよくあります。CSV を分析や NoSQL ツールへのインポートのために JSON に変換する場合、私はよく toolcraft.app/ja/tools/data/csv-to-json を使用します。ブラウザ上で直接処理されるため、機密データがサーバーに送信されることがなく、非常に安全で便利です。
価値のある高度な機能
- Streaming Backup: Barman は、16MB 溜まるのを待たずに継続的に WAL をストリーミングすることをサポートしています。
- Hook Scripts:
post-backup-scriptを使用して、バックアップを S3 や Google Cloud Storage に自動転送できます。これは 3-2-1 バックアップモデルを完成させるための重要なステップです。 - Barman Cloud: このツールセットを使用すると、中間サーバーを介さずに Postgres からクラウドオブジェクトストレージに直接バックアップでき、クラウドネイティブなアーキテクチャに非常に適しています。
おわりに
Barman は単なるバックアップツールではなく、包括的なデータ安全管理システムです。今日、数時間を費やして Barman を設定することで、毎晩ぐっすり眠れるようになります。データが消えてから、いつまでも pg_dump に固執していたことを後悔しないようにしましょう。
独自サーバー（VM またはベアメタル）で PostgreSQL を実行している場合、Barman は最良の選択肢です。AWS RDS のようなサービスには同様のメカニズムが備わっていますが、Barman の仕組みを理解しておくことは、PostgreSQL の本質を把握し、データベースのトラブルシューティングに自信を持つのに役立ちます。
