Azure上で仮想マシンを運用していると、当然考えなければならないのがバックアップと復旧です。
Rubrik Security Cloud（以下、RSC）はAzure VMやManaged DiskをCloud Native Protectionの対象として保護できます。
では、
Azure VMであれば、どんな構成でもRubrikでバックアップできるのでしょうか？
答えは、**「すべて同じように保護できるわけではない」**です。
通常のAzure VMであれば比較的シンプルに保護できますが、VM Scale Sets（VMSS）、Unmanaged Disk、Trusted Launch、暗号化、Premium SSD v2、Ultra Diskなど、構成によって制限や利用できない機能があります。
さらに重要なのは、
「バックアップできる」ことと「すべての復旧機能が利用できる」ことは同じではない
という点です。
本シリーズでは、Rubrik × Azure VMの制約を以下のテーマに分けて整理していきます。
- 基礎編：Azure VMの対応範囲と基本制約
- Disk編：Managed Disk / Premium SSD v2 / Ultra Disk
- 配置編：Availability Zone / PPG / Availability Set
- セキュリティ編：ADE / CMK / Azure Policy
- 高度機能編：Application Consistency / File Recovery / Exocompute
- 復旧編：Restore / Export / Cross-Region Recovery / DR
今回はその基礎編として、
「RubrikでAzure VMを守る前に、最低限何を確認すればよいのか？」
を整理します。
※本記事は2026年9月時点の公開情報をもとに整理しています。Rubrik Security Cloudは継続的に機能追加・仕様変更されるため、実際の設計・導入時には最新のRubrik Compatibility Matrixも確認してください。
1. RubrikはAzure VMをどうバックアップするのか？
最初に、RubrikによるAzure VM保護の仕組みを簡単に整理します。
RSCのCloud Native Protectionでは、Azure上に常時稼働する専用バックアップサーバーを置いて、そこへVMのデータを転送する方式が基本ではありません。
RSCはAzure Subscriptionへ必要な権限でアクセスし、Azure Compute / Storage APIを利用してManaged DiskのSnapshotを作成します。
概念的には次のような流れです。
Azure Subscription
│
│
├── Azure VM
│ │
│ ├── OS Managed Disk
│ └── Data Managed Disk
│
▼
Azure Compute / Storage API
│
▼
Managed Disk Snapshot
│
▼
Rubrik Security Cloud
│
├── SLA Domain
├── Retention
├── Archive
├── Replication
└── Recovery
RSCでは、Azureアカウント追加時に利用するMicrosoft Entra IDのアプリケーション／Service Principalを通じてAzureリソースへアクセスし、SLA Domainに定義された頻度・保持期間に従ってSnapshotを作成します。RubrikのCloud Native ProtectionはAzureのネイティブSnapshot/Image APIを利用する構成です。
この仕組みから、まず一つ重要なことが分かります。
RubrikによるAzure VM保護では、VM Sizeそのものよりも「VMが利用しているDiskやAzure機能」が対応可否に大きく影響する
ということです。
2. 基本バックアップと「高度な機能」は分けて考える
Azure VMバックアップを考えるときに、最も誤解しやすいポイントです。
例えば、あるAzure VMについて、
VM Backup → 利用可能
VM Restore → 利用可能
Archive → 利用可能
Replication → 利用可能
File Recovery → 利用不可
Indexing → 利用不可
というケースが存在します。
つまり、
バックアップ可能
=
すべてのRubrik機能を利用可能
ではありません。
例えばRubrikのCompatibility Matrixでは、Premium SSD v2とUltra DiskはBackup、Archive、Replication、VM/Disk Restoreには対応している一方、File-Level Recovery / Indexingには対応していません。
したがって、Azure VMの対応状況を確認するときは、単純に、
「Rubrik対応ですか？」
と確認するだけでは不足します。
少なくとも以下を分けて確認する必要があります。
| 確認する機能 | 確認内容 |
|---|---|
| Backup | Snapshotを取得できるか |
| Archive | 長期保存できるか |
| Replication | 別リージョンなどへ複製できるか |
| Restore | 元VMへ戻せるか |
| Export | 新規VMとして復旧できるか |
| File Recovery | ファイル単位で戻せるか |
| Indexing | ファイル検索用Indexを作成できるか |
| Application Consistency | アプリ整合性を確保できるか |
| Security機能 | Anomaly Detectionなどを利用できるか |
この考え方は、今後のシリーズ全体で重要になります。
3. Azure VMの対応範囲をざっくり整理する
まずは、Azure VMの構成を大きく3種類に分けて考えてみます。
比較的シンプルに考えられる構成
代表的なのは、
- 通常のAzure VM
- Managed Disk
- Standard SSD
- Premium SSD
- 一般的なWindows / Linux VM
です。
RubrikのCompatibility Matrixでは、Azure Virtual MachineおよびManaged DiskはCloud Native Protectionの対象としてサポートされています。
一方で、構成によっては追加確認が必要です。
注意が必要な構成
例えば、
- Trusted Launch
- Azure Disk Encryption（ADE）
- Encryption at Host
- Premium SSD v2
- Ultra Disk
- Shared Disk
- Application Consistent Backupが必要なVM
などです。
これらは、
「VMをまったく保護できない」
という意味ではありません。
Backupは可能でも、
- Replicationができない
- File Recoveryができない
- Indexingができない
- Cross-Subscription Recoveryに制限がある
など、機能単位で制約が変わる場合があります。
明確な制限がある構成
一方、現行Rubrik Compatibility Matrixでは、特に次の2つは基礎段階で覚えておきたい項目です。
Azure Virtual Machine Scale Sets（VMSS）
Rubrik Security CloudのCloud Native Protectionでは、
VMSSおよびVMSSに関連付けられたVMのBackup Operationはサポートされていません。
つまり、
通常Azure VM
↓
Cloud Native Backup
○
VM Scale Sets
↓
Cloud Native Backup
×
です。
Azure側でVMとして見えているからといって、すべて同じ保護方式を利用できるわけではありません。
Unmanaged Disk
Unmanaged Diskを使用するVMについても、RSCはSnapshotを取得できないとされています。
現在新規構築でUnmanaged Diskを採用するケースは少ないと思いますが、長期間運用されているAzure環境をRubrikへ移行する場合には確認しておきたいポイントです。
4. VM SizeにRubrik独自の上限はある？
次に気になるのが、
- vCPU
- Memory
- NIC
- Data Disk数
です。
例えば、
4 vCPU / 16 GB
ならバックアップできるが、
128 vCPU / 1 TB Memory
になるとRubrikでバックアップできないのでしょうか？
現時点で公開されているAzure VM Compatibility Matrixを見る限り、
「Rubrik Cloud Native Protectionでは最大64 vCPUまで」
や、
「最大512 GB Memoryまで」
といったRubrik固有の数値上限は掲載されていません。
Azure VM SizeにはGeneral Purpose、Compute Optimized、Memory Optimized、Storage Optimized、GPU、HPCなど多くのファミリーがあり、vCPU、Memory、Data Disk数、NIC数などはVM Sizeごとに異なります。
例えばVMシリーズによっては、
2 vCPU
4 vCPU
8 vCPU
...
96 vCPU
112 vCPU
160 vCPU
といった非常に大きなVMも存在します。
したがって基礎編での整理は、
CPUやMemoryの大きさそのものより、VMが利用しているDisk・暗号化・配置・復旧先条件を確認する
となります。
ただし、ここには大きな注意点があります。
5. 「バックアップできる」と「同じVM Sizeで復旧できる」は別
バックアップ時には問題がなくても、DRやVM Export時にはAzure側の制約が問題になります。
Azureには、
- Total Regional vCPU Quota
- VM FamilyごとのvCPU Quota
- VM数のQuota
- RegionごとのVM SKU提供状況
- Availability ZoneごとのCapacity
などがあります。
AzureはQuotaとCapacityを別々に評価します。
そのため、
Quotaは十分
↓
でもAzure側に物理Capacityがない
↓
VMを配置できない
ということもあります。
これはRubrikの問題ではなくAzure側のCompute制約ですが、バックアップ・DR設計では極めて重要です。
例えば、
本番環境
Standard_xxx
128 vCPU
大量Memory
│
│ Rubrik Backup
▼
Snapshot取得成功
│
│ 障害発生
▼
別RegionへRecovery
│
▼
同じVM SKUのCapacityがない
│
▼
VMを起動できない
となれば、バックアップそのものは正常でも要求されたRTOを満たせません。
このテーマは後続の「配置編」「復旧編」で詳しく扱います。
6. Trusted Launchはどう考える？
Azure VMで今後特に重要になるのがTrusted Launchです。
Trusted LaunchはGeneration 2 VMを対象に、
- Secure Boot
- vTPM
- Boot Integrity Monitoring
などを利用してVMのセキュリティを強化する仕組みです。
Microsoftは、新しく作成される条件を満たしたGen2 Azure VMでTrusted Launchを既定化する方向に進めています。またTrusted Launchはx64だけでなくArm64でもサポートされています。
ではRubrikではどうでしょうか。
RubrikのCompatibility MatrixではTrusted Launch VMについて、
- Same Region Recovery
- Same Subscription Recovery
- Cross-Region Recovery
- Cross-Subscription Recovery
がサポートされています。
一方で、
Snapshot Replicationはサポートされていません。
つまり、
Trusted Launch VM
Backup / Recovery
○
Snapshot Replication
×
というように、機能によって差があります。
ここでも、
「Trusted Launch対応○ / ×」だけでは判断できない
ことが分かります。
7. Confidential VMや特殊なVMは個別確認する
AzureにはTrusted Launch以外にも、
- Confidential VM
- Arm64 VM
- GPU VM
- HPC VM
- Storage Optimized VM
- Nested Virtualization利用VM
- Spot VM
など、多数のVMタイプがあります。
例えばAzure Confidential VMは、AMD SEV-SNPなどのハードウェアベースTrusted Execution Environmentを利用し、通常VMとは異なるセキュリティモデルを持ちます。利用できるVM SizeやOSにも固有の条件があります。
ここで重要なのは、
AzureがそのVMを作成できることと、Rubrikのすべての保護・復旧機能が利用できることは別
という考え方です。
公開Compatibility Matrixに明確な記載がない特殊構成については、
- 最新Compatibility Matrix
- 利用中のRSC Tenant
- Rubrik Support
で確認することをおすすめします。
特に、
新しいAzure VM Family
+
新しいSecurity機能
+
新しいDisk Type
の組み合わせは注意が必要です。
8. Azure VMの「何」がバックアップされるのか？
ここも非常に重要です。
Azure VMは単体のリソースに見えますが、実際には複数のAzureリソースから構成されています。
例えば、
Azure VM
│
├── OS Managed Disk
├── Data Managed Disk
├── NIC
├── Private IP
├── Public IP
├── NSG
├── VNet
├── Subnet
├── Load Balancer
├── Availability Zone
├── Availability Set
└── Proximity Placement Group
などです。
RubrikのCloud Native Protectionの中心になるのは、VMおよびManaged DiskのSnapshotを利用したデータ保護です。
したがって、
Azure VMをバックアップしたから、Azure環境全体がそのまま完全再現される
と考えるのは危険です。
例えば、
- VNet
- NSG
- Load Balancer
- Application Gateway
- Route Table
- Azure Firewall
- Private DNS
- Proximity Placement Group
などは、VMデータとは別のAzureリソースです。
バックアップ設計では、
VM / Diskのデータ復旧
と、
Azureインフラ構成の再構築
を分けて考える必要があります。
後者については、ARM Template、Bicep、TerraformなどのIaCとの組み合わせも重要になります。
9. Application Consistencyが必要なら話が変わる
通常のVM Snapshotだけで十分なのか、それともアプリケーション整合性まで求めるのかも重要です。
例えばVM上で、
- SQL Server
- Active Directory
- 業務アプリケーション
などが動いている場合、
単なるディスクSnapshotだけでなく、
Application-Consistent Backup
を求めることがあります。
RSCではAzure VMのApplication-Consistent BackupにWindows VSSを利用でき、対象Windows VMにはRubrik Backup Service（RBS）の登録が必要です。またExocomputeの構成も必要で、Application Consistencyはデフォルトでは無効です。
概念的には、
Azure VM
│
├── Windows
├── Application
└── RBS
│
▼
Windows VSS
▲
│
Exocompute
│
▼
Rubrik Security Cloud
となります。
つまり、
基本的なVM Snapshot保護には常時稼働するRubrik専用Computeを必要としなくても、高度な処理ではExocomputeなどの追加コンポーネントが必要になる
ということです。
ExocomputeはApplication-Consistent Backupだけでなく、
- File Indexing
- File Recovery
- Storage Tiering
にも利用されます。
このテーマは「高度機能編」で詳しく整理します。
10. VM上のDatabaseはさらに別の話
Azure VM上に、
SQL Server
Oracle Database
SAP HANA
IBM Db2
などを構築している場合も注意が必要です。
RubrikのCompatibility Matrixでは、
| Azure Workload | Cloud Native Protection |
|---|---|
| Azure Virtual Machine | ○ |
| Managed Disk | ○ |
| SQL Server running in Azure VM | DB Native Protectionとしては別方式 |
| Oracle Database running in Azure VM | DB Native Protectionとしては別方式 |
| SAP HANA running in Azure VM | DB Native Protectionとしては別方式 |
| IBM Db2 running in Azure VM | DB Native Protectionとしては別方式 |
という整理になっています。DBワークロードについてはRubrik Cloud Cluster Elastic Storage（CCES）側の保護方式が示されています。
要するに、
Azure VMをバックアップする
≠
DatabaseをDatabaseとしてバックアップする
です。
例えばOracle Databaseなら、
VM SnapshotからVMを戻す
ことと、
Archive Logを使って
特定時点・特定SCNへDatabaseをRecoveryする
ことは別です。
この部分については、DB編として別記事に分けた方が分かりやすいため、本シリーズではVM保護に焦点を当てます。
11. 最初に確認しておきたい6つのポイント
ここまでの内容を、Azure VMをRubrikで保護する際の最初の確認項目としてまとめます。
① VMタイプ
まず対象VMが何なのかを確認します。
通常VM？
VMSS？
Trusted Launch？
Confidential VM？
特殊なGPU / HPC VM？
特にVMSSは現行Compatibility MatrixではCloud Native Backupの対象外なので注意が必要です。
② Disk構成
次に、
OS Disk
Data Disk
Temporary Disk
Local NVMe
を確認します。
VMの中から一つのC:やD:に見えていても、Azureインフラ側ではストレージの種類が異なります。
③ Managed / Unmanaged
現在はManaged Diskが一般的ですが、古いAzure環境ではUnmanaged Diskが残っている可能性があります。
Unmanaged Disk VMについてはRubrikがSnapshotを取得できないため、事前確認が必要です。
④ 暗号化
確認する代表例は、
Azure Disk Encryption
Storage Service Encryption
Customer Managed Key
Encryption at Host
です。
例えばADEではBackup可能でもCross-Subscription RecoveryやIndexingに制限があります。
Encryption at Hostでも追加条件があります。
暗号化は非常に重要なため「セキュリティ編」で詳しく整理します。
⑤ 高度な機能を使うか
単にVMを丸ごと戻せればよいのか、
それとも、
- ファイル単位Recovery
- File Indexing
- Application Consistent Backup
- Archive
- Replication
- Anomaly Detection
まで必要なのかを決めます。
File IndexingやFile RecoveryなどではExocomputeが利用されます。
⑥ どこへ復旧するのか
最後はRecovery先です。
同じVMへRestore？
新規VMとしてExport？
同じRegion？
別Region？
別Subscription？
別Availability Zone？
ここまで考えて、初めて、
「このAzure VMは要件どおりRubrikで保護できる」
と言えます。
12. 基礎編チェックリスト
最後に、今回の内容だけを簡単なチェックリストにします。
| # | 確認項目 | Check |
|---|---|---|
| 1 | 対象は通常のAzure VMか | ☐ |
| 2 | VMSS配下のVMではないか | ☐ |
| 3 | Trusted Launchの利用有無を確認したか | ☐ |
| 4 | Confidential VMなど特殊VMではないか | ☐ |
| 5 | VM Generationを確認したか | ☐ |
| 6 | x64 / Arm64を確認したか | ☐ |
| 7 | VM Size / Familyを確認したか | ☐ |
| 8 | 復旧先Regionで同等VM Sizeを利用できるか | ☐ |
| 9 | vCPU Quotaを確認したか | ☐ |
| 10 | OS Diskの種類を確認したか | ☐ |
| 11 | Data Diskの種類を確認したか | ☐ |
| 12 | Unmanaged Diskを利用していないか | ☐ |
| 13 | Temporary Disk / Local NVMeに重要データがないか | ☐ |
| 14 | Disk暗号化方式を確認したか | ☐ |
| 15 | File Recoveryが必要か | ☐ |
| 16 | Application Consistencyが必要か | ☐ |
| 17 | Exocomputeが必要な機能を利用するか | ☐ |
| 18 | Replicationが必要か | ☐ |
| 19 | Cross-Region Recoveryが必要か | ☐ |
| 20 | Cross-Subscription Recoveryが必要か | ☐ |
| 21 | VM上でDatabaseが稼働していないか | ☐ |
| 22 | 「VM Backup」と「DB Backup」を分けて考えたか | ☐ |
| 23 | Azureインフラ全体の再構築方法を考えているか | ☐ |
| 24 | 最新Rubrik Compatibility Matrixを確認したか | ☐ |
13. まとめ
今回のポイントをまとめると、Rubrik Security CloudではAzure VMとManaged DiskをCloud Native Protectionで保護できます。
しかし、
「Azure VMだから何でも同じようにバックアップできる」わけではありません。
特に重要なのは次の点です。
Azure VM
│
├─ VMタイプは？
├─ Managed Disk？
├─ Diskタイプは？
├─ 暗号化されている？
├─ Trusted Launch？
├─ 高度なRecovery機能は必要？
└─ どこへRecoveryする？
そして一番重要なのは、
「Backup可能」と「要件どおりRecovery可能」は別々に確認する
ことです。
バックアップ製品を評価するときは、つい、
Backup対応：○
だけを見てしまいます。
しかし本当に重要なのは、
Backup
↓
Archive
↓
Replication
↓
Restore
↓
File Recovery
↓
VM起動
↓
Application起動
まで成立することです。
次回：Disk編
次はAzure VMの中でも、特に制約が多いManaged Diskに絞ります。
【Rubrik × Azure VM｜Disk編】Premium SSD v2やUltra Diskも守れる？Managed Diskの制約を整理する
次回は、
- Standard HDD
- Standard SSD
- Premium SSD
- Premium SSD v2
- Ultra Disk
- OS Disk
- Data Disk
- Ephemeral OS Disk
- Temporary Disk
- Local NVMe
- Disk数
- Disk容量
- Shared Disk
- Storage Spaces
- Unmanaged Disk
について、
Backup / Archive / Replication / Restore / File Recoveryのどこに制限があるのか
を整理していきます。
参考資料
- Rubrik Documentation：Cloud-native protection for Azure Rubrik公式ドキュメント
- Rubrik Compatibility Matrix：Azure virtual machine supported features and limitations Rubrik Compatibility Matrix
- Rubrik Documentation：Exocompute on Azure Exocompute on Azure
- Microsoft Learn：Azure VM Sizes Azure VM Sizes
- Microsoft Learn：Azure vCPU quotas Azure vCPU quotas
- Microsoft Learn：Trusted Launch for Azure VMs Trusted Launch