Google Cloud Backup and DR

解決する課題

VM やデータベースのバックアップを、リソースごとにバラバラの方法で取って属人化させるのではなく、組織全体で一貫したポリシーとして管理できます。

• 多数の Compute Engine VM やデータベースのバックアップを一元管理し、取り忘れや設定漏れをなくす
• リージョン障害や論理的破壊（誤削除・ランサムウェア）に備えた**災害復旧（DR）**の受け皿を用意する
• 「いつまで、どこに、どの頻度で残すか」をバックアップ計画として標準化し、組織のポリシーを徹底する
• 復元の手順をマネージドな操作にまとめ、復旧時間（RTO）を短縮し人的ミスを減らす

主要概念と用語

• バックアップボールト（Backup Vault）: バックアップデータを保管する隔離された領域。**不変性（immutability）**と保持の最小期間を持ち、削除や改ざんから守られた保管先として機能する
• バックアップ計画（Backup Plan）: バックアップのスケジュール（頻度）と保持期間を定めるテンプレート。複数リソースへまとめて適用する
• バックアップ計画の関連付け（Plan Association）: バックアップ計画と保護対象リソースを結び付ける設定。これにより対象が計画に従って自動でバックアップされる
• 保護対象リソース: バックアップの対象。Compute Engine VM や、対応するデータベースなどが該当する
• アプリ整合バックアップ（application-consistent backup）: ディスク状態だけでなくアプリ/DB の整合性を確保した状態のバックアップ。クラッシュ整合より復旧の信頼性が高い
• 保持ロック（retention lock）: バックアップが保持期間内に消されないよう不変に固定する仕組み。コンプライアンスやランサムウェア対策に用いる
• RPO / RTO: それぞれ復旧時点目標（どこまでデータ損失を許容するか）と復旧時間目標（どれだけ早く復旧するか）。バックアップ頻度と復元手段の設計指標

仕様・制限・クォータ

• 主な保護対象は Compute Engine VM と対応するデータベース。対象範囲はリージョンやリソース種別により異なるため、設計時に対応状況を確認する
• バックアップボールトには最小保持期間を設定でき、その期間内のデータは削除・改変ができない（不変）。これがランサムウェアや誤操作に対する防御線になる
• スケジュールは頻度と保持を分けて定義する。短期は高頻度・短保持、長期は低頻度・長保持といった階層的な保持を組める
• バックアップ計画・関連付け数や、同時実行ジョブ数などには上限/クォータがある。具体値は変動するため公式の最新値を参照する
• リソースはプロジェクト/リージョンの境界に従う。別リージョンへの保管は DR 要件に応じて設計する

内部の仕組み

Google Cloud Backup and DR は、保護対象からバックアップを取得し、それをバックアップボールトへ保管し、必要時に復元するという 3 段階を、バックアップ計画というポリシーで束ねて自動化します。

• 取得: VM の場合はディスクのスナップショットを基にバックアップを作成する。VM 内のエージェントや連携機能を使うことで、DB を**静止点（アプリ整合）**で取得できる
• 保管: 取得したバックアップはボールトに格納される。ボールトは不変性と最小保持を備え、保管されたデータは保持期間が切れるまで保護される
• 保持の世代管理: バックアップ計画のスケジュールに従い、世代（復旧ポイント）が積み上がり、保持期間を過ぎたものは自動で失効する
• 復元: 保管済みのバックアップから、新しい VM やディスクとしてリストアする。これにより誤削除やリージョン障害から復旧する

クラッシュ整合（電源を急に切ったのと同じ状態）とアプリ整合（DB がトランザクション的に整った状態）の違いは復旧成功率に直結するため、データベースではアプリ整合を狙うのが基本です。

設計パターン / ベストプラクティス

• 集中バックアップポリシー: 部門ごとにバラバラに取らせず、バックアップ計画を標準テンプレート化して組織全体に適用する
• 階層的保持（GFS 的）: 日次は短期保持、週次/月次は長期保持といった複数計画の組み合わせで、復旧ポイントの粒度とコストを両立する
• 不変ボールトでランサムウェア対策: 保持ロック付きボールトに保管し、攻撃者や誤操作によるバックアップ削除を防ぐ
• クロスリージョン DR: 本番と異なるリージョンにバックアップを保管し、リージョン災害でも復旧可能にする
• アプリ整合の徹底: データベースは静止点を取り、復元後すぐに使える状態を担保する
• 定期的なリストアテスト: バックアップは「取れていること」より「戻せること」が重要。復元演習を運用に組み込む

運用・監視

• Cloud Monitoring でバックアップジョブの成功/失敗、所要時間、保管容量などを可視化し、失敗時に通知する
• Cloud Audit Logs でボールトや計画への操作（作成・変更・復元・削除試行）を監査する
• バックアップジョブの失敗アラートを設定し、保護されていないリソース（計画未関連付け）を定期的に棚卸しする
• 復元の所要時間を計測し、RTO 目標との差分を継続的に見直す

コスト

主なコスト要因は、バックアップとして保管するデータ量と、その保持期間です。世代を多く・長く残すほど保管コストが増えます。あわせて、別リージョンへ保管する場合はネットワーク転送やバックアップ運用に伴う費用も考慮します。具体的な料金は変動するため、最新の料金ページで確認してください。

• 保持期間と頻度を要件から逆算し、不要に長い保持を避ける
• 重要度の低いリソースは頻度を下げ、階層的な保持で総量を抑える
• 不変ボールトは安全だが、最小保持の設定値がコストに直結することを意識する

セキュリティ

• バックアップデータは保存時に暗号化される。要件に応じて Cloud KMS（CMEK） による顧客管理鍵を利用できる
• アクセス制御は Cloud IAM。バックアップ管理・復元・閲覧などの権限を最小権限で分離し、運用者と復元実行者を分ける
• バックアップボールトの不変性と保持ロックにより、攻撃者がバックアップを削除して復旧を妨げる手口（ランサムウェア）に対抗する
• ボールトや計画への操作は Cloud Audit Logs で追跡し、不審な削除試行を検知する

Well-Architected の観点

• 信頼性（reliability）: 定期バックアップとクロスリージョン保管で、論理破壊・リージョン障害からの復旧を担保する。RPO/RTO を明示して設計する
• 運用上の優秀性（operational excellence）: バックアップ計画の標準化と監視・アラートで、保護を属人化させず継続的に運用する。復元演習を定常業務に組み込む

試験で問われるポイント

関連サービス・比較

最も近い AWS サービスは AWS Backup です。位置づけと用語の対応を整理します。

GCP 内では、単発の保護なら永続ディスクのスナップショットで足りますが、複数リソースをポリシーで集中管理したい場合に Backup and DR を使う、という棲み分けになります。

ハンズオン / CLI例

Google Cloud CLI の gcloud backup-dr コマンド群でボールトや計画を操作します。実際のサブコマンドやフラグは環境により異なるため、最新のヘルプを確認してください。

# バックアップボールトを作成（不変性のための最小保持期間を指定）
gcloud backup-dr backup-vaults create my-vault \
  --location=asia-northeast1 \
  --backup-min-enforced-retention-duration=30d \
  --description="Immutable vault for prod VMs"

# 作成したボールトの設定（保持・不変性）を確認
gcloud backup-dr backup-vaults describe my-vault \
  --location=asia-northeast1

# バックアップボールトの一覧を確認
gcloud backup-dr backup-vaults list \
  --location=asia-northeast1

# 利用可能なコマンドとフラグを確認
gcloud backup-dr --help