Azure Backup の新しい保管庫「Backup vault」で Vaulted backup を使うと、設定次第でクロスリージョン復元（Cross Region Restore / CRR）ができると思いがちです。しかし実際は Vault の設定だけで決まらず、データソース（ワークロード）側の対応状況が必須条件です。この記事では 2025年12月時点の対応状況と、Azure Blob で CRR が動かない理由を実務目線で整理します。
結論：Backup vault の CRR は「ワークロード対応」があるものだけ
Backup vault 側で Storage redundancy を Geo-Redundant（GRS） にし、さらに Cross Region Restore（CRR）を有効化していても、すべてのデータソースが自動的にセカンダリリージョンへ復元できるわけではありません。CRR の可否は、データソースの「復元機能」が CRR を実装しているかで決まります。
2025年12月時点で、Backup vault（Recovery Services vault ではない）＋Vaulted backup の前提で「クロスリージョン復元（CRR）」を 公式ドキュメント上で確認できる代表的なデータソースは次のとおりです。
用語メモ：ドキュメントやポータルの表記として Geo-redundant / Globally redundant と揺れることがありますが、いずれも「ペアリージョンへ冗長化する GRS」を指しているケースが多いです。CRR はこの GRS 前提で成り立ちます。
| データソース（代表） | Backup vault で Vaulted backup | CRR（クロスリージョン復元） | 補足（実務ポイント） |
|---|---|---|---|
| Azure Database for PostgreSQL（Flexible Server） | 対応 | 対応 | 復元は「ファイルとして出力」→ネイティブツールで新サーバーへ再構築、という流れが中心。 |
| AKS（Vault Tier / Vaulted AKS Backup） | 対応 | 対応 | Vault Tier の復旧ポイントがセカンダリ（ペア）リージョンへ複製され、災害時に Secondary Region から復元可能。 |
| Azure Blobs（Vaulted backup） | 対応（GA） | 未対応（公開ドキュメント上） | 復元は「別ストレージアカウントへ」可能だが、Backup vault の CRR としての Secondary Region 復元はドキュメント上確認できない。 |
| Azure Disks（Azure Disk Backup） | Operational Tier のみ | 未対応 | スナップショット（Operational）中心。Vault の冗長化設定は適用されず、「セカンダリリージョンへの復元」用途は VM Backup を推奨。 |
| Azure Database for MySQL（Flexible Server, preview） | Preview（新規構成は一時停止の案内あり） | 未提供 | 現状は「長期保管→ファイルとして出力」寄り。CRR を前提に設計しない。 |
| Azure Database for PostgreSQL（Single Server） | レガシー | 過去対応（ただしサービス退役） | Single Server は 2025/3/28 退役。新規検討対象にはしない（Flexible へ）。 |
前提整理：Backup vault と Recovery Services vault は “別物”
Azure Backup には「保管庫（vault）」が2系統あります。名前が似ているため、ここを取り違えると「ドキュメント通りにやったのに画面が違う」「CRR のメニューが出ない」といった混乱が起きがちです。
| 観点 | Backup vault | Recovery Services vault |
|---|---|---|
| 主な対象 | 新しめのワークロード（例：Azure Blobs の Vaulted backup、AKS、PostgreSQL など） | 従来の VM/ファイル系を中心（例：Azure VM backup など） |
| CRR の考え方 | Vault の CRR を有効化しても、ワークロード側が対応していないと復元できない | VM バックアップなど、従来から CRR の導線が確立しているワークロードが多い |
| 復元 UI の傾向 | Backup center / Business Continuity Center を経由する導線が多い | 保管庫（Recovery Services vault）の「バックアップ項目」から復元する導線が多い |
本記事は Backup vault の話です（Recovery Services vault ではありません）。同じ「CRR」という単語でも、対象ワークロードや UI が変わります。
CRR と CSR は別機能：Blob で「クロスサブスクリプション復元はできた」のに CRR はできない理由
実際の現場でいちばん混乱するのがここです。
- CRR（Cross Region Restore）：バックアップデータが Azure Paired Region（セカンダリリージョン）に複製され、一次リージョン障害時でもセカンダリ側から復元できる仕組み。
- CSR（Cross Subscription Restore）：復元先を 別サブスクリプションにできる仕組み（同一テナント内が前提）。
つまり、「別サブスクリプションへ復元できた」＝「CRR もできる」ではありません。Azure Blobs の Vaulted backup は、復元先として 別のストレージアカウント（サブスクリプションも選択可）を指定できる一方で、Backup vault の CRR でいう「Secondary Region からの復元」導線が確認できません。これが「CSR は動いたのに CRR が動かない」典型パターンです。
| やりたいこと | 該当する機能 | よくある勘違い | チェックポイント |
|---|---|---|---|
| リージョン障害に備え、ペアリージョンで復元したい | CRR | Vault を GRS にしただけで全部いけると思う | 復元ドキュメントに「Secondary region」や「Restore in secondary region」の記載があるか |
| 別サブスクリプションへ復元したい | CSR | CSR が動けば CRR も動くと思う | CRR と CSR の併用制限（ワークロード別）を確認する |
| 別ストレージアカウントへデータを出したい | ワークロード固有（例：Blob Vaulted restore） | 別リージョンのストアに出せる＝CRR と誤認 | 一次リージョンが落ちたときに「復元操作が実行できるか」まで想定する |
CRR 対応ワークロード：Azure Database for PostgreSQL（Flexible Server）
Backup vault の CRR を語る上で、いちばん “正攻法” なのが PostgreSQL です。PostgreSQL（Flexible Server）保護のサポートマトリクスでは、復元は Azure Paired region をまたいで可能、かつ 同一テナント内でのクロスサブスクリプション復元にも対応と整理されています。
PostgreSQL（Flexible Server）の復元イメージ
PostgreSQL の vaulted backup は、「そのまま別リージョンに “既存サーバーへ上書き復元”」というより、バックアップをファイルとして出力し、必要に応じて新しい PostgreSQL – Flexible Server へネイティブツールで戻す運用が中心です。サポートマトリクスでも、Vaulted backup の復元が “Restore to Files” ベースであることが明記されています。
この方式は一見遠回りですが、次のメリットがあります。
- リージョン障害・サブスクリプション障害の切り分けがしやすい（バックアップデータの持ち出し先をコントロールできる）
- 監査対応（「復元できること」を別環境でリハーサル）を回しやすい
- 復元先のネットワークやサーバー設定を、現行の設計方針に合わせて作り直せる
PostgreSQL の CRR で押さえるべき制約
- CRR は “ペアリージョン” への復元です。任意のリージョンではなく、Azure のペアに従います。
- CRR を有効化した直後は、セカンダリ側にバックアップが揃うまで時間がかかることがあります。
- 運用上は「一次リージョンが生きている平常時でも DR 訓練としてセカンダリへ復元できる」点が大きいです。
- 一部ドキュメントでは CRR と CSR の同時利用が非対応という注意書きがあります（復元先を “別リージョンかつ別サブスクリプション” にする、といった組み合わせ）。ワークロードと手順を必ず確認してください。
CRR 対応ワークロード：AKS（Vault Tier / Vaulted AKS Backup）
AKS は “バックアップが取れるだけ” では DR になりません。クラスタリソースと永続ボリュームを、災害時に別リージョンで再構築できることが重要です。Azure Backup の AKS バックアップは Vault Tier（Vaulted）を使うことで、セカンダリ（ペア）リージョンへバックアップを複製し、CRR で復元する設計が可能です。
AKS の CRR の特徴（運用で効くポイント）
- Vault Tier で 1日1回のスケジュール復旧ポイントが作られ、一次リージョンでの RPO は 24 時間。
- セカンダリリージョンへ複製されるまで最大 12 時間程度かかり、セカンダリ側の実効 RPO は最大 36 時間という整理になります。
- 災害時は Backup center 側の復元フローで Secondary Region を選ぶ導線が用意されています。
AKS で CRR を成立させる設計条件
AKS のドキュメントでは、CRR を使うには Backup vault を Globally Redundant（GRS）にし、Cross Region Restore を有効化しておく必要がある、と明示されています。
また、AKS バックアップは “運用設計の前提” も重要です。
- Backup vault と AKS クラスタは 同じリージョン・同じサブスクリプションが前提（少なくとも通常の保護・復元操作）。
- 別サブスクリプションへの復元（CSR）は、AKS ではサポートされない扱いになっています。
なぜ Azure Blobs（Vaulted backup）で CRR が “動かない” のか
Azure Blobs の Vaulted backup は 2024年に GA 化し、2025年末時点でも全パブリックリージョンで利用できる、と整理されています。
一方で、Blob の復元手順を見ると、Vaulted backup では 「別のストレージアカウントへ復元する」ことが明記されており、復元 UI も「復元先ストレージアカウント（とサブスクリプション）」を選ぶ流れになっています。ここには 「Secondary region から復元」という CRR の導線が登場しません。
また、Blob のサポートマトリクスは「対応リージョン」「対応シナリオ」「制約」を詳しく列挙していますが、CRR（セカンダリリージョン復元）の記載は確認できません。したがって、少なくとも 2025年12月時点の公開ドキュメント上は、Blob Vaulted backup が Backup vault の CRR で復元できる対象とは確認できません。
なお、過去の Microsoft Q&A では「Blob Vaulted Backups は次の CRR 対応ターゲットだが当時は未提供」という趣旨の回答がありました。ロードマップは変わり得るため、最終判断は Restore 手順とサポートマトリクスの記載で行うのが確実です。
「復元先を別リージョンのストレージアカウントにできる」＝CRR ではない
Blob の Vaulted restore は、復元先に別のストレージアカウントを選べます。極端な話、復元先ストレージアカウントが別リージョンに存在することもあり得ます。しかし、これは “CRR の Secondary Region から復元” とは意味が異なります。
- CRR：バックアップデータ自体がセカンダリに複製され、一次リージョン障害でもセカンダリ側から復元できる。
- Blob Vaulted restore：復元の出力先として別ストアを選べる（が、一次リージョン障害時にその操作が可能かは別問題）。
実務では、「一次リージョンが停止しても、バックアップの参照・復元操作ができるか？」まで含めて DR 設計を考える必要があります。CRR であればこの要件を満たしやすいですが、Blob の Vaulted backup は “CRR 対応ワークロードとしての確証” がないため、リージョン災害復旧の主軸に置くとギャップが出ます。
Blob Vaulted backup の制約も押さえておく
CRR の話から少し外れますが、Blob Vaulted backup は運用上ハマりやすい制約がいくつかあります。たとえば HNS 有効（ADLS Gen2 相当）のストレージアカウントが対象外、コンテナ数上限、オブジェクトレプリケーション（OR）ポリシーに関する注意点などです。バックアップ設計時に「そもそも保護できない」「初回バックアップが長い」などのトラブルを避けるため、サポートマトリクスを先に確認しておくと安全です。
Azure Disks は “Backup vault でも CRR でもない” ことが多い
Azure Disks については、「Backup vault がある＝Vaulted backup がある＝CRR できる」と連想しがちですが、Azure Disk Backup は性質が異なります。
Azure Disk Backup は スナップショット（Operational Tier）を自動で作成・ライフサイクル管理する仕組みで、ドキュメント上も Operational Tier のみをサポートし、Vault（保管庫ストレージ）へコピーしないと説明されています。したがって、Backup vault のストレージ冗長化（LRS/GRS）の設定は、ディスクバックアップのデータには適用されません。
さらに、Disk Backup の概要では「セカンダリリージョンへの復元が必要なら Azure VM Backup を使う」と明記されており、ディスク単体バックアップを CRR の用途に使うのは前提がずれることが読み取れます。
MySQL Flexible Server（Preview）は “CRR以前にプレビューが一時停止” の扱いに注意
Azure Database for MySQL – Flexible Server の長期保管（Azure Backup 経由）はプレビュー扱いで、ドキュメント上は 「現在プレビューソリューションは一時停止（paused）なので新規バックアップ構成を控える」という注意が出ています。既存データは保持されるものの、少なくとも新規設計で CRR を前提にする状態ではありません。
また、サポートマトリクスでも「Azure Backup による end-to-end の作成と復元は未サポート」と整理されており、現状は “バックアップデータをストレージへ出力して、ネイティブツールで再構築する” 寄りです。したがって、MySQL LTR を設計するなら、CRR ではなく別の DR 手段（サービス標準の geo-restore 等）と組み合わせて考えるのが現実的です。
PostgreSQL Single Server は 2025/3/28 で退役：CRR 以前に移行が必須
Azure Database for PostgreSQL – Single Server は 2025年3月28日に退役しました（Microsoft Lifecycle にも掲載）。現在は Flexible Server への移行が前提です。単に「CRR 対応かどうか」を考えるのではなく、まず Single Server を使い続けない設計へ変えるのが優先順位として高くなります。
もし過去に Single Server でバックアップを取っていた場合でも、退役後はサービス側の動作・サポート条件が変わります。Azure Backup 側でも Single Server 退役日に変更が入る旨が FAQ に記載されているため、運用している場合は必ず公式情報を確認してください。
実務的な見分け方：Restore ドキュメントで “Secondary region” を探す
「Backup vault を GRS＋CRR enabled にしたのに、復元できない」問題は、結局ここに収束します。ワークロードが CRR 対応かどうかを見分ける最短手順は次のとおりです。
- そのワークロードの Restore（復元）手順ページを開き、
secondary region/Restore in secondary region/Cross Region Restoreの記載があるか確認する。 - Azure portal の Backup center（または Business Continuity Center）の復元フローで、Instance Region や Secondary Region の選択が出るか確認する（出なければ未対応の可能性が高い）。
- サポートマトリクスに「Restores are supported across regions (Azure Paired)」のような文言があるか確認する。
ポイントは、Vault 側の設定だけでは決まらないことです。復元機能を実装しているのは各データソースであり、同じ Backup vault に保護していても “できる/できない” が混在します。
CRR 設計のチェックリスト：設定しても効かないケースを潰す
最後に、CRR を検討するときのチェックリストをまとめます。「全部設定したのにダメだった」を減らすための項目です。
補足として、CRR を有効化しても “すぐに” セカンダリ側で復旧ポイントが見えるとは限りません。ドキュメント上は、CRR 有効化後にバックアップ項目がセカンダリリージョンで利用可能になるまで 最大 48 時間かかる可能性がある、とされています（DR 訓練の直前に有効化するのは避けるのが無難です）。
| チェック項目 | 意図 | 落とし穴 |
|---|---|---|
| Backup vault の冗長化が GRS か | CRR の前提条件 | 後から変更できない/保護開始後に変更不可の制約がある |
| Backup vault の Cross Region Restore が Enable か | Secondary へ複製して復元できる状態にする | Enable してもワークロード非対応なら UI が出ない |
| 対象ワークロードが CRR 対応か | 復元導線の有無を確認 | 「同じ Backup vault だからいける」と思い込む |
| Secondary 側の RPO（複製遅延）を許容できるか | DR 目標の妥当性 | セカンダリの RPO は最大 36 時間という前提がある |
| CRR と CSR を同時に使う設計になっていないか | 併用制約の回避 | ワークロードによっては「別リージョン＋別サブスクリプション」が不可 |
まとめ：まず “CRR対応データソース” を起点に設計する
Backup vault の CRR は強力ですが、万能ではありません。特に Azure Blobs のように Vaulted backup 自体は GA でも、CRR の導線が未整備（少なくとも公開ドキュメントで確認できない）なケースがあります。逆に PostgreSQL（Flexible Server）や AKS（Vault Tier）では、DR を前提にした CRR の手順が用意されています。
DR 設計で迷ったら、次の順番で考えるとブレにくくなります。
- 保護したいデータソースは、Backup vault の Vaulted backup 対象か？
- そのデータソースは、復元手順に “Secondary region” が登場するか？
- RPO/RTO、復元先（同一/別サブスクリプション）、復元方式（直接/ファイル出力）まで含めて運用できるか？
「Vault の設定は全部正しいのに動かない」場合、原因はほぼ “データソース側の未対応” です。焦って設定を触る前に、Restore ドキュメントとサポートマトリクスから機能対応を確定させるのが、最短の解決策になります。
コメント