Azure VMをRubrik Security Cloud（以下、RSC）でバックアップしている。
Snapshotも正常に取得できている。
それなら、いざというときも安心でしょうか。
実際の運用では、
「VMを丸ごと戻せる」だけでは足りない
ケースが少なくありません。
例えば、
「SQL Serverが動いているVMなので、バックアップ時にアプリケーションの整合性を取りたい」
「ユーザーが昨日削除したExcelファイル1個だけ戻したい」
「数十TBあるVM全体ではなく、特定フォルダだけ復旧したい」
といった要件です。
そこで登場するのが、
Application-Consistent Backup
File Indexing
File-Level Recovery
Rubrik Backup Service（RBS）
Exocompute
です。
ところが、これらは通常のAzure VM Snapshotと同じ条件で使えるわけではありません。
例えばPremium SSD v2やUltra DiskはVM Backupには対応していますが、File-Level Recovery / Indexingには対応していません。Azure Disk Encryption（ADE）を利用したVMにもIndexing制約があります。
今回は、
「VM Backupが○だから、必要な復旧機能も全部○」とは限らない
という観点から、Rubrik × Azure VMの高度な保護・復旧機能を整理します。
※本記事は2026年9月時点のRubrik公開情報をもとに整理しています。ExocomputeやAzure Cloud Native Protectionは更新頻度が高いため、実環境への導入時には最新のRubrik Documentation / Compatibility Matrixも確認してください。
1. まず「VM Backup」と「高度な保護」を分けて考える
基本的なAzure VM保護では、RSCがAzure Native APIを利用してManaged Disk Snapshotを取得します。
概念的には、
Azure VM
│
├─ OS Managed Disk
└─ Data Managed Disk
│
▼
Azure Snapshot
│
▼
Rubrik Security Cloud
です。
しかし、ここから先の高度機能になると構成が変わります。
Azure VM
│
▼
Snapshot
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
VM Restore File Indexing App Consistency
│ │
└─────┬───────┘
▼
Exocompute
│
┌──────────┴─────────┐
▼ ▼
File Recovery RBS
ExocomputeはAKSを利用したRubrikのCompute基盤で、File Indexing、File Recovery、Application-Consistent Backup、Storage Tieringなどの処理をAzure Subscription内で実行します。
この違いを最初に理解しておくことが重要です。
2. Crash ConsistentとApplication Consistentは何が違う？
まずBackupの「整合性」を整理します。
Crash-Consistent Backupは、ある時点のDisk状態を取得します。
概念的には、
Application
│
│ I/O実行中
▼
Managed Disk
│
▼
Snapshot
です。
OSやApplicationの観点では、
突然電源が落ちた後に起動する状態
に近いと考えると分かりやすいでしょう。
一方Application-Consistent Backupでは、Snapshot取得前にApplicationやFile Systemの処理を整えます。
Application
│
▼
Windows VSS
│
Flush / Quiesce
│
▼
Managed Disk
│
▼
Snapshot
RubrikのAzure VM向けApplication ConsistencyではWindows Volume Shadow Copy Service（VSS）が利用されます。Application-Consistent BackupはApplicationの稼働状態を保持するための機能として提供されています。
3. Azure VMではApplication ConsistencyはデフォルトOFF
ここは重要です。
RSCのAzure VM Cloud Native Protectionでは、
Application Consistencyはデフォルトでは無効
です。
つまり、
Azure VMをSLA Domainで保護
↓
Application Consistentになる
と自動的に考えてはいけません。
Application Consistencyが必要なVMでは、対象VMごとにRSCから有効化する必要があります。
4. Azure VMのApplication Consistencyに必要なもの
Azure VMでApplication-Consistent Backupを利用するためには、主に次の構成が必要です。
| コンポーネント | 役割 |
|---|---|
| Windows Azure VM | Application Consistency対象 |
| Windows VSS | Application / I/Oの整合性 |
| Rubrik Backup Service（RBS） | VM内とRubrikの連携 |
| Exocompute | Backup処理のCoordinator |
| RSC | Protection Policy / Orchestration |
Rubrikの現行ドキュメントでは、Azure VM向けApplication-Consistent BackupはWindows VM＋登録済みRBS＋VSSで提供されます。また対象Azure AccountにはExocomputeの構成が必要です。
概念図にすると、
Rubrik Security Cloud
│
▼
Exocompute
Temporary Compute
│
▼
Azure Windows VM
│
├─ RBS
│
▼
Windows VSS
│
▼
Application
となります。
5. Linux VMでは同じApplication Consistency方式ではない
上記のAzure Cloud Native Application-Consistent Backupは、Rubrikの公開手順上、
Windows VMでRBSとWindows VSSを利用する機能
です。
したがってLinux VMで、
Oracle Database
PostgreSQL
SAP HANA
MySQL
などを動かしている場合、
「Azure VMのApplication ConsistencyをONにすればDatabase Backupも完全」
と考えてはいけません。
DatabaseとしてPoint-in-Time Recovery、Archive Log、Transaction Logなどが必要なら、
VM Protection
+
Database Native Protection
を別々に検討する必要があります。
これは以前の基礎編でも触れた、
VMを戻せることとDatabaseを任意時点へ戻せることは別
という考え方です。
6. Application-Consistent BackupでもDB Native Backupとは違う
例えばSQL Server VMを考えます。
Azure VM
└─ Windows Server
└─ SQL Server
Application-Consistent Snapshotを使えば、VSSを利用してより整合性の高いVM Recovery Pointを作れます。
しかし、
10:00 Full Snapshot
10:27 障害
が発生した場合に、
10:26:58
までSQL Serverを戻したいのであれば、VM SnapshotだけではなくSQL ServerのLog Backup / Point-in-Time Recoveryが必要になります。
したがって、
Application Consistent VM Snapshot
≠
Database Native PITR
です。
Application Consistencyは非常に有効ですが、Database Protectionの代替ではなく、Recovery要件によって併用するものと考える方が分かりやすいでしょう。
7. Application ConsistencyではExocomputeが必要
ExocomputeはAzure Kubernetes Service（AKS）を利用するRubrikの処理基盤です。
RSCは必要な処理に応じてAKS上にWorkerを起動し、
- File Indexing
- File Recovery
- Application-Consistent Backup
- Azure Storage Tiering
を実行します。
そのため、
普通のVM Backup
だけを見ているとExocomputeの存在を意識しないことがあります。
ところが、
VM Backup
↓
もっと高度なRecoveryが必要
↓
Exocomputeが必要
となります。
8. Exocomputeは「RubrikのSaaS側だけ」で動くわけではない
ExocomputeではAzure Subscription内にAKSなどのAzure Resourceが作成されます。
Rubrik-managed AKSの場合、AKS用Resource GroupやNode Resource Groupが作られ、Node、Virtual Network、StorageなどのAzure Infrastructure Resourceが利用されます。
つまり、
RubrikはSaaSだから、Azure側には何も作られない
という理解は正しくありません。
基本的なCloud Native Snapshotと、Exocomputeを使う高度処理は分けて考える必要があります。
9. ExocomputeにはAzure vCPU Quotaも必要
Exocomputeが実際にAzure VMを起動する以上、Azure側のCompute Quotaが必要です。
Rubrikは用途ごとに必要となるVM Familyを公開しています。
代表例は次の通りです。
| Exocompute用途 | Rubrikが利用する代表VM Type |
|---|---|
| Indexing / Archiving | Standard_D8s_v4 |
| File-Level Recovery / Archive Recovery | Standard_D16s_v5 |
| Application Consistency | Standard_B2ms |
RubrikはExocompute用のvCPU Quotaが不足すると、処理が中断・失敗する可能性があるため、事前に十分なQuotaを確保するよう案内しています。
つまり、
Production VM用Quota
○
Exocompute用Quota
×
なら、高度機能を正常に利用できない可能性があります。
10. Exocomputeではネットワーク設計も必要
ExocomputeにはVNet / Subnetも必要です。
また、
- AKS Node
- RSC
- Azure API
- Container Registry
- DNS
- Firewall
- NSG
などの通信を成立させる必要があります。
RubrikはExocomputeのNetwork Setupで、Inbound / Outbound通信、NSG、Firewall、Azure CNIなどの設定を要求しています。さらに、Exocompute用AKSのVNet / SubnetではDeep Packet Inspection（DPI）を無効化するよう明記しており、DPIが有効だとExocompute Health Checkが失敗する可能性があります。
これは企業Azure環境では意外な落とし穴です。
11. Azure PolicyもExocomputeを止めることがある
セキュリティ編ではAzure Policyについて説明しましたが、Exocomputeでも影響します。
例えば企業Policyとして、
すべてのAzure Resourceに
特定Tagを必須化
している場合です。
RubrikのTroubleshooting Documentでも、Required Tag PolicyによってAKS Resource作成が拒否され、
RequestDisallowedByPolicy
となるケースが紹介されています。
つまりExocomputeでは、
Quota
Network
Azure Policy
Capacity
IP Address
まで確認する必要があります。
12. File Indexingとは何か
次はFile Recoveryです。
Azure VMのSnapshotには、多数のファイルが含まれています。
例えば、
C:
├─ Windows
├─ Program Files
└─ Users
D:
├─ Data
├─ Documents
└─ Application
があります。
このSnapshotから、
「report.xlsxはどこにある？」
を検索するには、Snapshot内部のFile System情報を解析する必要があります。
これがFile Indexingです。
RSCはExocomputeを利用してManaged Disk SnapshotからFile System Metadataを取り出し、個々のFile / Folderを検索・Recoveryできるようにします。
13. File IndexingはデフォルトOFF
ここも重要です。
Azure VM / Managed DiskのFile Indexingはデフォルトでは無効
です。
したがって、
VM Snapshotあり
↓
すぐFile Search可能
とは限りません。
RSCでは大きく2つの方法があります。
| 方法 | 特徴 |
|---|---|
| 必要なSnapshotだけIndex | Recovery時に対象SnapshotをIndex |
| 全SnapshotをIndex | Backup後に継続的にIndex |
Rubrikは、必要な特定SnapshotをRecovery時にIndexする方式を推奨オプションとして案内しています。全Snapshot Indexingを有効にすると検索は高速になりますが、すべてのBackupについてIndex処理が行われます。
14. 「全部Indexする」必要があるか考える
例えば毎日Backupを取得していて、
30日保持
しているVMなら、30日分のSnapshotすべてをIndexする設計もできます。
メリットは、
「ファイル名は分かるが、いつ削除されたか分からない」
という場合です。
report.xlsx
↓
全Indexed Snapshotを検索
↓
9月1日 ○
9月2日 ○
9月3日 ○
9月4日 ×
↓
9月3日のSnapshotからRecovery
といった運用がしやすくなります。
一方でIndexingはExocompute処理なので、
Recovery要件
+
Compute / Quota / Cost
のバランスで決める必要があります。
15. Azure Storage Tiering利用時はIndexingの挙動が違う
通常File IndexingはデフォルトOFFですが、例外があります。
Rubrikでは、
Azure Storage TieringをArchiving用途で構成している場合、File Indexingはデフォルトで有効
としています。
そのため、
Indexingを明示的にONにした覚えがない
環境でも、Storage Tiering構成によってIndexing処理が動作している可能性があります。
16. File-Level RecoveryにはDisk Type制約がある
Disk編で説明した重要ポイントです。
| Azure Disk | Backup | File Recovery / Indexing |
|---|---|---|
| Standard HDD | ○ | ○ |
| Standard SSD | ○ | ○ |
| Premium SSD | ○ | ○ |
| Premium SSD v2 | ○ | × |
| Ultra Disk | ○ | × |
Premium SSD v2およびUltra Diskについては、Backup、Archive、Replication、VM/Disk Restoreはサポートされていますが、File-Level Recovery / Indexingはサポートされません。
つまり、
VM Backup ○
でも
File Recovery ×
です。
17. Azure Disk EncryptionでもIndexing制約がある
セキュリティ編で紹介したAzure Disk Encryption（ADE）にも注意が必要です。
ADE VMについてRubrikはBackup、Archive、Replicationをサポートしていますが、
Indexingは非対応
です。
したがって、
Disk Type = Premium SSD
↓
本来Indexing ○
しかし
ADE enabled
↓
Indexing ×
というように、Disk Typeだけでは判断できません。
18. File Systemにも制約がある
Disk自体が対応していても、Disk内部のFile Systemが非対応ならIndexingできません。
現行Rubrik Compatibility Matrixで、代表的な対応状況を抜粋すると次のようになります。
| File System /構成 | Indexing |
|---|---|
| NTFS | ○ |
| Ext2 / Ext3 / Ext4 | ○ |
| XFS | ○ |
| BTRFS | ○ |
| LVM Volume | ○ |
| LDM Volume | ○ |
| ReFS | × |
| exFAT | × |
| ZFS | × |
| Windows Storage Spaces | × |
| LVM Thin Provisioned Volume | × |
RubrikはAzure VM / Managed DiskのIndexingについて、上記のようなFile System制約を公開しています。
ここでも、
Managed Disk ○
Premium SSD ○
だけでは判断できません。
19. Storage PoolもFile Recovery非対応
Azure Managed Diskを複数まとめてStorage Poolとして利用している場合にも注意が必要です。
Rubrikは、
Azure Managed DiskでStorage Poolを利用している構成はFile Recovery非対応
としています。
例えば、
Managed Disk 1 ─┐
Managed Disk 2 ─┼─ Storage Pool
Managed Disk 3 ─┤
Managed Disk 4 ─┘
│
▼
Volume
の場合、
VM Backup ○
VM Restore ○
File Recovery ×
となる可能性があります。
20. File Recoveryには複数の方法がある
RSCではAzure VM / Managed DiskのRecovery方法として複数の選択肢があります。
| Recovery方式 | 用途 |
|---|---|
| VM Restore | VM全体を元に戻す |
| Virtual Disk Mount | 特定DiskをVMへMount |
| File / Folder Download | File / FolderをAzure Storage Accountへ出力 |
| In-place File Recovery | VMへ直接File / Folderを戻す |
RubrikはAzure VMのRecovery Optionとして、VM Restore、Virtual Disk Mount、File / Folder Download、In-place File Recoveryなどを提供しています。
21. In-place File Recoveryとは
In-place File Recovery（IFR）は、Snapshotから選択したFile / Folderを、
元VM
または、
別VM
へ直接Recoveryする機能です。
Recovery方法には、
Overwrite existing
既存File / Folderを上書きします。
Recover
Source VM内の別PathへRecoveryします。
Export
別のAzure VMへFile / FolderをRecoveryします。
VM全体を戻さず、必要なFileだけ直接戻せるのが大きなメリットです。
22. In-place File RecoveryにはRBSが必要
通常のAzure VM SnapshotにはRBSを必須としません。
しかしIFRでは、
Recovery先VMにRubrik Backup Service（RBS）が必要
です。
ここは重要な設計ポイントです。
Basic VM Backup
↓
RBS必須ではない
In-place File Recovery
↓
RBS必要
つまり、将来IFRを使う可能性があるなら、
障害が起きてからRBSをどうするか
ではなく、平常時からDeployment / Registration方法を決めておく方が運用しやすくなります。
23. IFRにはネットワーク要件もある
IFRではRBSだけでは足りません。
RubrikのPrerequisiteでは、
- Exocompute構成済み
- VM VNetとExocompute VNetが同一、またはPeering済み
- Exocompute Network要件を満たす
- RBSをVMへ構成
- File Indexingを有効化
- Recovery可能なSnapshotが存在
することが求められています。
つまり、
Snapshot
○
RBS
○
でも
Network
×
ならIFRは成立しません。
24. File Recovery設計では「どこへ戻すか」も決める
例えばUserが、
D:\Project\report.xlsx
を削除したとします。
選択肢は少なくとも3つあります。
① 元のPathへ上書き
D:\Project\report.xlsx
② 別PathへRecovery
D:\Restore\report.xlsx
③ 別VMへExport
Recovery-VM
D:\Restore\report.xlsx
本番Serverへ直接Overwriteする方法は速い反面、誤RecoveryのRiskがあります。
そのため運用Runbookでは、
まず別PathへRecoveryしてApplication Ownerに確認してもらう
など、Recovery方法まで決めておくのがおすすめです。
25. ExocomputeはSubscription / Regionも意識する
File Indexingに利用するExocomputeは、対象Azure VM / Managed DiskのSubscriptionおよびRegionに対応した構成が必要です。
RubrikはExocomputeが特定のAzure Region / Subscriptionに紐づくため、対象Workloadに適切なExocompute設定が必要としています。
例えば、
Subscription-A
Japan East
VM-A
と、
Subscription-B
Japan West
VM-B
がある場合、
一つ作れば無条件に全Subscription / Regionの高度処理を実行できる
とは考えない方がよいでしょう。
RubrikではLocalized / Centralized Exocomputeなど複数のDeployment Modelを選択できます。
26. 「Exocomputeを使わない設計」も選択肢
すべてのVMで高度機能が必要とは限りません。
例えば、
Stateless Web Server
IaCから再構築可能
個別File Recovery不要
なら、
VM Backup
+
VM Restore
だけで十分な場合があります。
一方、
File Server
大量のUser File
誤削除Recoveryが多い
なら、
File Indexing
+
IFR
の価値が高くなります。
そして、
Windows Application Server
Transaction処理あり
なら、
Application Consistency
を検討します。
つまり、
すべてのVMへすべての高度機能をONにするのではなく、Recovery要件から逆算する
ことが重要です。
27. VMタイプ別に考えると分かりやすい
例えば、次のように分類できます。
| VM用途 | VM Backup | App Consistency | File Indexing | IFR |
|---|---|---|---|---|
| Stateless Web | ○ | △ | △ | △ |
| Windows Application | ○ | ○検討 | ○検討 | ○検討 |
| File Server | ○ | △ | ○ | ○ |
| SQL Server VM | ○ | ○検討 | △ | △ |
| Infrastructure Server | ○ | 要件次第 | 要件次第 | 要件次第 |
ポイントは、
機能を基準にVMを合わせるのではなく、Recovery Requirementから必要機能を決める
ことです。
28. 高度機能を使う前に確認する5段階
今回の内容を実際の設計手順にすると、次の順番が分かりやすいと思います。
STEP 1
VM全体を戻せればよい？
│
▼
STEP 2
Application Consistencyが必要？
│
▼
STEP 3
File-Level Recoveryが必要？
│
▼
STEP 4
Disk / File Systemは対応している？
│
▼
STEP 5
Exocompute / RBS / Network / Quotaを準備
この順序にすると、
「とりあえず全部Indexingしておこう」
のような過剰構成を防ぎやすくなります。
29. 高度機能編チェックリスト
| # | 確認項目 | Check |
|---|---|---|
| 1 | VM全体Restoreだけで要件を満たせるか | ☐ |
| 2 | Application Consistencyが必要か | ☐ |
| 3 | 対象はWindows VMか | ☐ |
| 4 | Windows VSSを利用できるか | ☐ |
| 5 | RBSをInstall / Registerできるか | ☐ |
| 6 | Application ConsistencyをRSCで有効化したか | ☐ |
| 7 | DB Native Backupが別途必要ではないか | ☐ |
| 8 | Exocomputeを構成したか | ☐ |
| 9 | Exocompute用vCPU Quotaを確保したか | ☐ |
| 10 | Exocompute用VNet / Subnetを準備したか | ☐ |
| 11 | NSG / Firewall要件を満たしているか | ☐ |
| 12 | Azure PolicyがAKS作成を阻害しないか | ☐ |
| 13 | DPIが有効になっていないか | ☐ |
| 14 | File-Level Recoveryが必要か | ☐ |
| 15 | File Indexingが必要か | ☐ |
| 16 | 全Snapshot Indexingが本当に必要か | ☐ |
| 17 | Premium SSD v2を利用していないか | ☐ |
| 18 | Ultra Diskを利用していないか | ☐ |
| 19 | ADEを利用していないか | ☐ |
| 20 | File SystemがIndexing対応か | ☐ |
| 21 | ReFS / ZFS / exFATではないか | ☐ |
| 22 | Windows Storage Spacesではないか | ☐ |
| 23 | LVM Thin Provisioningではないか | ☐ |
| 24 | In-place File Recoveryが必要か | ☐ |
| 25 | Recovery先VMにRBSがあるか | ☐ |
| 26 | VMとExocomputeのVNetが通信可能か | ☐ |
| 27 | Overwrite / Recover / Exportのどれを使うか決めたか | ☐ |
| 28 | File Recovery Runbookを作成したか | ☐ |
| 29 | Recovery Testを実施したか | ☐ |
| 30 | 最新Compatibility Matrixを確認したか | ☐ |
30. まとめ
今回最も重要なのは、
「Azure VMのBackupが成功している」ことと、「必要な粒度でRecoveryできる」ことは別
という点です。
通常のVM Backupは、
Azure VM
↓
Managed Disk Snapshot
↓
VM Restore
です。
しかしApplication Consistencyが必要なら、
Windows VM
+
RBS
+
VSS
+
Exocompute
が必要になります。Application ConsistencyはAzure VMではデフォルト無効です。
File Recoveryが必要なら、
Supported Disk
+
Supported File System
+
File Indexing
+
Exocompute
を確認します。
さらにIn-place File Recoveryなら、
Exocompute
+
RBS
+
VNet Connectivity
+
Indexed Snapshot
まで必要です。
そして、
Premium SSD v2
Ultra Disk
ADE
Storage Pool
ReFS
ZFS
Windows Storage Spaces
などでは機能制限があります。
つまり、
Backupできる？
↓
Application整合性は必要？
↓
File単位で戻したい？
↓
Disk Typeは対応？
↓
File Systemは対応？
↓
Exocomputeはある？
↓
RBSはある？
↓
Networkは通る？
↓
Quotaはある？
↓
必要なRTO内でRecoveryできる？
まで考えて、初めて高度なAzure VM Data Protection設計が成立します。
次回：復旧編
次はAzure VMシリーズの締めとして、
【Rubrik × Azure VM｜復旧編】データが戻ればDR成功？Restore・Export・Cross-Region Recoveryを整理する
を扱います。
これまでの、
- Disk
- Availability Zone
- PPG
- Encryption
- Azure Policy
- Application Consistency
- File Recovery
をすべてRecoveryの視点からまとめ、
Snapshotがある
↓
Diskが戻る
↓
VMが起動する
↓
Networkにつながる
↓
Applicationが起動する
↓
RTO / RPOを満たす
まで成立して初めて、
「DR成功」と言える
という内容にします。
参考資料
Rubrik Documentation：Application-consistent protection for Azure virtual machines
Rubrik Documentation：Enabling application-consistent backups in Azure
Rubrik Documentation：Exocompute on Azure
Rubrik Documentation：Exocompute on Azure vCPU quota requirements
Rubrik Documentation：File indexing for Azure virtual machines
Rubrik Documentation：Prerequisites for Azure In-place File Recovery
Rubrik Compatibility Matrix：Azure virtual machine supported features and limitations
Rubrik Compatibility Matrix：File systems for indexing