2026年5月7日に公開または更新された「Public Preview: Bulk Restore for Azure Virtual Machines using Azure Backup」は、Azure Backupで保護しているAzure VMを、最大100台までまとめて復元できるようにするプレビュー機能です。結論から言うと、障害対応やランサムウェア復旧訓練で「VMを1台ずつ復元する運用」を減らせる一方、Classic VM、非管理ディスク、暗号化VM、Confidential VM、クロスリージョン復元などは対象外です。Azure Storage管理者は、ステージング用ストレージアカウント、復元先サブネット、RBAC、復元後のVHDや権限の扱いを必ず確認しておく必要があります。(Microsoft Azure)
Azure Storage観点で見る「Bulk Restore for Azure Virtual Machines using Azure Backup」の要点
今回の変更は、Azure Storageそのものの新しいストレージ機能というより、Azure BackupによるAzure VM復元を大規模に扱いやすくする機能です。ただし、復元処理ではステージング用ストレージアカウント、復元ディスク、VHD、ネットワークアクセス設定が関係するため、Storage運用にも影響します。
Microsoft Learnでは、Azure BackupのBulk Restoreにより、Recovery Services vaultで保護されているAzure VMを最大100台まで、単一のガイド付き操作で代替場所へ復元できると説明されています。復元ポイントの時間範囲を指定し、共通の復元構成を設定しつつ、各VMの復元は個別のジョブとして追跡できます。(Microsoft Learn)
なお、ステータスは「In preview」です。Azure Updates上の「In preview」は、すべてのAzure顧客が非運用環境での使用やテストに利用できる段階と説明されています。したがって、本番DR手順へ即時に組み込むのではなく、検証環境で復元結果、権限、ネットワーク、コストを確認してから段階的に採用するのが現実的です。(Microsoft Azure)
何が変わるのか：複数VM復元を1つの操作で開始できる
従来、複数のAzure VMを復旧する場合、対象VMごとに復元ポイントを選び、復元先リソースグループ、仮想ネットワーク、サブネット、ストレージアカウントなどを指定する必要がありました。台数が増えるほど手作業が増え、設定ミスや復旧順序の混乱が起きやすくなります。
Bulk Restoreでは、Recovery Services vaultのバックアップ項目から複数VMを選択し、共通の復元パラメーターを適用してまとめて復元を開始できます。公式ドキュメントでは、復元ポイントのタブで時間範囲や個別VMの復元ポイントを調整し、復元パラメーターではターゲットリソースグループ、Virtual Network、Subnetなどの共通設定を指定する流れが示されています。(Microsoft Learn)
| 比較項目 | 従来の個別復元 | Bulk Restoreプレビュー |
|---|---|---|
| 操作単位 | VMごとに復元操作を実行 | 最大100台のVMを1回のガイド付き操作で復元 |
| 復元ポイント | VMごとに選択 | 時間範囲を指定し、必要に応じて個別VM単位で調整 |
| 復元先設定 | VMごとに指定 | リソースグループ、VNet、Subnetなどを共通設定として指定 |
| 進行状況の確認 | 個別ジョブを確認 | 一括操作の中で個別VMの復元ジョブを追跡 |
| 向いている場面 | 少数VMの復元、個別検証 | 大規模障害、ランサムウェア復旧訓練、複数VMのDR演習 |
実務上の価値は、「復元を速くする」だけではありません。復元手順を標準化しやすくなるため、夜間障害やインシデント対応時に、担当者ごとの差を減らせます。特に、同じアプリケーション群に属するWebサーバー、アプリケーションサーバー、踏み台サーバーなどをまとめて復旧する運用では、手順書を簡素化しやすくなります。
対象となる管理者・開発者
Bulk Restoreの確認が必要なのは、Azure Backup担当者だけではありません。復元時にはVM、ディスク、ストレージ、ネットワーク、ID、アプリケーションの依存関係が同時に動くため、複数ロールで事前確認が必要です。
| 立場 | 確認すべきポイント |
|---|---|
| Azure管理者 | Recovery Services vault、バックアップ対象VM、復元先リソースグループ、RBAC |
| Azure Storage管理者 | ステージング用ストレージアカウント、VHD残存、ネットワーク制限、ストレージコスト |
| ネットワーク管理者 | 復元先VNet、Subnet、NSG、IPアドレス、Private Endpoint、名前解決 |
| セキュリティ担当者 | プレビュー利用可否、権限分離、復元後のRBAC再付与、監査ログ |
| アプリ開発者 | アプリの起動順序、DB接続先、証明書、シークレット、ドメイン参加、整合性確認 |
特にAzure Storage管理者は、「VMの復元だからStorageは関係ない」と考えないほうがよいです。Vault-Standardの復元ポイントから復元する場合、条件によってVHDファイルやテンプレートがステージング用ストレージアカウントに作成されます。不要なVHDを削除しないと、余分なストレージ課金が残る可能性があります。(Microsoft Learn)
利用前に確認すべき制限事項
Bulk Restoreは便利ですが、すべてのAzure VMで使えるわけではありません。公式ドキュメントでは、Classic、Unmanaged、Encrypted、Confidential virtual machinesはBulk VM restoreの対象外とされています。また、クロスリージョン復元、つまりCRRシナリオではBulk VM restoreはサポートされません。(Microsoft Learn)
| 確認項目 | 注意点 |
|---|---|
| 最大台数 | 最大100台までの保護済みAzure VMを一括復元 |
| 復元先 | 代替場所への復元を前提にしたガイド付き操作 |
| 対象外VM | Classic VM、Unmanaged VM、Encrypted VM、Confidential VM |
| CRR | Cross Region Restoreシナリオでは非対応 |
| サブネット | ターゲットサブネットは/16またはそれより小さいサブネットマスクが必要 |
| ステータス | Public Previewのため、本番利用前の検証が必須 |
ここで見落としやすいのがサブネット条件です。一般的な業務システムでは/24などの小さなサブネットを使っているケースがありますが、Bulk Restoreではターゲットサブネット条件に合わない可能性があります。復元演習の直前に気づくと手戻りが大きいため、対象VNetとSubnetは事前に棚卸ししておきましょう。
Azure Storage管理者が重点的に見るべき設定
ステージング用ストレージアカウントのリージョンと種類
Azure VM復元では、ステージング用ストレージアカウントが関係する場合があります。公式ドキュメントでは、ストレージアカウントはRecovery Services vaultと同じリージョンに存在する必要があり、該当リージョンのアカウントのみが表示されると説明されています。また、Blob Storageアカウントはサポートされないとされています。(Microsoft Learn)
確認すべきポイントは次の通りです。
- Recovery Services vaultと同一リージョンに利用可能なストレージアカウントがあるか
- ストレージアカウントのネットワーク制限が復元処理を妨げないか
- 復元後に不要なVHDや一時ファイルを削除する運用があるか
- ZRSなど冗長性の指定が社内ポリシーに合っているか
- ストレージアカウントへの権限付与が最小権限になっているか
特に、復元テスト後のクリーンアップは軽視されがちです。復元先VMだけ削除しても、ステージング用ストレージアカウントにVHDが残っていれば課金対象になります。検証手順書には「復元ジョブ確認」「VM確認」「不要ディスク削除」「不要VHD削除」「一時リソースグループ削除」まで含めるべきです。
RBACとマネージドID
復元操作では、Recovery Services vaultだけでなく、復元先リソースグループ、ネットワーク、ストレージアカウントに対する権限が必要です。公式ドキュメントでは、成功する復元操作のために、ステージング場所であるStorage AccountとターゲットResource GroupへVM restore operatorロールを割り当てる方法が示されています。(Microsoft Learn)
実務では、次のような権限不足が起きやすくなります。
| よくある権限不足 | 起きる問題 | 対策 |
|---|---|---|
| ストレージアカウントへの権限不足 | ステージング処理やVHD操作で失敗 | 復元前にStorage Accountスコープのロールを確認 |
| サブネット参加権限の不足 | NIC作成やVM復元先ネットワーク設定で失敗 | VNet/Subnetへのjoin権限を確認 |
| リソースグループへの書き込み権限不足 | VM、ディスク、NICなどを作成できない | ターゲットRGに必要なロールを付与 |
| 最小権限の設計不足 | 復元担当者に過剰権限を付与してしまう | 復元専用ロールや一時的なPIM利用を検討 |
復元は緊急時に実行されることが多いため、普段の運用では権限不足に気づきにくい作業です。平時の復元テストで、担当者の実アカウントまたは運用用IDを使って検証することが重要です。
復元ディスクのネットワークアクセス設定
バックアップ対象VMがPrivate Endpoint有効ディスクなどを使っている場合、復元ディスクのアクセス設定も確認が必要です。Azure Backupでは、復元後のディスクアクセス設定として、元ディスクと同じネットワーク構成を使う、すべてのネットワークからのパブリックアクセスを有効にする、Disk Accessを使ってプライベートアクセスを有効にする、といった選択肢が示されています。(Microsoft Learn)
ただし、復元時に安易にパブリックアクセスを許可すると、復旧作業後のセキュリティレビューで問題になりやすいです。検証環境では利便性を優先しても、本番復旧手順では「どのディスクをどのネットワークからアクセス可能にするか」を明文化しておきましょう。
Bulk Restoreの基本的な実行手順
Azure portalでのBulk Restoreは、Recovery Services vaultから開始します。公式ドキュメントでは、Protected items、Backup itemsへ進み、Backup Management TypeとしてAzure Virtual Machineを選択し、復元したいVMを複数選んで「Bulk restore (Preview)」を実行する流れが説明されています。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前準備 | 対象VM、復元先RG、VNet、Subnet、Storage Accountを確認 | 対象外VMやサブネット条件を先に除外 |
| VM選択 | Recovery Services vaultのBackup itemsから複数VMを選択 | 最大100台、同じ復元目的のVMに絞る |
| 復元ポイント設定 | 時間範囲を指定し、必要に応じてVMごとに編集 | アプリ整合性や依存関係を確認 |
| 復元パラメーター設定 | ターゲットRG、VNet、Subnetなどを指定 | 共通設定で問題ないVMだけをまとめる |
| 事前検証 | Validation pre-checksで構成を確認 | エラーが出たVMは原因を切り分ける |
| 復元開始 | Review + restoreで実行 | 個別VMの復元ジョブを監視 |
| 復元後確認 | VM起動、通信、権限、アプリ動作を確認 | 不要なVHD、ディスク、NICを整理 |
一括復元といっても、すべてのVMを無条件に同じ設定で復元すべきではありません。Web層、アプリ層、管理用VMなど、復元先ネットワークや優先順位が近いVMをグループ化すると、失敗時の切り戻しや原因調査がしやすくなります。
復元後に必ず確認すべきこと
復元が完了しても、そのまま本番相当の稼働状態になるとは限りません。公式ドキュメントでは、復元後の注意点として、バックアップ構成時に存在した拡張機能はインストールされるが有効化されない場合があること、新しいVMとして復元した場合は元VMスコープのRBACロール割り当てが引き継がれないこと、静的IPだったVMも競合回避のため動的IPになることなどが説明されています。(Microsoft Learn)
復元後チェックリストとして、最低限次を確認しましょう。
- VMが起動しているか
- NIC、IPアドレス、NSG、ルートテーブルが想定どおりか
- DNS名、Private DNS、アプリ接続先が正しいか
- Azure VM拡張機能、監視エージェント、セキュリティエージェントが有効か
- RBAC、マネージドID、Key Vaultアクセスが再設定されているか
- ドメイン参加や認証基盤との接続に問題がないか
- 復元後VMのバックアップが再度有効になっているか
- ステージング用ストレージアカウントに不要なVHDが残っていないか
特にRBACの引き継ぎは重要です。復元後VMが新しいリソースとして作成された場合、元VMに直接付与されていた権限は自動的に移りません。運用チーム、監視システム、デプロイパイプラインが対象VMへアクセスできるかを確認してください。
開発者が注意すべきアプリケーション側の落とし穴
Bulk Restoreはインフラ復元を効率化する機能ですが、アプリケーション全体の復旧を自動保証するものではありません。複数VMをまとめて戻しても、データベース、キャッシュ、メッセージキュー、認証基盤、外部APIとの整合性が取れていなければ、サービスは正常に戻りません。
開発者やアプリ運用担当者は、次の観点で復旧手順を見直す必要があります。
| 観点 | 確認内容 |
|---|---|
| 起動順序 | DB、アプリ、Web、バッチ、監視の順番に依存がないか |
| 復元ポイント | VMごとに異なる時点へ戻した場合、データ整合性に問題がないか |
| シークレット | Key Vault、証明書、接続文字列、環境変数が復元後も有効か |
| 名前解決 | DNS、Private DNS Zone、hosts、ロードバランサーの向き先が正しいか |
| セッション | 復元後に古いセッション情報やキャッシュが障害を起こさないか |
| CI/CD | 復元後VMをデプロイ対象として再登録する必要があるか |
| 監視 | 復元後のVMが監視、ログ収集、アラート対象に戻っているか |
ランサムウェア対応を想定する場合は、「何時点のVMに戻すか」だけでなく、「安全な復元ポイントをどう判断するか」も重要です。Bulk Restoreは複数VMの復元操作をまとめる機能であり、感染していない復元ポイントの選定やアプリケーションデータの検証は、別途プロセスとして用意する必要があります。
失敗しやすいポイントと回避策
Bulk Restoreの導入時に失敗しやすいのは、機能そのものの操作よりも、周辺設定の見落としです。特にプレビュー段階では、手順書に「できること」だけでなく「できないこと」を明記しておく必要があります。
| 失敗しやすいポイント | 起きること | 回避策 |
|---|---|---|
| 対象外VMを含めて選択する | 事前検証で失敗、または一部VMを復元できない | Classic、Unmanaged、Encrypted、Confidential VMを事前に棚卸し |
| CRR用途で使おうとする | クロスリージョン復元では利用できない | CRRは従来の復元手順を維持 |
| 小さすぎるサブネットを指定する | ターゲットサブネット条件で失敗する可能性 | 復元専用VNet/Subnetを事前作成 |
| ストレージアカウントのリージョンが違う | ステージング場所として選択できない | vaultと同一リージョンに用意 |
| ストレージの後片付けを忘れる | VHDや一時ファイルの課金が残る | 復元後チェックリストに削除作業を追加 |
| RBACを本番直前に確認する | 緊急時に復元できない | 復元担当者の実権限で定期テスト |
| 復元後のIP変更を見落とす | アプリや監視が接続できない | DNS、LB、FW、監視設定を復元後手順に含める |
導入判断の目安
Bulk Restoreを使う価値が高いのは、同一Recovery Services vaultで保護している複数VMを、同じ復元先環境へまとめて戻したいケースです。たとえば、検証用DR環境への定期復元、ランサムウェア復旧訓練、部門システム単位の復旧演習などでは、作業時間と手順のばらつきを減らせます。
一方で、次のような環境では慎重に判断してください。
- VMごとに復元先ネットワークやセキュリティ設定が大きく異なる
- 暗号化VMやConfidential VMが多い
- クロスリージョン復旧を主目的にしている
- サブネット設計が細かく、復元先に
/24などを使っている - アプリケーションの整合性確認手順がまだ整っていない
- 復元後の権限、監視、バックアップ再設定を自動化できていない
プレビュー段階では、既存の個別復元手順を置き換えるのではなく、「大規模復元の選択肢を増やす」位置づけで導入するのが安全です。小規模な検証から始め、対象VMの条件、復元時間、失敗時の切り分け、クリーンアップ手順を確認してから、DRランブックに反映しましょう。
管理者が次に取るべきアクション
まずは、Azure Backupで保護しているVMの一覧を作り、Bulk Restoreの対象にならないVMを洗い出してください。次に、復元専用のリソースグループ、VNet、Subnet、ステージング用ストレージアカウントを用意し、2〜5台程度の小さな単位で復元テストを実施します。
テストでは、復元が成功したかだけでなく、次の結果を記録しましょう。
- 復元にかかった時間
- 事前検証で出た警告やエラー
- 復元後に変更されたIP、権限、拡張機能
- ステージング用ストレージアカウントに残ったデータ
- アプリケーション起動までに必要だった手動作業
- 監視、バックアップ、セキュリティ設定の再適用手順
Bulk Restoreは、大規模復旧の初動を標準化するうえで有用な機能です。ただし、VMをまとめて戻せることと、業務システムを安全に再開できることは別です。Azure Storage、ネットワーク、ID、アプリケーションの担当者を巻き込み、復元前の条件確認、復元中の監視、復元後のクリーンアップまで含めた手順に落とし込むことが、実運用で失敗しないための最短ルートです。
コメント