DBAtlas · データベース運用アトラス

pgBackRest によるバックアップと PITR

PostgreSQLレベル: 中級所要時間: 45～90 分

pgBackRest によるフル / 差分 / 増分バックアップ、継続的 WAL アーカイブ、ポイントインタイムリカバリ (PITR)。単一サーバー、ストリーミングレプリケーション (primary + standby) または Patroni クラスタに対応し、リポジトリは同じサーバー、別のバックアップサーバー (SSH)、S3 互換オブジェクトストレージのいずれにも置けます。暗号化、圧縮、保持ポリシー、cron/systemd によるスケジュール、別ディレクトリへのテストリストアを含みます。同じガイドで障害時のインプレースリストア runbook も生成します (Patroni ではバックアップからのクラスタ再構築を含む)。類似ガイドとの違い: 本番環境に推奨される物理バックアップツールです。追加ツールなしで物理バックアップと PITR を行う場合は pg_basebackup + WAL アーカイブのガイドを、論理バックアップ (テーブル/データベースのダンプ、メジャーバージョン間の移行) には pg_dump / pg_restore のガイドを使用します。

構成: サーバー 1 台、primary + standby、または Patroni クラスタ。バックアップサーバーは任意

シナリオ

  • pgBackRest のインストール + 初回バックアップ + テストリストア — pgBackRest が未導入の場合: ソフトウェア、リポジトリ、WAL アーカイブ、初回バックアップ、スケジュール、テストリストア。
  • 障害時: インプレースリストア (最新状態または指定時刻まで) — データベースをその場で、バックアップとアーカイブに含まれる任意の時点に戻します: 最新、時刻、xid、LSN、restore point のいずれか。クラスタは停止し、目標時点以降の変更は失われます。
  • データディレクトリに破損または削除されたファイルがある (delta restore で修復) — サーバーは正常だが一部のデータファイルが読めない、または削除されている場合: --delta は差異のあるファイルだけをバックアップから書き戻し、アーカイブの最終時点まで進めます。クラスタは停止します。
  • 1 つのデータベースだけを戻す (--db-include) — クラスタは稼働したままです: 対象データベースだけを一時インスタンス (別ディレクトリ・別ポート) にリストアし、pg_dump で取り出して本番サーバーに別名でロードします。削除された単一テーブルもこのカードで対応します (そこから pg_dump -t)。
  • バックアップを別サーバーにリストアする (クローン / テスト / レポーティング) — 本番サーバーには触れません。バックアップを新しいサーバーに展開し、WAL アーカイブを無効にするため、クローンが本番のリポジトリに書き込むことはありません。暗号化リポジトリでは暗号鍵が必要です。
  • サーバーを完全に喪失: バックアップを新サーバーに展開して置き換える — ディスクまたはサーバーの喪失: 新サーバーをバックアップから起動して新しい primary にします。WAL アーカイブとバックアップは同じ stanza で継続します。旧サーバーは必ず停止したままにしてください。
  • バックアップから新しい standby を構築する (--type=standby) — primary にコピー負荷をかけずに新しい standby を作成します: ファイルはバックアップから取得し、不足分の WAL はアーカイブとストリーミングで補います。primary は稼働したままです。
  • バックアップは本当に健全か (info / check / verify とリストア訓練) — 読み取り専用の確認と、本番サーバーに触れずに別ディレクトリで行うリストア訓練。月次の検証ジョブ (cron) も設定します。
  • 保持期間を変更して古いバックアップを削除する (expire) — repo1-retention-full/diff の設定を変更し、まず --dry-run で削除対象を表示してから expire を実行します。削除したバックアップは元に戻せません。

開始前の確認

  • PostgreSQL … がインストールされ稼働していること (pg-install ガイド)…。このサーバーが primary…。データディレクトリは …。
  • Patroni クラスタ … が稼働していること (Patroni のインストール): Leader が 1 台、他はストリーミングレプリカ。全ノードでデータディレクトリは …、Patroni の設定は …、REST API のパスワードは /etc/patroni/patroni.env にあります。
  • 他のアーカイブ/バックアップツール (Barman、WAL-G、手書きの archive_command) が設定されていないこと。ある場合は先に削除してください。2 つのツールが同じ WAL を別々の場所に送ると、どちらも不完全になります。… Patroni では現在の値を patronictl show-config の出力で確認できます。…
  • データベースのサイズを把握していること。リポジトリにはおおよそ (full の数 + 1) × 圧縮後サイズ + WAL アーカイブ の容量が必要です (zst ではほとんどのデータベースで 1/3～1/5 に圧縮されます)。
  • リポジトリディレクトリ … がデータベースとは 別の ディスク/NFS 共有上にあり、永続的にマウントされていること (fstab)。
  • バックアップサーバーに … 用の十分な容量を持つ別ディスクがマウントされていること。バックアップサーバーがデータベースと同じ OS ファミリーであること。
  • サーバー同士が互いの名前を解決でき (…, …)、相互に 22/tcp (SSH) が開いていること。
  • standby (………, ……) が primary から WAL を受け取るストリーミング standby であり、primary と同じ PGDATA パス (…) を使用していること。
  • バケット … が作成済みで、このバケットに対してのみ読み取り/書き込み/削除の権限を持つアクセスキー (access key + secret key) が用意されていること。バケットにオブジェクトを削除する ライフサイクルルールがない こと (保持は pgBackRest が管理します)。サーバーからエンドポイントに到達できること。
  • 時刻が同期されていること (NTP)。PITR の目標時刻と S3 の署名は正しい時刻に依存します。
  • サーバーが PGDG と EPEL のリポジトリ (または社内ミラー) にアクセスできること。pgBackRest の依存パッケージ libssh2 は EPEL から提供されます。
  • 暗号鍵の保管場所 (パスワード保管庫 / vault) が用意されていること。暗号鍵をサーバー外に保管していないと、サーバー喪失時にバックアップを復号できません。

ガイドのフェーズ

  • pgBackRest ソフトウェアのインストール — PGDG リポジトリを追加する (バックアップサーバー) · PGDG リポジトリを追加する (バックアップサーバー) · EPEL リポジトリを有効にする · pgBackRest をインストールする · pgbackrest ユーザーを作成する · 古い設定ファイルを削除する
  • リポジトリの準備 — リポジトリディレクトリを作成する · リポジトリディレクトリを作成する · SSH 鍵を生成する (バックアップサーバー) · SSH 鍵を生成する (データベースサーバー) · バックアップサーバーの鍵を認可する · データベースサーバーの鍵を認可する …
  • pgBackRest の設定 — 設定ファイルを作成する · 設定ファイルを作成する (バックアップサーバー) · 設定ファイルを作成する (データベースサーバー) · S3 アクセスキーを入力する · 暗号鍵を生成する · 暗号鍵を … サーバーに書き込む …
  • stanza と初回バックアップ — stanza を作成する · stanza を作成する · 設定を検証する (check) · 初回の full バックアップを取得する · 初回の full バックアップを取得する · リポジトリの状態を表示する (info) …
  • バックアップのスケジュール — pgbackrest コマンドのパスを確認する · バックアップスクリプトを作成する · スクリプトの所有者と権限を設定する · systemd の service と timer を作成する · スケジュールをテストする (手動実行) · cron サービスを準備する …
  • 検証とリストアテスト — WAL アーカイブが機能していることを確認する · テストデータを書き込み、目標時刻を記録する · テストリストア用ディレクトリを準備する · 目標時刻まで別ディレクトリにリストアする · テストクラスタを別ポートで起動する · リストアされたデータを検証する …
  • 監視と保守 — リポジトリの整合性を検証する (verify) · リポジトリの整合性を検証する (verify) · 最新バックアップの経過時間を監視する · 最新バックアップの経過時間を監視する · 2 つ目のコピーと暗号鍵の保管
  • 診断: ファイルの破損か欠落か — ログのエラーと影響を受けたファイルを特定する · 破損したオブジェクトを特定する · 健全なバックアップとアーカイブがあることを確認する
  • リストア前の確認 — バックアップを一覧表示する · アプリケーションの接続を確認する · standby を停止する · PostgreSQL を停止する · 既存のデータディレクトリのコピーを取る (容量がある場合)
  • インプレースリストア — リストアする (--delta) · PostgreSQL を起動し、リカバリの完了を待つ · 目標時点のデータを確認する (pause) · リカバリを終了して promote する
  • 検証 — リストア用の設定を削除する · クラスタの状態を確認する · アプリケーションデータを確認する · 破損が解消されたことを確認する (amcheck) · アーカイブが継続していることを確認する · 新しい full バックアップを取得する …
  • リストア前: Patroni クラスタを停止する — バックアップを一覧表示する · クラスタの状態と動的設定を保存する · アプリケーションを停止する · レプリカで Patroni を停止する · leader で Patroni を停止する · 既存のデータディレクトリのコピーを取る (容量がある場合)
  • 検証と後片付け (Patroni) — アーカイブが継続していることを確認する · 新しい full バックアップを取得する · クラスタとアプリケーションの接続を確認する · 退避したデータディレクトリを削除する
  • Patroni: 破損したノードを再構築する (reinit) — 破損がどのノードにあるかを特定する · 破損したノードが leader であれば leader を移す · 破損したレプリカを再構築する (reinit)
  • バックアップ検証とリストア訓練 — バックアップの状態と最新バックアップの経過時間 (info) · アーカイブが現在機能していることを確認する (check) · リポジトリの整合性を検証する (verify) · 訓練用ディレクトリを準備する · 最新のバックアップを訓練用ディレクトリにリストアする · 訓練用インスタンスを起動してリカバリを待つ …
  • 月次検証のスケジュール — 月次検証スクリプトを作成する · スクリプトの権限を設定し、cron の環境でテストする · 月次の cron ジョブを作成する · cron ファイルの権限を設定する
  • 保持ポリシーを変更する — 現在の保持設定とバックアップ · 保持設定を変更する · 削除対象を表示する (dry-run) · 古いバックアップを削除する (expire) · リポジトリの使用量とスケジュールを確認する
環境に合わせた手順プランを開く →