---
title: 'Google Cloudバックアップをラベルで自動化｜Backup and DR Auto-protection実践ガイド'
url: 'https://automationse.net/google-cloud-backup-dr-auto-protection-labels'
markdown: 'https://automationse.net/google-cloud-backup-dr-auto-protection-labels.md'
date: '2026-09-22'
description: '<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…'
taxonomy:
  category:
    - クラウド・インフラ
  tag:
    - 'Google Cloud'
    - 'Backup and DR'
    - 'Compute Engine'
    - クラウド運用
---

## [Google Cloudバックアップをラベルで自動化｜Backup and DR Auto-protection実践ガイド](https://automationse.net/google-cloud-backup-dr-auto-protection-labels)

  公開日 2026.09.22 更新日 2026.09.22  [Google Cloud](https://automationse.net/tag:Google%20Cloud#body-wrapper) [Backup and DR](https://automationse.net/tag:Backup%20and%20DR#body-wrapper) [Compute Engine](https://automationse.net/tag:Compute%20Engine#body-wrapper) [クラウド運用](https://automationse.net/tag:%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E9%81%8B%E7%94%A8#body-wrapper)  

 <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 projects**1ポリシー当たりの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 plan | Backup vault project | 保存先とスケジュール・保持ルールを定義 |
| Auto-protection policy | Backup vault project | Label、Region、Resource type、Planを対応付け |
| Policy binding | Project間 | どのWorkload projectへポリシーを適用するか指定 |
| VM / Disk | Workload project | ラベル条件に一致すると保護対象になる |

## 技術的なポイント

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

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

ただしPreviewでは、同じプロジェクトへ複数のAuto-protection policyを適用する場合、全ポリシーで**同じラベルキー**を使う必要があります。`env=prod`と`tier=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. 復元テスト後、対象プロジェクトを段階的に増やします。

```bash
# 対象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日

## 参照元

- [Google Cloud Release notes：2026年9月16日 Backup and DR](https://docs.cloud.google.com/release-notes#September_16_2026)
- [Google Cloud Docs：Automate resource protection](https://docs.cloud.google.com/backup-disaster-recovery/docs/protect/automate-protection)
- [Google Cloud API：AutoProtectionPolicies REST resource](https://docs.cloud.google.com/backup-disaster-recovery/docs/reference/rest/v1beta/projects.locations.autoProtectionPolicies)
- [Google Cloud Docs：Backup plans overview](https://docs.cloud.google.com/backup-disaster-recovery/docs/concepts/backup-plan)
- [Google Cloud Docs：Data protection options for disks and instances](https://docs.cloud.google.com/compute/docs/disks/data-protection)

  Previous Post Next Post

---

## Navigation

- Previous: [GitHub Actionsの実行保護がGA｜11月2日のpull_request_target遮断に備える](https://automationse.net/github-actions-workflow-execution-protections-ga.md)
- Next: [Zyxel GS1900がCISA KEV入り｜CVE-2026-7273を9月24日までに塞ぐ](https://automationse.net/zyxel-gs1900-cve-2026-7273-kev-patch-guide.md)