判断: どのバックアップ戦略か?

バックアップ戦略は、許容できるデータ損失量 (RPO)、データサイズ、復旧に必要な速さ (RTO) の 3 つの要素のバランスで選択する。すべてのシナリオに合う単一の方法はない。このツリーは、RPO 目標を起点に、論理ダンプ、物理バックアップ + PITR、スナップショットの間で選択を導き、3-2-1 と検証は譲れない原則であることを想起させる。

データ損失の目標 (RPO) は?

最も決定的な制約から始める: 災害時に何分/何時間分のデータを失っても許容できるか? ほぼゼロのデータ損失が必要なら、継続的なログアーカイブ (PITR) が必須。日次/週次のバックアップで許容できるなら、よりシンプルな方法で十分。RPO が戦略の枠組みを決める。

• ほぼゼロ — 任意の時点に戻れる必要がある
• 日次/定期的なバックアップ (数時間の損失) で許容できる
• まず一般的なベストプラクティス (3-2-1 / 検証) を確認したい

データサイズと可搬性の要件は?

定期的なバックアップで十分な場合、次の問題は規模と目的: データベースは小/中規模で、バックアップを別の環境/バージョンに移せるようにしたいのか、それともデータが大きく、数分以内に復旧することが最大の関心事なのか? これにより論理ダンプとスナップショットのどちらにするかが決まる。

• 小/中規模、可搬性がありバージョン間で互換性がある
• 大規模データ、復旧は非常に高速である必要がある (低 RTO)

推奨: 論理ダンプ

データを論理レベル (スキーマ定義 + 行) でエクスポートする。出力は SQL/テキスト (pg_dump の plain 形式、mysqldump) か、ツール固有のバイナリダンプ (pg_dump -Fc、Oracle Data Pump) のいずれか。小/中規模のデータベース、移行、バージョンアップグレード、特定のテーブル/オブジェクトの復旧に適した柔軟で可搬性のある方法。

推奨: 物理バックアップ + WAL/アーカイブログ (PITR)

定期的に物理ベースバックアップを取得し、トランザクションログ (WAL/redo/binlog) を継続的にアーカイブする。これにより任意の時点へのポイントインタイムリカバリが可能になり、データ損失をほぼゼロに抑えられる。

推奨: スナップショット

ストレージ層または仮想化層で、データのブロックレベルのスナップショットを取得する。非常に大規模なデータベースでもバックアップとリストアが非常に高速。ただし、インフラに依存し、慎重な運用が必要。

推奨: 3-2-1 ルール + オフサイト + 検証の必須化

どの方法を選択しても、これらの原則を戦略の上位に置く必要がある。バックアップが存在するだけでは不十分で、異なるメディア、異なる場所に保管し、定期的にテストする必要がある。これは上記すべての選択肢を補完する枠組み。