プロンプトとコンテキスト
大規模なPostgreSQLクラスタにおいて、フルバックアップ時間の短縮とストレージコストの削減が求められています。pg_basebackupを使用して増分ベースバックアップチェーンを設計し、WAL依存関係、バックアップマニフェスト、pg_combinebackup、検証、保持ポリシー、リカバリ訓練について説明してください。
PostgreSQLでは、増分バックアップを直接リストアすることはできず、依存する過去のバックアップと結合して合成フルバックアップ（synthetic full）を作成する必要があります。ツールは関係性を検証しますが、依存関係の追跡や各バックアップの完全性の証明までは行いません。面接では、単一のバックアップコマンドの暗記ではなく、リカバリ可能性の確証（証跡）が試されます。
面接官がチェックしているポイント
フル、増分、WAL、マニフェストの役割、参照バックアップ、依存チェーン、合成フルバックアップ、pg_verifybackup、チェックサム、イミュータブルなオブジェクトバージョン、整合性チェック、チェーンの破損、スタンバイバックアップ、レプリケーションスロット/WALの保持、暗号化、目標復旧水準について説明できるか。バックアップ成功ダッシュボードではなく、実機訓練によってRPOとRTOを実証できるか。
最初に明確にすべき質問
リカバリ目標
RPO、RTO、目標時点（PITR）、クロスリージョンリカバリ、許容されるPostgreSQLバージョン変更、およびクラスタに複数のテーブルスペースが存在するかどうかを確認します。
バックアップワークロード
フルバックアップのサイズ、日次変更量、WAL生成レート、バックアップウィンドウ、ネットワーク帯域幅、オブジェクトストレージのライフサイクル、並行性制限を確認します。
一貫性とコンプライアンス
バックアップの暗号化とキーローテーション、イミュータブルな保持、削除権限、マニフェストのチェックサムアルゴリズム、監査ログ、訓練の頻度を確認します。
30秒で答える要約
「検証可能なフルバックアップから開始し、参照マニフェストをもとに増分バックアップを生成し、各マニフェスト、依存関係レコード、連続したWALセグメントを保持します。増分バックアップは直接リストアできないため、pgcombinebackupでチェーンを順序通りに結合し、必要なWALを適用します。オブジェクトストレージではイミュータブルなバージョニングと暗号化を採用し、pgverifybackupおよびサンプルリストアでコンテンツを検証します。依存関係が欠落している場合、自動処理により先行バックアップの削除をブロックします。バックアップ成功率に頼るのではなく、実際のデータサイズと障害訓練によってRPOとRTOを証明します。」
ステップごとの詳細な回答
ステップ1: バックアップチェーンのモデル化
フルバックアップ、各増分バックアップの参照バックアップ、LSN範囲、マニフェスト、キーバージョン、ストレージURIを記録します。すべてのノードは前提条件となるバックアップを指し示し、保持処理では最初にリカバリ可能な最古の時点を計算します。
ステップ2: 増分バックアップの生成
pg_basebackupは参照マニフェストを使用して増分バックアップを要求できます。増分バックアップには、その参照以降に変更されたブロックが含まれます。バックアップは単一のデータベースオブジェクトではなく、クラスタ全体を対象とします。レプリケーション接続には、REPLICATION権限またはスーパーユーザー権限と、十分なwalsenderが必要です。
full_0 = pg_basebackup(full)
inc_1 = pg_basebackup(incremental, reference=full_0.manifest)
inc_2 = pg_basebackup(incremental, reference=inc_1.manifest)ステップ3: 連続したWALの保持
ベースバックアップ中に生成されたWALは利用可能な状態で保持されなければなりません。stream方式では2つ目のレプリケーション接続を並行して開きます。fetch方式では転送が完了するまで必要なWALを保持するためにwal_keep_sizeまたはアーカイブが必要です。レプリケーションスロットは早期削除のリスクを軽減しますが、ディスク使用量が増大する可能性があるため、最古の要求LSNを監視します。
ステップ4: マニフェストと関係性の検証
pg_combinebackupは入力バックアップ間の正当な関係性を検証しますが、個々のバックアップの完全性は検証しません。すべてのノードに対してpg_verifybackupとマニフェストチェックサムを実行します。オブジェクトのアップロードと検証が完了した後にのみ、ノードをカタログに登録します。
ステップ5: リストア入力の構築
ターゲット時点について、フルバックアップから対象の増分バックアップまで順序通りにpg_combinebackupを呼び出し、合成フルバックアップを生成します。これは後続の結合操作のシードとして使用できますが、WALを置き換えるものではありません。バックアップ終了LSNからターゲット時点までのWALをリカバリディレクトリに配置し、リカバリターゲットを設定します。
ステップ6: チェーン破損と保持の処理
スケジューラは依存関係グラフとリカバリ可能な最古の時点を管理します。前提条件が欠落している、チェックサム検証に失敗する、またはキーが失われた場合は、すべての子孫をリカバリ不能としてマークし、前提条件の自動削除をブロックします。チェーンの長さとRTOを抑えるために、定期的に新しいフルバックアップまたは合成フルバックアップを作成します。
ステップ7: RPOとRTOの訓練
隔離された環境でランダムな時点のリストアを実行し、システムカタログ、テーブルスペース、WAL、拡張機能、アプリケーションの一貫性を確認します。ダウンロードバイト数、結合所要時間、WALリプレイレート、完了時間、チェックサムを記録します。オブジェクトストレージの404エラー、破損したマニフェスト、キーの失効、プライマリ障害を意図的に発生させてテストします。
模範解答
バックアップを依存関係グラフとして扱います。フルバックアップがルートであり、各増分バックアップは参照先を指し、WALが特定の時点を補完します。すべてのノードは、マニフェスト、チェックサム、LSN、キーバージョン、イミュータブルなオブジェクトURIを保存します。リカバリでは、pgcombinebackupを使用してチェーンを順序通りに結合し、連続したWALをリプレイします。結合時の関係性チェックは、pgverifybackupによるコンテンツチェックの代わりにはなりません。保持ポリシーはグラフに従い、計測されたRPO/RTOゲートを通過させる前に、破損したチェーン、欠落したWAL、キー失効、複数テーブルスペースを対象とした訓練を実施します。
よくある間違い
- 間違い: 増分バックアップをそのまま起動可能なディレクトリとして扱う。 → 失敗の理由: 参照バックアップに依存しているため。 → 対策: 合成フルバックアップに結合してからWALを適用する。
- 間違い: pg_combinebackupの実行成功のみを信用する。 → 失敗の理由: 各入力が破損していないことを証明していないため。 → 対策: すべてのマニフェスト/チェックサムを検証し、サンプルリストアを実施する。
- 間違い: 経過日数のみに基づいてフルバックアップを保持または削除する。 → 失敗の理由: 後続の増分バックアップが依存している可能性があるため。 → 対策: 依存関係グラフとリカバリ可能な最古の時点を使用する。
- 間違い: 連続したWALがない状態でバックアップ成功を報告する。 → 失敗の理由: 目的の時点までリプレイできないため。 → 対策: 要求LSN、アーカイブ遅延、スロット使用量を監視する。
フォローアップ質問と回答
フルバックアップ、合成フルバックアップ、増分バックアップの違いは何ですか？
フルバックアップはクラスタファイルの独立したコピーです。増分バックアップには参照先以降に変更されたブロックが含まれます。合成フルバックアップはチェーンから再構築されたものでありリストアの入力として使用できますが、目的の時点まで復旧するにはバックアップ終了時点以降のWALが依然として必要です。
増分チェーンを無期限に延長しないのはなぜですか？
チェーンが長くなると、ダウンロード、結合、検証、障害コストが増加し、RTOが悪化します。変更率、ストレージコスト、訓練データに基づいて、新しいフルバックアップまたは合成フルバックアップを適宜挿入します。
マニフェストが欠落している場合はどうしますか？
自動化処理においてそのノードを利用不可としてマークします。ファイル名から依存関係を推測してはなりません。信頼できるコピーからマニフェストを復元できた場合は、ファイルのチェックサム、LSN、チェーン関係性を検証した上で再登録します。
暗号化がリカバリを妨げないことをどのように証明しますか？
現在および過去のキーを使用して隔離環境で定期的にサンプルリストアを実施し、ローテーション、失効、権限、クロスリージョンKMSアクセスをテストします。キーが利用できない場合は、明示的にアラートを発報し、リカバリ可能性の保証対象からその時点を除外します。