Azure VMをRubrik Security Cloud（以下、RSC）でバックアップするとき、特に注意したいのがDiskの種類です。
Azureには現在、代表的なManaged Diskとして、
- Standard HDD
- Standard SSD
- Premium SSD
- Premium SSD v2
- Ultra Disk
があります。
一見すると、
「全部Managed Diskなのだから、Rubrikでも全部同じようにバックアップできるのでは？」
と思うかもしれません。
しかし実際にはそう単純ではありません。
例えば、Premium SSD v2やUltra DiskはRSCでバックアップできます。
ところが、
VM Restoreはできるが、File-Level RecoveryやFile Indexingはできない
という機能差があります。
さらにAzure VMには、
- OS Disk
- Data Disk
- Temporary Disk
- Local NVMe
- Ephemeral OS Disk
- Shared Disk
など、性質の異なるストレージが存在します。
つまり、
「Azure VMをバックアップする」＝「VMに見えているすべてのDiskを同じように保護できる」
ではありません。
今回はRubrik × Azure VMシリーズのDisk編として、
「どのDiskが保護でき、どの機能に制限があるのか？」
を整理します。
※本記事は2026年9月時点のMicrosoftおよびRubrik公開情報をもとに整理しています。クラウドサービスは継続的に仕様変更されるため、実際の導入時には最新のRubrik Compatibility MatrixおよびMicrosoft Learnも確認してください。
1. まずAzure VMのDisk構成を整理する
Azure VMを作成すると、VMには複数種類のDiskが登場します。
代表的な構成は次のとおりです。
Azure VM
│
├── OS Disk
│ └── Managed Disk
│
├── Data Disk #1
│ └── Managed Disk
│
├── Data Disk #2
│ └── Managed Disk
│
└── Temporary / Local Storage
├── Temporary Disk
└── Local NVMe
この中で、まず大きく分ける必要があるのが、
Azure Storageに永続化されるDisk
と、
VMホスト側のローカルストレージ
です。
RubrikのCloud Native Protectionでは、AzureのAPIを利用してManaged Disk Snapshotを取得します。
そのため、
Managed DiskとしてSnapshotを取得できるストレージかどうか
が非常に重要になります。
2. RubrikによるAzure VMバックアップとManaged Disk
RSCではAzure VMを保護するとき、AzureのネイティブSnapshot APIを利用します。
概念的には次のようになります。
Azure VM
│
├── OS Managed Disk
├── Data Managed Disk
└── Data Managed Disk
│
▼
Azure Snapshot
│
▼
Rubrik Security Cloud
│
├── SLA Domain
├── Retention
├── Archive
├── Replication
└── Recovery
ここで重要なのが、
VMバックアップの中心となっているのはManaged DiskのSnapshot
という点です。
このためDisk編では、
- Azure側でSnapshot可能か
- RubrikがそのDisk Typeをサポートしているか
- Backup後にどのRecovery機能が利用できるか
の3段階で考えます。
3. Azure Managed Diskは現在5種類
Azureでは主に次の5種類のManaged Diskが提供されています。
| Disk Type | 主な用途 |
|---|---|
| Standard HDD | 低頻度アクセス、低コスト用途 |
| Standard SSD | Web、開発、軽量アプリ |
| Premium SSD | 本番システム |
| Premium SSD v2 | 高IOPS・高Throughput用途 |
| Ultra Disk | DB、SAP HANAなど超高性能用途 |
2026年9月時点のAzure仕様では、最大容量はおおむね以下です。
| Disk Type | Azure最大Disk容量 |
|---|---|
| Standard HDD | 32,767 GiB |
| Standard SSD | 32,767 GiB |
| Premium SSD | 32,767 GiB |
| Premium SSD v2 | 65,536 GiB |
| Ultra Disk | 65,536 GiB |
つまり、Azureでは現在、
1 Diskあたり約64TiB
という非常に大きなData Diskを構成できます。
ただし、
Azureで作成できるDisk
と、
Rubrikですべての機能を利用できるDisk
は同じではありません。
4. RubrikのDisk Type別対応状況
ここが今回の記事で最も重要な部分です。
Rubrik Compatibility Matrixでは、Azure Disk Typeごとの対応状況が次のように整理されています。
| Azure Disk Type | Backup | Archive | Replication | File-Level Recovery / Indexing |
|---|---|---|---|---|
| Standard HDD LRS | ○ | ○ | ○ | ○ |
| Standard SSD LRS | ○ | ○ | ○ | ○ |
| Standard SSD ZRS | ○ | ○ | ○ | ○ |
| Premium SSD LRS | ○ | ○ | ○ | ○ |
| Premium SSD ZRS | ○ | ○ | ○ | ○ |
| Premium SSD v2 LRS | ○ | ○ | ○ | × |
| Ultra Disk LRS | ○ | ○ | ○ | × |
さらにRSCでは、上記のサポート対象Diskについて、
- VM Export
- VM Restore
- Disk Export
をサポートしています。
ここで最も重要なのが、
Premium SSD v2
Ultra Disk
です。
この2種類について、
「Rubrikではバックアップできない」
という理解は誤りです。
正しくは、
Backup ○
Archive ○
Replication ○
VM Restore ○
Disk Export ○
File Recovery
File Indexing
×
です。
5. Premium SSD v2は何が違う？
Premium SSD v2は、Premium SSDより柔軟に、
- Capacity
- IOPS
- Throughput
を設定できる高性能Diskです。
Azureでは最大64TiB、最大80,000 IOPS、最大2,000 MB/sのThroughputを設定できます。
特に、
- SQL Server
- Oracle Database
- SAP
- MongoDB
- Cassandra
- 分析系システム
などの高I/Oワークロードで利用されます。
ただしAzure側にもいくつか特徴があります。
例えば、
Premium SSD v2はOS Diskとして利用できません。
つまり、
Azure VM
│
├── OS Disk
│ Premium SSD
│
└── Data Disk
Premium SSD v2
という構成になります。
またPremium SSD v2はHost Cachingをサポートしません。
6. Premium SSD v2をRubrikで守る場合
RubrikではPremium SSD v2について、
Backup ○
Archive ○
Replication ○
Restore ○
Disk Export ○
です。
ここまでは問題ありません。
ところが、
File Indexing ×
File-Level Recovery ×
です。
つまり、例えば、
Premium SSD v2
│
└── D:\Database
D:\Documents
D:\Application
を持っているVMの場合、
VM全体をSnapshotから復旧することはできても、
「昨日削除してしまった
D:\Documents\report.xlsxだけ戻したい」
というFile-Level Recoveryは利用できません。
ここはバックアップ設計で非常に重要です。
7. 「Backup ○」だけを見てはいけない
例えばバックアップ製品のCompatibility Matrixを確認して、
Premium SSD v2
Backup = Yes
だけを見れば、
「問題なし」
と判断してしまうかもしれません。
しかし実際には、
Premium SSD v2
│
┌─────────┴─────────┐
│ │
VM単位Recovery File単位Recovery
│ │
○ ×
です。
したがって、要件が、
障害時にVMごと戻せればよい
なら問題にならない可能性があります。
一方で、
ユーザーが削除したファイルを個別に戻したい
という要件があれば設計に影響します。
8. Ultra Diskはどうなる？
次はUltra Diskです。
Ultra DiskはAzure Managed Diskの中でも特に高性能なDiskです。
Microsoftは、
- SAP HANA
- SQL Server
- Oracle Database
- Transaction-heavy workload
などを代表的な利用用途として挙げています。
Azureでは最大、
Capacity
64 TiB
IOPS
400,000
Throughput
10,000 MB/s
までサポートされています。
非常に高性能です。
一方でUltra Diskは、
Data Disk専用
です。
OS Diskとしては利用できません。
したがって一般的には、
Azure VM
│
├── OS Disk
│ Premium SSD
│
└── Database Disk
Ultra Disk
のようになります。
9. Ultra DiskもRubrik Backupは可能
Ultra DiskについてもRubrikの対応状況は、
Backup ○
Archive ○
Replication ○
Restore ○
Disk Export ○
です。
しかし、
File Indexing ×
File-Level Recovery ×
となります。
Premium SSD v2と同じです。
この違いは特にDatabase VMで重要です。
例えば、
SQL Server VM
C: OS
Premium SSD
E: Database
Ultra Disk
F: Log
Ultra Disk
という構成で、
VM Snapshotそのものは保護できます。
しかし、
Ultra Disk内のファイルをRubrik File Indexingで検索して個別Recoveryする
ことはできません。
10. OS Diskには別の上限がある
ここでもう一つ重要なのがOS Diskです。
Azure Managed Diskそのものは32TiBや64TiBまで対応していますが、
Azure VMのOS Disk最大サイズは4,095 GiB
です。
つまり、
Managed Disk最大容量
≠
OS Disk最大容量
です。
また、古いOSやMBR形式では利用可能容量が2TiBに制限される場合があります。
そのため大容量データは、
OS Disk
↓
OS中心
Data Disk
↓
Application / Database / Data
に分けるのが基本です。
11. Standard HDDをOS Diskとして使う場合の将来注意
Azureでは2028年9月8日に、
Standard HDDをOS Diskとして利用する機能を廃止する予定
と案内されています。
Data DiskとしてのStandard HDDそのものがなくなるという意味ではありません。
しかし長期間保管するAzure VM構成では、
Standard HDD OS Disk
が残っていないか確認しておく価値があります。
Rubrikの対応可否とは別に、
Azureプラットフォーム側のライフサイクル
もバックアップ設計では確認する必要があります。
12. Ephemeral OS Diskは別物
Disk編の中で特に注意したいのが、
Ephemeral OS Disk
です。
通常のOS DiskはAzure Storage上に保存されます。
VM
│
└── Managed OS Disk
│
▼
Azure Storage
│
▼
Snapshot
一方Ephemeral OS Diskは、
VM
│
└── Ephemeral OS Disk
│
▼
VM Host Local Storage
です。
OS Diskの内容をAzure Storageに永続化せず、VMホスト側のローカルストレージへ保存します。
その結果AzureではEphemeral OS Diskについて、
- Disk Snapshot
- Azure Backup
- Azure Site Recovery
- Azure Disk Encryption
- OS Disk Swap
などがサポートされません。
つまり、
Snapshotを前提とする通常のRubrik Azure VM保護とは根本的に性質が異なる
ということです。
13. Ephemeral OS Diskは「バックアップすべきVM」なのか？
Ephemeral OS Diskはそもそも、
Stateless Workload
向けです。
例えば、
VM障害
↓
VMを復旧
ではなく、
VM障害
↓
新しいVMを再作成
↓
Application再デプロイ
という設計です。
そのためEphemeral OS Diskを採用している環境では、
「RubrikでVM Snapshotを取るにはどうするか？」
よりも、
「このVMはバックアップから戻す設計なのか、それともIaCから再作成する設計なのか？」
を先に確認すべきです。
これはバックアップ設計とCloud Native Designの境界になります。
14. Temporary Diskも保護対象と考えてはいけない
Azure VMにはTemporary Diskが存在する場合があります。
Windowsでは歴史的に、
D:
として見えることも多いDiskです。
しかしTemporary DiskはAzure VMホストのローカルストレージです。
VMが別ホストへ移動した場合などには内容が失われます。
そのため、
永続データをTemporary Diskへ保存してはいけません。
例えばSQL Serverでは、
C:
OS
Premium SSD
E:
Database
Premium SSD
F:
Transaction Log
Premium SSD
D:
tempdb
Temporary Disk
という設計があります。
この場合D:のtempdbは、バックアップから復旧する必要のない一時データです。
15. Local NVMeも同じ考え方
Storage Optimized VMなどではLocal NVMeを利用できる場合があります。
Local NVMeは非常に高性能ですが、
Local
という名前のとおり、VMホスト側のストレージです。
したがって、
Managed Disk
↓
永続データ
Local NVMe
↓
Cache
Temporary Data
Scratch
のように役割を分ける必要があります。
RubrikのVM Snapshotを設計するときも、
「OSからDiskとして見えるか」ではなく「Azure Storage上のManaged Diskなのか」
を確認することが重要です。
16. Data Disk数にRubrik独自上限はある？
次に気になるのが、
「1VMに何枚までDiskを付けてもRubrikでバックアップできるのか？」
です。
現行のRubrik Compatibility Matrixには、
最大16 Data Disks
最大32 Data Disks
といった単純なRubrik固有上限は掲載されていません。
Data Disk数は基本的に、
Azure VM Size側の上限
に依存します。
例えばAzure VM Sizeによって、
4 Disks
8 Disks
16 Disks
32 Disks
64 Disks
など異なります。
したがって、
Azure側でそのVM Sizeが何枚のData Diskを接続できるのか
を確認する必要があります。
17. 復旧先VM Sizeも同じDisk数を接続できる必要がある
ここはRecovery設計で重要です。
例えば本番VMが、
VM-A
OS Disk × 1
Data Disk × 32
だったとします。
Snapshot自体は正常に取得できたとしても、
DR時に選んだVM Sizeが、
最大Data Disk数 = 16
なら、そのまま同じ構成にはできません。
つまり、
Backup時
32 Data Disks
│
▼
Backup ○
Recovery時
Target VM Size
Max 16 Disks
│
▼
構成不成立
となります。
これも、
BackupできることとRecoveryできることは別
という代表例です。
18. 大容量DiskではRTOも考える
Azureでは現在、
Premium SSD v2
64 TiB
Ultra Disk
64 TiB
級のDiskを構成できます。
例えば、
VM
│
├── Data Disk 32 TiB
├── Data Disk 32 TiB
├── Data Disk 32 TiB
└── Data Disk 32 TiB
なら、
合計128 TiB
です。
これを考えると、
「Rubrikが対応しているから問題ない」
では不十分です。
重要なのは、
- Snapshot取得
- Archive
- Replication
- Disk作成
- VM Restore
- Application起動
までを含めたRTOです。
大容量VMでは、
「バックアップできる最大値」
より、
「要求された時間内に復旧できる構成か？」
の方が重要になります。
19. Shared Diskもバックアップできる？
次にShared Diskです。
Azure Shared Diskでは1つのManaged Diskを複数VMへ接続できます。
例えば、
Shared Disk
│
┌────────┴────────┐
│ │
VM-A VM-B
という構成です。
Windows Server Failover Cluster（WSFC）やLinux Pacemakerなどで利用されます。
Azureでは現在、
- Ultra Disk
- Premium SSD v2
- Premium SSD
- Standard SSD
をShared Diskとして利用できます。
Shared DiskではmaxSharesによって、同時に接続可能なVM数を指定します。
20. RubrikでShared DiskをRestoreするとどうなる？
ここは非常に重要です。
RubrikではShared Diskが接続されたVMをRestoreする場合、
- Restore対象VMからShared Diskを切り離す
- SnapshotからShared Diskの新しいコピーを作成
- Restore対象VMへ新しいDiskを接続する
という動作になります。
一方、元のShared Diskは他のVMに引き続き接続されています。
例えば、
Restore前
Shared Disk A
/ \
VM-A VM-B
VM-AをRestoreすると、
Restore後
VM-A VM-B
│ │
▼ ▼
Restored Disk A' Shared Disk A
となります。
つまり、
RestoreしたVMが自動的に元のShared Disk Clusterへ戻るわけではない
ということです。
クラスタシステムでは非常に重要な制約です。
21. Shared Diskは「VM単体」で考えてはいけない
Shared Diskを利用するシステムでは、
VM-A
VM-B
Shared Disk
Cluster Configuration
Quorum
Application
全体でRecoveryを考える必要があります。
したがって、
「VM-AのSnapshotがあるからVM-AをRestoreすれば終わり」
ではありません。
特に、
- SQL Server Failover Cluster Instance
- Windows Server Failover Cluster
- Pacemaker
- SAP HANA
- Shared Database Storage
などでは、アプリケーション／クラスタ単位のRecovery設計が必要です。
22. Storage Spaces / Storage Poolにも注意
Azure VM内で複数Managed Diskをまとめて、
Disk 1 ─┐
Disk 2 ─┼─ Storage Pool
Disk 3 ─┤
Disk 4 ─┘
│
▼
Volume
としている場合があります。
Windows Storage Spacesなどが代表例です。
Rubrikでは、
Azure Managed DiskでStorage Poolを利用している構成はFile Recoveryでサポートされません。
ここでも、
VM Backup
○
VM Restore
○
File Recovery
×
という違いが発生します。
23. File RecoveryにはFile System側の制約もある
File-Level RecoveryではDisk Typeだけでなく、
Disk内部のFile System
も重要です。
RubrikのFile Indexing / File Recoveryでは、対応File Systemに制限があります。
例えば構成によって、
- Windows Storage Spaces
- ReFS
- exFAT
- ZFS
- Storage Pool
などがFile Indexing / Recoveryに影響します。
したがって、
Disk Type
○
だけでは不十分
です。
確認すべきなのは、
Disk Type
+
Partition
+
File System
+
Storage Pool
+
Encryption
です。
File Recoveryの詳細は後続の高度機能編で整理します。
24. Unmanaged Diskは明確な非対応
現在Azureで新しくVMを構築する場合、Managed Diskが基本です。
しかし古いAzure環境では、
Storage Account
│
▼
Page Blob (.vhd)
│
▼
Azure VM
というUnmanaged Diskが残っている可能性があります。
Rubrik Compatibility Matrixでは、
Unmanaged Diskを持つVMについて、RSCはSnapshotを取得できない
と明記されています。
したがって、
Managed Disk
○
Unmanaged Disk
×
です。
既存Azure環境へRubrikを導入する場合は、まずUnmanaged Diskが残っていないか確認するのがおすすめです。
25. Disk Snapshot自体にもAzure側の制限がある
Managed Disk SnapshotはAzureプラットフォームの機能です。
MicrosoftではIncremental Snapshotについて、例えば、
- 1 Diskあたり最大500 Incremental Snapshots
- 5分間に最大7 Snapshot / Disk
- Snapshotを元Diskとは別Subscriptionで直接作成できない
などの制限があります。
RubrikがAzure Native Snapshot APIを利用している以上、
Azureプラットフォーム側のSnapshot制限も無関係ではありません。
特に大量VM・高頻度Snapshotを設計する場合には、
RubrikのSLA DomainだけでなくAzure API / Snapshot側のScale Limitも考慮する必要があります。
26. Disk Backup設計で最も重要な考え方
ここまでを整理すると、Disk保護では次の順番で確認すると分かりやすくなります。
STEP 1
そのDiskは永続ストレージか？
│
▼
STEP 2
Managed Diskか？
│
▼
STEP 3
どのDisk Typeか？
│
▼
STEP 4
必要なRecovery機能は何か？
│
▼
STEP 5
要求されたRTO内で戻せるか？
例えば、
Premium SSD v2
なら、
Managed Disk？
○
Backup？
○
Restore？
○
File Recovery？
×
です。
一方、
Ephemeral OS Disk
なら、
Persistent Managed Disk Snapshot？
×
の段階で通常のバックアップ設計とは異なります。
27. Disk Type別まとめ
最後に今回の内容を一覧化します。
| Disk / Storage | Rubrik VM Backup観点 | 主な注意点 |
|---|---|---|
| Standard HDD | ○ | OS Disk利用はAzure側で2028年廃止予定 |
| Standard SSD | ○ | 基本機能を利用可能 |
| Premium SSD | ○ | 基本機能を利用可能 |
| Premium SSD v2 | ○ | File Recovery / Indexing × |
| Ultra Disk | ○ | File Recovery / Indexing × |
| Ephemeral OS Disk | ×相当 | Azure Disk Snapshot自体が非対応 |
| Temporary Disk | 保護対象外 | 非永続Local Storage |
| Local NVMe | 保護対象外 | 非永続Local Storage |
| Shared Disk | ○ | Restore時の共有関係に注意 |
| Storage Pool | Backup ○ | File Recovery制約あり |
| Unmanaged Disk | × | RSC Snapshot非対応 |
28. Disk編チェックリスト
実際の設計時には次の項目を確認するとよいでしょう。
| # | 確認項目 | Check |
|---|---|---|
| 1 | OS DiskがManaged Diskか | ☐ |
| 2 | Data DiskがManaged Diskか | ☐ |
| 3 | Unmanaged Diskが残っていないか | ☐ |
| 4 | OS Disk Typeを確認したか | ☐ |
| 5 | Data Disk Typeを確認したか | ☐ |
| 6 | Standard HDDをOS Diskに利用していないか | ☐ |
| 7 | Premium SSD v2を利用しているか | ☐ |
| 8 | Ultra Diskを利用しているか | ☐ |
| 9 | Premium SSD v2でFile Recoveryが必要ではないか | ☐ |
| 10 | Ultra DiskでFile Recoveryが必要ではないか | ☐ |
| 11 | Ephemeral OS Diskではないか | ☐ |
| 12 | Temporary Diskに永続データがないか | ☐ |
| 13 | Local NVMeに永続データがないか | ☐ |
| 14 | OS Disk容量を確認したか | ☐ |
| 15 | Data Disk容量を確認したか | ☐ |
| 16 | Data Disk数を確認したか | ☐ |
| 17 | Recovery先VM Sizeが同じDisk数を接続できるか | ☐ |
| 18 | 大容量DiskのRTOを確認したか | ☐ |
| 19 | Shared Diskを利用していないか | ☐ |
| 20 | Shared Disk Restore時の動作を理解しているか | ☐ |
| 21 | Cluster全体のRecovery手順を決めているか | ☐ |
| 22 | Storage Spaces / Storage Poolを利用していないか | ☐ |
| 23 | File Systemを確認したか | ☐ |
| 24 | File Indexingが必要か | ☐ |
| 25 | File-Level Recoveryが必要か | ☐ |
| 26 | Archiveが必要か | ☐ |
| 27 | Replicationが必要か | ☐ |
| 28 | 最新Rubrik Compatibility Matrixを確認したか | ☐ |
| 29 | Azure Managed Disk最新仕様を確認したか | ☐ |
| 30 | 「Backup ○」だけで判断していないか | ☐ |
29. まとめ
今回最も重要なのは、
「Managed Diskだから全部同じようにRubrikで守れる」と考えない
ことです。
特に覚えておきたいのは、
Standard HDD
Standard SSD
Premium SSD
│
└── Backup ○
File Recovery ○
Premium SSD v2
Ultra Disk
│
└── Backup ○
File Recovery ×
という違いです。
そして、
Ephemeral OS Disk
Temporary Disk
Local NVMe
は通常のManaged Diskとは根本的に性質が異なります。
バックアップ設計では、
VMからDiskとして見える
ことではなく、
Azure Storage上で
どのように永続化されているか
を確認する必要があります。
もう一つ重要なのがShared Diskです。
VM Restore成功
≠
Cluster Recovery成功
です。
Diskを共有しているCluster Workloadでは、VM単体ではなくシステム全体としてRecoveryを考える必要があります。
最終的には、
Backupできる？
↓
Restoreできる？
↓
File Recoveryできる？
↓
同じDisk構成を再現できる？
↓
RTO内に戻せる？
↓
Applicationを起動できる？
まで確認して、初めてバックアップ設計が成立します。
次回：配置編
次はDiskから一歩進んで、
【Rubrik × Azure VM｜配置編】バックアップがあってもVMが起動できない？AZ・PPG・配置制約を整理する
を扱います。
次回は、
- Availability Zone
- Availability Set
- Proximity Placement Group（PPG）
- PPG Intent
- VM Size
- Capacity
- Quota
- Capacity Reservation
- Dedicated Host
- VMSS
などを整理します。
特に、
RubrikのSnapshotもDiskも正常なのに、Azure側の配置制約によってVMを作成できない
というケースを中心に、
「バックアップ成功」と「DR成功」の違い
を掘り下げます。
参考資料
- Rubrik Compatibility Matrix：Azure virtual machine supported features and limitations
- Rubrik Documentation：Restoring Azure virtual machine using a snapshot
- Rubrik Documentation：File recovery limitations
- Rubrik Documentation：File indexing for Azure virtual machines
- Microsoft Learn：Azure managed disk types
- Microsoft Learn：Overview of Azure Disk Storage
- Microsoft Learn：Ephemeral OS disks for Azure VMs
- Microsoft Learn：Share an Azure managed disk across VMs
- Microsoft Learn：Incremental snapshots for managed disks