<style> .ap-hero{padding:clamp(24px,5vw,48px);border-radius:24px;color:#f8fafc;background:linear-gradient(135deg,#0f172a,#075985 55%,#047857);box-shadow:0 18px 44px #0f172a2b}.ap-hero p{max-width:790px}.ap-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.ap-card{padding:18px;border:1px solid #bae6fd;border-radius:17px;background:#fff}.ap-card b{display:block;font-size:1.65rem;color:#0369a1}.ap-flow{display:grid;grid-template-columns:1fr auto 1fr auto 1fr;gap:10px;align-items:center;margin:24px 0}.ap-step{height:100%;padding:18px;border-radius:16px;background:#f0f9ff;border:1px solid #bae6fd}.ap-arrow{font-size:1.5rem;color:#0284c7}.ap-table{display:block;overflow-x:auto}.ap-table table{width:100%;min-width:700px;border-collapse:collapse}.ap-table th,.ap-table td{padding:12px;border:1px solid #cbd5e1;text-align:left}.ap-table th{background:#e0f2fe}.ap-note,.ap-warn{padding:18px;border-radius:13px;margin:18px 0}.ap-note{background:#ecfdf5;border-left:5px solid #10b981}.ap-warn{background:#fff7ed;border-left:5px solid #f97316}.ap-status{display:grid;grid-template-columns:9rem 1fr 3rem;gap:10px;align-items:center;margin:9px 0}.ap-meter{height:14px;background:#e2e8f0;border-radius:999px;overflow:hidden}.ap-meter i{display:block;height:100%;background:linear-gradient(90deg,#0ea5e9,#10b981)}@media(max-width:720px){.ap-grid,.ap-flow{grid-template-columns:1fr}.ap-arrow{transform:rotate(90deg);text-align:center}.ap-status{grid-template-columns:1fr}} </style>

GOOGLE CLOUD BACKUP AND DR / PREVIEW

VMを作ったのにバックアップを付け忘れる——をラベルで防ぐ

Auto-protection policyがリソースラベルを評価し、該当するCompute Engine VMまたはディスクへ指定のバックアッププランを自動関連付けします。

2種類VMとPersistent Disk
最大8時間初期設定・保護予定の反映目安
100 projects1ポリシー当たりのPreview推奨上限

3行要約

  • Google Cloudは2026年9月16日、Backup and DRのAuto-protection policiesをPreview公開しました。
  • ラベル条件に合うCompute Engine VMまたはディスクへ、プロジェクト横断でバックアッププランを自動適用できます。
  • Previewでは単一リージョン、単一ラベルキー制約、Terraform未対応があるため、検証環境から段階導入します。

背景:バックアップ対象の追加漏れは構成差分から生まれる

バックアッププランを整備していても、新しいVMやディスクを個別に関連付ける運用では、作成経路が増えるほど漏れが起きます。コンソール、CLI、IaC、別チームのプロジェクトなど、インフラ作成と保護設定の責任が分かれるためです。

Auto-protectionは、backup=goldのようなラベルを「保護意図」として扱います。条件に一致するリソースを継続的に検出し、指定したBackup planへ関連付けることで、手作業の対象選択を減らします。

1. Label
`backup=gold`をVMへ付与
2. Match
ポリシーが条件を評価
3. Protect
Backup planを自動関連付け

何が新しいのか

新機能はBackup vault projectにAuto-protection policyを作り、Workload projectをbindingで関連付けます。ラベルに一致した対象へ、同じリージョン・対象リソース種別のBackup planが適用されます。

構成要素配置役割
Backup vault / Backup planBackup vault project保存先とスケジュール・保持ルールを定義
Auto-protection policyBackup vault projectLabel、Region、Resource type、Planを対応付け
Policy bindingProject間どのWorkload projectへポリシーを適用するか指定
VM / DiskWorkload projectラベル条件に一致すると保護対象になる

技術的なポイント

ラベルは「環境」ではなく「保護レベル」に寄せる

env=prodだけでバックアップを決めると、同じ本番環境でも異なるRPO・保持期間を表現できません。backup=goldbackup=silverのように保護意図を直接表し、組織のラベル作成権限を制御する方が監査しやすくなります。

ただしPreviewでは、同じプロジェクトへ複数のAuto-protection policyを適用する場合、全ポリシーで同じラベルキーを使う必要があります。env=prodtier=goldのように異なるキーを混在できません。

VMとDiskは別のリソース種別

ポリシーはcompute.googleapis.com/Instanceまたはcompute.googleapis.com/Diskを対象にします。VM単位のバックアップと独立ディスク保護を同じものとして扱わず、復旧単位を決めてからBackup planを設計します。

導入手順

  1. Backup vault projectとWorkload projectを分けるか決めます。
  2. Vaultと、対象リージョン・リソース種別に合うBackup planを作ります。
  3. Workload側の対象VMまたはDiskへ、標準化したラベルを付けます。
  4. Auto-protection policyへRegion、Resource type、Label、Backup planを設定します。
  5. Policy bindingで検証用Workload projectを追加します。
  6. Matching、Protected、Failedの件数と実際のRecovery pointを確認します。
  7. 復元テスト後、対象プロジェクトを段階的に増やします。
# 対象VMへ保護レベルを付ける
gcloud compute instances add-labels app-01 \
  --labels=backup=gold \
  --zone=asia-northeast1-a

# ポリシーと一致するリソースを確認する
gcloud backup-dr binding-matching-resources list \
  --auto-protection-policy-binding=prod-apps \
  --auto-protection-policy=gold-vm-policy \
  --location=asia-northeast1
完了条件はラベル付与ではありません。
Matching resourcesとProtected resourcesが一致し、最新のBackupが成功し、別VMまたは別Diskへ復元できるところまで確認します。

IAM:中央管理とWorkload側の同意を分ける

Backup vault projectではroles/backupdr.adminまたはroles/backupdr.editorがポリシー管理に必要です。Workload project側でもbindingの承認・管理権限が必要です。

プロジェクトをまたぐ場合、Backup vaultのサービスエージェントへ、VMならroles/backupdr.computeEngineOperator、Diskならroles/backupdr.diskOperatorを対象Workload projectで付与します。広いEditor権限で代用せず、対象種別に合うOperator roleを使います。

監視する3つの件数

Matching
100
Protected
98
Failed
2

Matching - Protectedがゼロにならない場合、権限、リージョン、Backup planの対象種別、既存の関連付けを確認します。初期構成と保護スケジュールには通常最大2時間、場合によって最大8時間かかるため、即時一致だけをSLOにしない設計が必要です。

開発者と企業への影響

開発チームは、VM作成時にバックアップAPIを個別呼び出しする代わりに、標準ラベルを付けるだけで保護要件を宣言できます。一方、ラベルのタイプミスや無断削除が保護漏れにつながるため、Org Policy、CI検査、Asset Inventoryなどで必須ラベルを別途統制する必要があります。

中央運用チームはBackup planを一元化しつつ、Workload projectごとにbindingを管理できます。請求対象にはBackup and DR、Compute Engine VM・Diskが含まれるため、対象の急増と保持期間によるコストも監視します。

Previewのリスクと限界

本番へ直行しないでください。
公式ドキュメントはPreviewのScale recommendationsとして、本番リソースを使用せず、1ポリシー当たり最大100プロジェクトを推奨しています。
  • 対象はCompute Engine VMとDiskのみです。
  • 1ポリシーは単一リージョンです。複数リージョンには別ポリシーが必要です。
  • 同一プロジェクトの複数ポリシーは同じLabel keyを共有します。
  • 管理はConsole、gcloud、APIに対応しますが、Terraformは将来対応予定です。
  • 自動関連付けは復元可能性を保証しません。定期的な復元テストが必要です。

今後注目すべき点

GA時のSLAとサポート範囲、Terraform Provider対応、対応リソースの拡大、ラベル条件の複合化、ポリシー当たりのScale上限を確認します。導入判断では「自動でBackupが付く」だけでなく、削除保護、Vault分離、保持期間、復元時間、監査ログを含めたRecovery設計として評価してください。

最終確認日:2026年9月22日

参照元

Previous Post Next Post