Azureでデータを保存する場所というと、Azure VMのManaged Diskだけではありません。
例えば、
- Azure Blob Storage
- Azure Files
- Azure NetApp Files
も、多くのシステムで利用されています。
しかし、この3つはすべて「Azure上のストレージ」ではあるものの、性質がかなり異なります。
Azure Blob Storage
↓
Object Storage
Azure Files
↓
Managed File Share
Azure NetApp Files
↓
Enterprise File Storage
そしてRubrikで保護するときも、
3サービスを同じ方法でバックアップするわけではありません。
2026年9月時点のRubrik Compatibility Matrixでは、Azure Blob StorageはRSCのCloud Native Protectionに対応しています。
一方、Azure FilesとAzure NetApp FilesはCloud Native Protection対象ではなく、Rubrik Cloud Cluster Elastic Storage（CCES）やRubrik NAS Cloud Direct（NAS CD）を利用する方式としてサポートされています。
今回は、
「Azureのファイル・オブジェクトストレージをRubrikで守るなら、何を選べばよいのか？」
を整理します。
※本記事は2026年9月時点のRubrikおよびMicrosoft公開情報をもとに整理しています。実際の導入時には、利用中のRSC環境、Rubrik Compatibility Matrix、対象Azureサービスの最新仕様をご確認ください。
1. まず3つのサービスの違いを整理する
最初にAzure Blob Storage、Azure Files、Azure NetApp Filesそのものの違いを整理します。
Azure Blob Storage
Blob Storageはオブジェクトストレージです。
大量の非構造化データを保存する用途に適しており、
- 画像
- 動画
- ログ
- バックアップデータ
- 分析データ
- Data Lake
などで利用されます。
一般的なファイルサーバーとは異なり、基本的には「ファイルシステム」ではなくObjectとしてデータを扱います。
Azure Files
Azure Filesは、Azureが提供するフルマネージドファイル共有です。
SMBとNFSを利用でき、クラウドだけでなくオンプレミスやAzure VMからもマウントできます。
例えば、
Windows VM
│
SMB
│
Azure Files
や、
Linux VM / AKS
│
NFSv4.1
│
Azure Files
という使い方ができます。
Azure NetApp Files
Azure NetApp Files（ANF）は、Azureネイティブの高性能エンタープライズファイルストレージサービスです。
SMB、NFS、Dual Protocolをサポートしており、特に、
- SAP HANA
- Database
- HPC
- Enterprise NAS
- 大規模ファイル共有
など、高性能・低Latencyが求められるワークロードで利用されます。
2. Rubrikの対応方式を先に比較する
3サービスについて、Rubrikの保護方式を整理すると次のようになります。
| Azureサービス | RSC Cloud Native Protection | Rubrik CCES | NAS Cloud Direct |
|---|---|---|---|
| Azure Blob Storage | ○ | × | ― |
| Azure Files | × | ○ | ○ |
| Azure NetApp Files | × | ○ | ○ |
Rubrik Compatibility MatrixではAzure FilesとNetApp Filesについて、CCESはRubrik CDM 7.0以降でサポートされ、両者ともNAS Cloud Directでもサポートされるとされています。
ここが今回の記事の最重要ポイントです。
Azure Blob Storage
↓
Azure APIを利用した
Cloud Native Protection
Azure Files / ANF
↓
File / NAS Workloadとして
CCES または NAS Cloud Direct
つまり、
ストレージの名前だけでなく、「ObjectなのかFileなのか」を見て保護方式を決める
必要があります。
3. Azure Blob StorageはRSCで直接保護できる
Azure Blob Storageは、今回の3サービスの中では唯一、RSC Cloud Native Protectionの対象です。
RSCではAzure Blob Storage内のObjectを保護し、Recoveryできます。
概念的には、
Azure Subscription
│
▼
Storage Account
│
▼
Blob Container
│
├── Object A
├── Object B
└── Object C
│
▼
Rubrik Security Cloud
│
├── SLA Domain
├── Snapshot
├── Archive
└── Recovery
という形です。
4. Blob StorageをRubrikで守るメリット
RubrikはAzure Blob Storage保護について、
- Immutable Snapshot
- 別LocationへのSnapshot保存
- 低コストStorage Tierへの保存
- SLAベースの管理
- Storage Account全体のRecovery
- 特定ObjectだけのRecovery
などを提供しています。
特に重要なのが、
Storage Account全体を戻さなくても、特定ObjectだけRecoveryできる
ことです。
例えば、
container-a
├── image001.jpg
├── image002.jpg
├── report.pdf
└── database-export.json
のうち、
report.pdf
だけを戻す、といったRecoveryができます。
5. Azure Blob Storage保護ではArchival Locationが必要
Azure VMとの違いとして覚えておきたいポイントがあります。
RSCでAzure Blob Storageを保護する場合、Rubrikの設定フローではArchival Locationを作成することが前提になっています。
概念的には、
Azure Blob Storage
│
▼
RSC Protection
│
▼
Immutable Backup Copy
│
▼
Archival Location
です。
その後、
Archival Location
↓
SLA Domain
↓
Storage AccountへAssign
という流れになります。
6. Storage Account単位だけでなくContainerを除外できる
実務では、
Storage Account
│
├── container-production
├── container-log
├── container-cache
└── container-temp
のすべてを同じRetentionで守るとは限りません。
RSCではStorage Accountを保護しながら、特定Containerを保護対象から除外できます。
例えば、
Production Data
↓
Backupする
Log
↓
Backupする
Temporary Data
↓
除外する
といった設計が可能です。
これはコスト管理でも重要です。
7. Azure Blobなら何でも守れるわけではない
ここから制約です。
RubrikのAzure Blob Storage ProtectionでサポートされているBlob Typeは、
Block Blob
です。
一方、
- Page Blob
- Append Blob
はサポートされていません。
整理すると、
| Blob Type | Rubrik Protection |
|---|---|
| Block Blob | ○ |
| Page Blob | × |
| Append Blob | × |
Azure Blob Storageを使っているからといって、その中のBlob Typeを確認せずに設計してはいけません。
8. Source BlobのTierにも制約がある
Source側のStorage Tierについては、
| Source Tier | Rubrik Protection |
|---|---|
| Hot | ○ |
| Cool | ○ |
| Cold | ○ |
| Archive | × |
です。
つまり、
Archive TierのObject
↓
RubrikでさらにBackup
という使い方は、現行仕様ではサポートされません。
ここは、
Rubrik Backupの保存先としてArchive Tierを使える
ことと混同しないよう注意が必要です。
Source ObjectがArchive Tier
×
Backup CopyをArchive Tierへ保存
○（構成による）
は別の話です。
9. ADLS Gen2を利用している場合の注意
Azure Blob StorageではHierarchical Namespaceを有効にすることで、Azure Data Lake Storage Gen2として利用できます。
RSCはADLS-enabled Storage Accountも扱えますが、Incremental Snapshotには注意があります。
RubrikはObjectの変更をBlobのLast Modified Timeで検出します。
そのため、
Blob Data自体は変更せずMetadataだけを変更した場合、それを変更として認識せず、新しいBackupが作成されない
場合があります。
例えば、
Blob Data
変更なし
ACL / Metadata
変更あり
だけの場合は注意が必要です。
10. ADLS → non-ADLS Recoveryにも制約
ADLS-enabled Storage Accountを通常のnon-ADLS Storage AccountへRecoveryすること自体は可能です。
ただし、
- Owner
- ACL
- 一部Properties
- Empty Directory
などは完全にはRecoveryされません。
つまり、
Object Data Recovery
○
File System Semanticsの完全再現
×の場合あり
です。
特にData Lake用途では重要です。
11. Storage AccountそのもののMetadataも完全復旧ではない
Storage Account Export時には、
Storage Account LevelのMetadataはRecoveryされず、選択したBlob Level / Container Level MetadataがRestore対象
となります。
つまり、
Dataが戻る
≠
Storage Account Configurationが
完全に元通り
です。
これはAzure VMで、
VM Backup
≠
VNetやPPGを含むAzure環境完全再現
だったのと同じ考え方です。
12. Azure Blob StorageのPrivate Endpointにも対応
セキュリティ要件の厳しい企業では、
Storage Account
Public Network Access = Disabled
という構成も多いと思います。
RubrikではAzure Blob Storage Protection用にAzure Private Endpointを構成する手順が用意されています。
13. 次はAzure Files
Azure FilesはBlobとは性質が大きく異なります。
Azure Filesは、
SMB / NFSでMountして利用するファイル共有
です。
例えばWindows系なら、
Windows VM
│
│ SMB
▼
Azure Files
│
├── Department
├── Home
└── Application Data
です。
LinuxではNFS Azure File Shareを利用できます。
Azure Filesは現在、SMBとNFSをサポートしています。NFS ShareではNFSv4.1が利用されます。
14. Azure FilesはCloud Native Protectionではない
ここは重要です。
Azure VMやAzure Blob Storageと違い、
Azure FilesはRSC Cloud Native Protectionの対象ではありません。
Rubrik Compatibility Matrixでは、
Azure Files
Cloud Native Protection
×
Rubrik CCES
○
NAS Cloud Direct
○
となっています。
したがって、
「Azure Cloud Accountを登録してBlobと同じようにSLA Domainを付ければ終わり」
という保護方式ではありません。
15. Azure FilesをNAS Cloud Directで守る
Azure Filesについては、Rubrik NAS Cloud DirectのAPI Integrationがサポートされています。
RubrikのCompatibility Matrixでは、
Azure Files：SMBおよびNFSv4.1のみ
と明記されています。
つまり、
Azure Files
│
├── SMB
│ ○
│
└── NFSv4.1
○
です。
NAS Cloud Directは大規模なUnstructured File Data向けの保護サービスで、Incremental-Forever型のProtectionを提供します。
データ移動には保護対象NASに近い場所へ配置されたStateless VMを利用し、Azure BlobなどのObject StorageへBackup Dataを保存できます。
16. Azure Filesでは「Protocol」が設計項目になる
Azure VMのDisk Protectionでは、
Premium SSD？
Ultra Disk？
を確認しました。
Azure Filesでは代わりに、
SMB？
NFS？
を確認する必要があります。
さらにSMBなら、
- SMB Version
- Authentication
- Encryption
- ACL
- Service Account
なども関係します。
NAS Cloud Directでは、
- SMB 2：○
- SMB 3：○
- SMB 1：×
です。
17. SMB Encryptionにも注意
NAS Cloud DirectのSMB Encryptionは「Partial Support」とされています。
現行Compatibility Matrixでは、NAS CDのSMB ClientはAES-CCMのWire Encryptionに対応していますが、暗号化の有効化はServer側から要求されることが前提です。
Azure Files側では現在、SMB 3.xのChannel Encryptionとして複数の暗号化方式をサポートしています。
そのため、厳しいSMB Security Policyを利用している場合は、
Azure Files側のSMB Security設定とNAS CDのCompatibilityを事前確認する
必要があります。
18. Azure NetApp Filesは何が違う？
Azure NetApp FilesはAzure Filesよりも高性能・高機能なEnterprise File Storageです。
Azure NetApp Filesでは、
- NFSv3
- NFSv4.1
- SMB
- Dual Protocol
を利用できます。
例えば、
SAP HANA
│
NFS
│
Azure NetApp Files
や、
Enterprise File Server
│
SMB
│
Azure NetApp Files
という構成です。
19. Azure NetApp FilesもCloud Native Protectionではない
ANFについても、
Azure NetApp Files
Cloud Native Protection
×
Rubrik CCES
○
NAS Cloud Direct
○
です。
つまりBlob Storageとは保護モデルが異なります。
20. Azure NetApp Files × NAS Cloud Direct
Rubrik NAS Cloud DirectはAzure NetApp Filesをサポートしています。
現行Compatibility Matrixでは、Generic SMBのSupported PlatformとしてAzure NetApp Filesが明示されています。
ただし、NFSについては少し注意が必要です。
NAS CD自体はNFSv3およびNFSv4.1をサポートしますが、NFSv4.1についてはCompatibility Matrix上で特定Platformが個別列挙されています。
そのためAzure NetApp FilesをNFSv4.1で利用している場合には、
ANF対応だからNFSv4.1も自動的に対応、と断定せず、最新Compatibility MatrixまたはRubrik Supportで対象Protocolを確認する
のが安全です。
21. ANFはSAP HANAでも特殊な使われ方をする
Azure NetApp Filesは一般的なNAS Backupだけでなく、SAP HANAのData Volumeとして使われることもあります。
RubrikではAzure VM上のSAP HANAとANFを組み合わせた構成について、CCES 9.1.1以降でStorage Snapshotを利用した保護Workflowも提供しています。
この場合は、
Azure NetApp Filesを
単なるNASとしてBackup
するのではなく、
SAP HANA
+
Azure NetApp Files
+
Application-aware Protection
として考えます。
これはかなり重要な違いです。
22. 同じANFでも用途によって保護方式を変える
例えば、
一般ファイル共有
Azure NetApp Files
↓
SMB
↓
Department Share
なら、
NAS Cloud Direct
が候補になります。
一方、
SAP HANA Data Volume
SAP HANA
↓
Azure NetApp Files
なら、
SAP HANA Workload Protection + Storage Snapshot
として考えた方が適切です。
つまり、
「ANFだからこのBackup方式」と決めるのではなく、ANF上で何が動いているかを見る
必要があります。
23. NAS Cloud Directとは何か
Azure VM編ではあまり登場しなかったため、簡単に整理します。
NAS Cloud Directは、
大規模Unstructured Dataを保護するためのRubrikのNAS Backup方式
です。
特徴として、
- Incremental-Forever
- Policy-based Backup / Archive
- 大規模NAS対応
- Stateless VMによるData Movement
- Cloud Object StorageへのBackup
- Latency-aware throttling
などがあります。
概念的には、
Azure Files / ANF
│
▼
NAS Cloud Direct
Stateless Data Mover
│
▼
Backup Storage
│
├── Azure Blob
├── Rubrik Cloud Vault
└── その他Object Storage
となります。
24. NAS Cloud DirectのBackup先としてAzure Blobも使える
少し面白い構成です。
Azure FilesやANFをNAS Cloud Directで保護し、
Source
Azure Files
↓ Backup
Destination
Azure Blob Storage
という設計もできます。
NAS CDのBackup Destinationでは、
- Azure Hot
- Azure Cool
- Azure Cold
- Azure Archive
がサポートされています。
さらにこれらについて、Compatibility MatrixではImmutabilityもサポート対象として掲載されています。
つまりAzure Blob Storageは、
保護されるSource
にも、
Backup Destination
にもなり得ます。
ここを混同しないことが重要です。
25. Azure Blob Storageは2つの顔を持つ
整理すると、
パターン1：Blob自体を保護
Business Data
↓
Azure Blob Storage
↓
RSC Cloud Native Protection
パターン2：Backup保存先として利用
Azure Files / ANF
↓
NAS Cloud Direct
↓
Azure Blob Storage
です。
同じ「Azure Blob」でも役割が違います。
26. 3サービスのRecovery粒度を考える
Backup製品では「取れるか」だけでなく、
どの単位で戻したいか
を先に考えるべきです。
例えば、
Azure Blob
Storage Account全部
or
Object 1個
Azure Files
File
Folder
File Share
Azure NetApp Files
File
Folder
Volume
Application Data
です。
必要なRecovery粒度によって、最適な保護方式も変わります。
27. 3サービスを比較するとどうなる？
今回の内容をまとめます。
| 項目 | Azure Blob Storage | Azure Files | Azure NetApp Files |
|---|---|---|---|
| Storage種別 | Object | File | Enterprise File |
| SMB | × | ○ | ○ |
| NFS | NFSv3構成あり | NFSv4.1 | NFSv3 / v4.1 |
| RSC Cloud Native | ○ | × | × |
| Rubrik CCES | × | ○ | ○ |
| NAS Cloud Direct | ― | ○ | ○ |
| Object単位Recovery | ○ | ― | ― |
| File単位Protection | ― | ○ | ○ |
| SAP HANA用途 | ― | ― | ○ |
| 主な確認点 | Blob Type / Tier | Protocol | Protocol / Workload |
28. では、どの方式を選べばよい？
かなり単純化すると次のように考えられます。
Azure Blob Storage？
│
YES
↓
RSC Cloud Native Protection
Azure Files？
│
YES
↓
NAS Cloud Direct
またはCCES
Azure NetApp Files？
│
↓
一般ファイル共有？
│
YES
↓
NAS Cloud Direct
│
NO
↓
SAP HANAなどApplication Workload？
↓
Application Native Protectionも検討
29. 「Azure標準BackupがあるからRubrik不要？」という考え方
Azure FilesやANFにはAzure / NetApp側にもSnapshotやBackup機能があります。
例えばAzure FilesにはShare SnapshotやAzure Backupとの統合があります。
ANFもNative Snapshot、Backup、Cross-region Replicationなど複数のData Protection機能を持っています。
そのため、
「Native BackupかRubrikか」
という二者択一より、
Local Snapshot
↓
短時間Recovery
+
Rubrik
↓
独立Backup / Long-term Retention / Cyber Recovery
という役割分担で考えるのも一つの方法です。
30. Ransomware対策として重要なのは「別コピー」
特にFile / Object Storageでは、
Production Data
+
Snapshot
だけではなく、
Production
│
▼
Independent Backup Copy
│
▼
Immutable Storage
を持つことが重要です。
RSCのAzure Blob Storage ProtectionはImmutable Snapshotを別Locationへ保存することを目的の一つとしており、RubrikのAzure Archival LocationでもImmutabilityを利用できます。
NAS Cloud DirectでもAzure Storage TierへのBackupについてImmutability対応が掲載されています。
31. 設計時のチェックリスト
最後に3サービス共通の確認項目をまとめます。
| # | 確認項目 | Check |
|---|---|---|
| 1 | 対象はBlob / Files / ANFのどれか | ☐ |
| 2 | Object StorageかFile Storageか | ☐ |
| 3 | Rubrik Cloud Native Protection対象か | ☐ |
| 4 | CCESが必要か | ☐ |
| 5 | NAS Cloud Directが必要か | ☐ |
| 6 | 必要なRecovery粒度を決めたか | ☐ |
| 7 | Azure BlobのBlob Typeを確認したか | ☐ |
| 8 | Block Blobか | ☐ |
| 9 | Page / Append Blobがないか | ☐ |
| 10 | Source Tierを確認したか | ☐ |
| 11 | Archive Tier Objectを保護しようとしていないか | ☐ |
| 12 | ADLS Gen2を利用しているか | ☐ |
| 13 | ADLS ACL / Metadata Recovery要件を確認したか | ☐ |
| 14 | Azure Blob用Archival Locationを準備したか | ☐ |
| 15 | Container除外設計を行ったか | ☐ |
| 16 | Private Endpointが必要か | ☐ |
| 17 | Azure FilesのProtocolを確認したか | ☐ |
| 18 | SMBかNFSv4.1か | ☐ |
| 19 | SMB Security設定を確認したか | ☐ |
| 20 | Azure NetApp FilesのProtocolを確認したか | ☐ |
| 21 | ANFが一般NAS用途かApplication用途か | ☐ |
| 22 | SAP HANA等でANFを使用していないか | ☐ |
| 23 | Backup Destinationを決めたか | ☐ |
| 24 | Immutabilityが必要か | ☐ |
| 25 | RPO / RTOを決めたか | ☐ |
| 26 | Native Snapshotとの役割分担を決めたか | ☐ |
| 27 | Recovery Test方法を決めたか | ☐ |
| 28 | 最新Rubrik Compatibility Matrixを確認したか | ☐ |
32. まとめ
今回最も重要なのは、
AzureのStorage Serviceだからといって、Rubrikでの守り方は同じではない
ということです。
整理すると、
Azure Blob Storage
│
▼
RSC Cloud Native Protection
に対し、
Azure Files
│
▼
CCES / NAS Cloud Direct
そして、
Azure NetApp Files
│
├── General NAS
│ ↓
│ NAS Cloud Direct
│
└── Application Storage
↓
Workload Protection
です。
さらにAzure Blob Storageでは、
Block Blob ○
Page Blob ×
Append Blob ×
Hot ○
Cool ○
Cold ○
Archive Source ×
という制約があります。
Azure FilesではProtocolを確認し、
SMB
NFSv4.1
とNAS Cloud DirectのCompatibilityを確認します。
Azure NetApp Filesではさらに、
「どのProtocolを使っているか」だけでなく、「そのVolume上で何を動かしているか」
を見ることが重要です。
最終的には、
何を保存している？
↓
Object？ File？
↓
どのAzure Service？
↓
どのProtocol？
↓
どのRecovery粒度が必要？
↓
Cloud Native？
CCES？
NAS Cloud Direct？
↓
Backup Destinationは？
↓
Immutable？
↓
RTO内にRecoverできる？
まで考えて初めて、Azure Storage全体のData Protection設計が成立します。
次回以降はさらに掘り下げます
今回は、Azure Blob Storage、Azure Files、Azure NetApp Filesを横断的に整理しました。
次回以降は、それぞれのサービスについて、実際の設計や運用で気になる制約やRecovery方法を、より詳しく掘り下げていきます。
まずはAzure Blob Storageについて、
【Rubrik × Azure Blob Storage｜制約編】Block Blobは守れる？Tier・ADLS・Private Endpointの注意点を整理する
として、次のポイントを詳しく見ていく予定です。
- Block / Append / Page Blobの違いとRubrikの対応範囲
- Hot / Cool / Cold / Archive Tierごとの注意点
- ADLS Gen2利用時の制約
- Container Exclusionの考え方
- Object Recoveryの方法
- Private Endpoint環境での保護
- Immutabilityの考え方
- Storage Tiering
- Ransomware Recovery
Azure Blob Storageは、同じStorage Account内でもBlob TypeやTier、Network構成によって設計上の注意点が変わります。
次回は、「Rubrikでどこまで守れるのか」「どこに制約があるのか」 を、より実務寄りに整理していきます。
参考資料
- Rubrik Compatibility Matrix：Cloud data protection with Rubrik Security Cloud
- Rubrik Documentation：Azure Blob Storage
- Rubrik Documentation：Feature support in Azure Blob Storage
- Rubrik Compatibility Matrix：Rubrik NAS Cloud Direct
- Rubrik Documentation：NAS Cloud Direct data sets
- Microsoft Learn：Azure Files
- Microsoft Learn：Azure NetApp Files
- Microsoft Learn：Azure Files / Blob Storage / Azure NetApp Files NFS comparison