【Rubrik × Azure VM｜復旧編】データが戻ればDR成功？Restore・Export・Cross-Region Recoveryを整理する

Posted at 2026-09-16

Azure VMのSnapshotをRubrik Security Cloud（以下、RSC）で取得している。

別RegionへのReplicationも設定している。

障害時に使えるRecovery Pointも確認できている。

それなら、

「DR対策は完了している」

と言えるでしょうか。

答えは、必ずしもそうではありません。

たとえば、

Snapshot
   ○

Disk Recovery
   ○

VM Allocation
   ×

というケースがあります。

さらにVMが起動しても、

VM
   ○

Network
   ×

Application
   ×

なら、業務サービスとしては復旧していません。

Rubrik × Azure VMシリーズでは、これまで、

VM / Managed Diskの対応範囲
Premium SSD v2 / Ultra Disk
Availability Zone
Proximity Placement Group（PPG）
ADE / Encryption at Host
Azure Policy
Application Consistency
File Recovery
Exocompute

などを個別に整理してきました。

今回はシリーズの復旧編として、これらを、

「実際にサービスを復旧できるのか？」

という観点からつなげます。

特に押さえたいのが、

Restore
Export
Replicated Copy / Archived CopyからのRecovery
Cross-Zone Recovery
Cross-Region Recovery
Cross-Subscription Recovery
Azure側のQuota / Capacity
暗号化やNetwork Access Policy

です。

※本記事は2026年9月時点の公開情報をもとにしています。Rubrik公式ドキュメント内で一般説明ページとCompatibility Matrixの記述に差がある項目については、対応可否はCompatibility Matrixを優先して整理しています。

1. まずRubrikのAzure VM Recovery方法を整理する

RSCでは、Azure VM / Managed Diskに対して複数のRecovery方法を提供しています。

代表的なものは次のとおりです。

Recovery方式	主な用途	Recovery対象
VM Restore	既存VMを過去の状態へ戻す	VM
VM Export	Snapshotから新しいVMを作成	VM
Managed Disk Export	新しいManaged Diskを作成	Disk
Virtual Disk Mount	DiskをVMへ接続してデータを参照	Disk
File / Folder Recovery	Storage Accountへファイルを復旧	File / Folder
In-place File Recovery	元VMまたは別VMへ直接ファイルを復旧	File / Folder

Rubrik公式ドキュメントでも、VM Restore / Exportに加え、Disk MountやFile Recoveryなど複数のRecovery Optionが用意されています。

つまり、

障害
 ↓
とりあえずVM Restore

ではありません。

何が壊れたか、どの粒度で戻したいかによってRecovery方法を選びます。

2. RestoreとExportは何が違う？

Restore

Restoreは、既存VMをSnapshot取得時点へ戻す処理です。

Rubrik公式ドキュメントでは、RSCがSnapshotからManaged DiskのCopyを作成し、既存VMのDiskを置き換えると説明されています。

概念的には、

現在

VM-A
 ├─ OS Disk Current
 └─ Data Disk Current

        ↓ Restore

VM-A
 ├─ OS Disk Snapshot Copy
 └─ Data Disk Snapshot Copy

です。

つまり、

同じVMを過去の状態へ巻き戻す

操作です。

Export

Exportは、Snapshotから新しいAzure VMを作成する処理です。

Source VM
   ↓
Snapshot
   ↓
Rubrik Export
   ↓
New Azure VM

RSCのVM Exportでは、Recovery先として次のような項目を指定できます。

Subscription
Resource Group
Region
Availability Zone
VM Size
VNet
Subnet
NSG
Availability Set
Tags
Accelerated Networking
Power State
RecoveryするDisk

そのため、

別AZ・別Region・別Subscriptionへ新しいVMとして復旧したい場合はExportが重要

になります。

3. RestoreではOS Diskを必ず戻す

VM Restoreでは、すべてのDiskがデフォルトでRecovery対象になります。

Data Diskは選択解除できますが、

OS Diskは必須で、選択解除できません。

たとえば、

VM

OS Disk       ← 必ずRestore
Data Disk 1   ← Restore
Data Disk 2   ← Restore
Data Disk 3   ← Restoreしない

という選択は可能です。

4. Original / Replica / ArchiveからRecoveryできる

Rubrikの重要な特徴の一つが、Recovery Sourceを選べることです。

構成されていれば、

Original Copy

Replicated Copy

Archived Copy

からRestore / Exportできます。

Original CopyがRetention切れでExpireしている場合でも、ReplicaやArchiveが残っていればRecovery Sourceとして利用できます。

たとえば、

Original
7日

Replica
30日

Archive
1年

なら、

30日前のVMを戻すときはReplicaまたはArchiveを利用できます。

5. Snapshot Replicationはどう動く？

RubrikのAzure Snapshot Replicationは、SLA Domainに設定したReplication TargetへSnapshot Dataをコピーします。

Rubrik公式では、Replication Jobは30分ごとに実行され、AzureのGet Page RangesとPut Pages from URL APIを利用して変更PageをIncrementalに別Regionへコピーすると説明されています。

概念的には、

Japan East
Managed Disk Snapshot
        │
        │ Incremental Replication
        ▼
Japan West
Replica Snapshot

です。

Target Regionでは、Replica DataはAzure Storage上のLRSとして保持され、必要に応じてRestore / Exportに利用できます。

6. ReplicationがあるだけではDRは完成しない

Replicationが完了すると、

Recovery Pointが別Regionにも存在する

状態になります。

しかし、

Replication Completed

は、

DR Completed

ではありません。

ReplicaからVMを作成するためには、Recovery先Azure環境が、

VM Size
Availability Zone
Quota
Capacity
Disk
Network
Security

などの条件を満たす必要があります。

7. Replication Targetを変更したときの注意

これはDR設計で見落としやすいポイントです。

たとえば最初、

Japan East
   ↓
Japan WestへReplication

していたとします。

その後Replication Targetを、

Australia East

へ変更したとします。

Rubrik公式ドキュメントでは、

Target変更後に作成されたSnapshotだけが新しいRegionへReplicationされる

とされています。

つまり、

Japan Westにある過去Replica
        ↓
Australia Eastへ自動コピー

されるわけではありません。

したがってReplication Target変更時には、

新Regionに十分なRecovery Pointが蓄積されたか

まで確認する必要があります。

8. Japan East → Japan WestのDRを考える

たとえば本番VMが、

Japan East
Zone 1

Standard_E64ds_v5

OS Disk
Premium SSD

Data Disk
Premium SSD v2

Accelerated Networking
ON

PPG
PPG-PROD

だったとします。

Japan WestへReplicaを持っていても、実際のRecovery時には、

Japan West

Target AZは？

Standard_E64ds_v5は利用できる？

vCPU Quotaは十分？

物理Capacityはある？

Premium SSD v2は利用可能？

Accelerated Networkingは？

VNet / Subnetは？

NSGは？

PPGはどうする？

まで確認する必要があります。

9. QuotaとCapacityは別物

Azure DRで特に重要なのが、

Quota

と、

Capacity

の違いです。

Quotaは、

SubscriptionがそのRegionで利用を許可されているvCPU等の上限

です。

Capacityは、

実際にAzureがそのRegion / AZで提供できる物理Compute Resource

です。

Microsoftは現在、QuotaとCapacityを別々に確認すると明記しています。

そのため、

必要vCPU
64

Quota
100

Quota
○

でも、

Target AZに
Standard_E64ds_v5のCapacityなし

Capacity
×

ならDeploymentは失敗します。

つまり、

Quotaが十分だからDRできる

とは限りません。

10. 旧世代VM SKUにも注意する

2026年7月以降、Azureでは複数の旧世代VM SeriesにCapacity Growth Restrictionが導入されています。

Microsoftは、対象Seriesについて、

新規Deployment
Quota Increase
Capacity Expansion

が制限される可能性があると案内しています。

既存Quota内でも、実際のCapacity Availabilityは保証されません。

そのためDR Runbookでは、

第一候補
Sourceと同じVM Size

第二候補
新しいGenerationの同等VM Size

第三候補
CPU / Memory要件を満たす別Family

のように代替VM Sizeも決めておくことをおすすめします。

11. Recovery先VM SizeはDisk数にも影響する

たとえばSource VMが、

OS Disk × 1
Data Disk × 32

だったとします。

Recovery先VM SizeのData Disk上限が16枚なら、

Snapshot
 ○

Disk Data
 ○

Target VM Size
 ×

となります。

そのため代替VM Sizeを選ぶときは、

vCPU
Memory
NIC数
Data Disk数
Accelerated Networking

まで確認する必要があります。

12. Availability Zoneを指定できても配置できるとは限らない

VM ExportではAvailability Zoneを指定できます。

しかし、

Japan West
AZ2を選択できる

ことと、

Japan West AZ2に
そのVM SKUを配置できる

ことは別です。

Azure側でCapacityが不足していれば、Allocation Failureになります。

これが、

Snapshotが正常でもVMが起動できない

代表的なパターンです。

13. PPGは標準Export項目に含まれていない

配置編で取り上げたProximity Placement Group（PPG）も、DR時に注意が必要です。

Rubrik公式のVM Export手順では、

Region
AZ
VM Size
VNet
Subnet
NSG
Availability Set
Accelerated Networking

などは選択できます。

一方、標準手順にはPPGの指定項目は掲載されていません。

そのため、

Source VM
   ↓
PPG-PROD

だったとしても、

Export VM
   ↓
PPG-PRODへ自動再配置

を前提にしてはいけません。

PPGを利用するシステムでは、Export後の配置手順を別途Runbook化する必要があります。

14. VM Recovery ≠ Network Recovery

VM ExportではVNet、Subnet、NSGを指定できます。

しかし、

Route Table
Azure Firewall
Load Balancer
Application Gateway
DNS
Private Endpoint
NAT Gateway

などのAzure Resourceまで、VM Snapshotからすべて完全再構築されるわけではありません。

したがって、

Rubrik
VM Data Recovery

と、

Terraform / Bicep / ARM
Infrastructure Recovery

を組み合わせる設計が重要です。

15. TagsもRecovery時に扱える

VM RestoreではRestore Tagsを選択すると、VMとManaged DiskのTagをSnapshot取得時点へ戻せます。

選択しない場合、

VM Tagは変更されない
RestoreされたDiskにはRubrik Metadata Tagのみ付く

という動作です。

VM ExportにもSource Snapshot取得時点のTagをCopyするOptionがあります。

Tagを、

Azure Policy
Cost Management
Automation
Monitoring

などに利用している環境では確認しておきたいポイントです。

16. Generalized VMはRestore非対応

Rubrik公式では、

Generalized Azure VMのRestoreは非対応

です。

Generalized VMはOS Diskを置き換えた後に既存VMとしてRestartできないためです。

通常VM
  ↓
Restore ○

Generalized VM
  ↓
Restore ×

Image作成用途などでGeneralizeしたVMには注意が必要です。

17. Shared DiskのRestoreは特殊

Shared Diskを持つVMではRestore動作が通常と異なります。

Rubrik公式では、

Restore対象VMからShared DiskをDetach
SnapshotからShared Diskの新しいCopyを作成
Restore対象VMへ新Copyを接続
元Shared Diskは他VMに接続されたまま

となります。

イメージすると、

Restore前

       Shared Disk
       /        \
    VM-A        VM-B

VM-AをRestoreすると、

Restore後

VM-A                 VM-B
 │                    │
New Copy          Original
                  Shared Disk

です。

したがって、

Cluster VMのRestore成功 ≠ Cluster全体のRecovery成功

です。

18. ADE VMのRecoveryを正確に整理する

ここは公式情報を再精査して修正したポイントです。

Rubrik Compatibility Matrixでは、Azure Disk Encryption（ADE）VMについて、

Primary Backup：○
Archive：○
Replication：○
Same Region / Same Subscription Recovery：○
Cross-Subscription Recovery：×
Indexing：×
Virtual Disk Mount：×

とされています。

※Rubrikの一般的なSnapshot説明ページにはADE Indexingをサポートするように読める記述もありますが、本記事では対応可否についてCompatibility Matrixを優先しています。

19. ADE VMのCross-Region Exportは可能

ADEについて、特に重要なのがここです。

Rubrik公式のVM Export手順では、

ADE VMのCross-Region Exportを実行する場合、暗号化KeyとSecretをTarget Regionの新しいAzure Key Vaultへ事前に移行する

よう明記されています。

したがって、

Japan East
ADE VM
   ↓
Rubrik Snapshot
   ↓
Japan WestへVM Export

は可能ですが、

Snapshotだけあればよい

わけではありません。

Snapshot
   +
Encryption Key
   +
Secret
   +
Target Key Vault

まで含めてDR設計する必要があります。

20. ADEのCross-Subscription Recoveryは非対応

一方、Compatibility Matrixでは、

ADE VMを別SubscriptionへRecoveryすることは非対応

です。

整理すると、

ADE VM

Same Subscription
Same Region
○

Cross Region VM Export
○
※Key / Secretの事前移行必要

Cross Subscription
×

です。

21. VM ExportとManaged Disk ExportでADE条件が異なる

もう一つ重要な注意です。

Rubrik公式のVM ExportではADE VMのCross-Region Export手順が用意されています。

一方、Managed Disk単体のExportでは、

ADE-encrypted VM由来のManaged DiskはSource VMと同じRegionへのExportのみ

と公式手順に記載されています。

つまり、

ADE VMをVMとしてCross-Region Export
○

ADE Managed Diskを単体でCross-Region Export
×

と、Recovery方式によって制約が異なります。

これは実務でかなり重要な違いです。

22. Trusted LaunchはRecovery可能だがReplication非対応

Trusted Launch VMについて、Rubrik Compatibility Matrixでは、

Same Region Recovery：○
Same Subscription Recovery：○
Cross-Region Recovery：○
Cross-Subscription Recovery：○

をサポートしています。

しかし、

Snapshot Replicationは非対応

です。

つまり、

Cross-Region Recovery
○

事前にRemote Regionへ
Snapshot Replication
×

です。

これはDR設計上非常に重要です。

Regional Disaster対策で、

「Japan WestにReplicaを常時持つ」

ことを要件にしている場合、Trusted Launch VMではこの制約を事前に確認する必要があります。

23. Encryption at Host

Encryption at Hostを有効にしたVMでは、Compatibility Matrix上、

Source SnapshotからExport：○
Archived SnapshotからExport：○
Replicated SnapshotからExport：○
Cross-Region Export：○
Cross-Subscription Export：○

です。

ただし、

Backupを有効化するにはRubrik Supportへの問い合わせが必要

です。

またCross-Subscription Exportでは、関連SubscriptionでEncryption at Hostを有効化する必要があり、その支援についてもRubrik Supportへの問い合わせが案内されています。

24. SSE + CMKはさらに注意

Rubrik Compatibility Matrixでは、

Storage Service EncryptionをCMKで暗号化したVM / Managed DiskはRSCで保護できない

と記載されています。

つまり、

Recoveryできるか？

以前に、

そもそもProtection対象か？

を確認する必要があります。

暗号化構成はDR Runbookだけでなく、Backup設計段階で確認してください。

25. SnapshotのNetwork Access Policyにも注意

セキュリティ編でも扱いましたが、Recovery時にもNetwork Access Policyは重要です。

RSCはAzure Disk / SnapshotのDataを読むためにSAS URIを利用します。

Rubrik公式では、Public Accessが無効な環境でPrivate Accessを利用する場合、

Private access to snapshots Permission Category
Exocompute SubscriptionのPrivate endpoints Permission Category

が必要とされています。

つまり、

Snapshot
○

Permission
×

Private Endpoint
×

なら、高度なSnapshot処理に影響する可能性があります。

26. Replication中はPrivate Accessを維持できない

これは特に重要です。

Rubrik公式のReplication Documentationでは、

Replication Jobの実行中、Private Accessを有効なまま維持することはサポートされない

とされています。

デフォルトでは、必要に応じてNetwork AccessをPublicへ切り替えてReplication処理を行います。

一方、Archivingなど他のOperationではPrivate Accessを維持できます。

したがって、

企業Azure Policy
Public Accessを完全禁止

という環境では、

Rubrik Snapshot Replicationとの整合性を事前確認する

必要があります。

これはセキュリティ設計とDR設計が直結するポイントです。

27. Virtual Disk Mountという中間Recoveryもある

VM全体をRestore / Exportするほどではないが、

「Disk内の大量データを直接確認したい」

ケースではVirtual Disk Mountも利用できます。

Rubrikでは、Source / Replicated / Archived Snapshotから選択したVirtual Diskを、

同じSubscription
別Subscription
別Region
別Resource Group

のTarget VMへMountできます。

つまり、

VM全体Restore

と、

File 1個Recovery

の中間的な手段として利用できます。

ただしADEではVirtual Disk MountはCompatibility Matrix上非対応です。

28. File RecoveryではExocomputeも関係する

File / Folder Recoveryでは、Source / Replicated / Archived SnapshotをRecovery Sourceとして選択できます。

Azure Storage AccountへFileをRecoveryする場合、Target SubscriptionにはExocompute HostがMapされている必要があります。

In-place File Recoveryなら、

Indexed Snapshot
      ↓
RBS
      ↓
Exocompute
      ↓
Source VM / Other VM

という追加要件もあります。

そのためDRでは、

VM全体のRecoveryだけでなく、File Recovery経路も別途テストする

価値があります。

29. RPOとRTOを分けて考える

RPO

Recovery Point Objective。

どの時点までのData Lossを許容するか

です。

RTO

Recovery Time Objective。

障害発生から何分・何時間でServiceを再開するか

です。

RTOには、

Recovery Point選択
↓
Replica / Archive Access
↓
Disk生成
↓
Azure VM Allocation
↓
Network
↓
OS Boot
↓
Application Start
↓
Business Validation

まで含まれます。

したがって、

Snapshotを30分間隔で取っているからRTOも30分

ということにはなりません。

30. Recovery SourceによってRTOは変わる

同じRecovery Pointでも、

Original

Replica

Archive

では処理経路が異なります。

そのため、

「1年間Backupを保存している」

ことと、

「1年前のVMを30分以内で復旧できる」

ことは別問題です。

DR Testでは、実際に利用する予定のRecovery Source、

Original
Replica
Archive

それぞれから必要に応じてRecovery時間を測ることをおすすめします。

31. VM Recovery Completed ≠ Business Recovery Completed

RSC上で、

Recovery Completed

と表示されても、Business Serviceが戻ったとは限りません。

Rubrik Recovery
Completed
     ↓
VM
Running
     ↓
OS
Running
     ↓
Application
Stopped

ならDRは完了していません。

また、

Application
Running

Database Connection
Failed

でも同じです。

DRの完了条件は、

VM Recovery
↓
OS確認
↓
Network確認
↓
Middleware確認
↓
DB接続確認
↓
Application確認
↓
Business Owner確認

まで定義するのが理想です。

32. Recovery Runbookを作る

たとえばJapan East → Japan WestのDRなら、Runbookは次のようになります。

STEP 1
障害判定

STEP 2
Recovery Point選択

STEP 3
Original / Replica / Archiveを確認

STEP 4
Target Subscription確認

STEP 5
Japan West Target AZ確認

STEP 6
VM SKU / Quota / Capacity確認

STEP 7
VNet / Subnet / NSG確認

STEP 8
暗号化Key / Key Vault確認

STEP 9
Rubrik Export

STEP 10
PPG等の配置を再設定

STEP 11
Load Balancer / DNS / Firewall切替

STEP 12
OS起動確認

STEP 13
Application起動

STEP 14
Business Validation

STEP 15
Traffic切替

33. 「Recoveryできるはず」ではなく実際にTestする

DRで最も危険なのは、

一度も復旧したことがないBackup

です。

設定上、

Backup ○
Replication ○
Archive ○

でも、

Quota不足
Capacity不足
Policy Deny
Key Vault設定不足
Network Access Policy
VNet未準備

で失敗する可能性があります。

AzureではQuotaとCapacityが別物なので、特に本番で利用している大きなVM SKUほど実際のRecovery Testが重要です。

34. 本番と近い条件でRecovery Testする

たとえば、

Test VM

2 vCPU
Standard SSD
1 Data Disk

だけを復旧して、

「DR試験成功」

とするのは不十分です。

本番が、

64 vCPU
32 Data Disks
Premium SSD v2
Accelerated Networking
PPG
Encryption

なら、

できるだけ同じConstraintを含めてRecovery Testした方が、実障害時の問題を発見できます。

35. DR方式を3パターンに分ける

パターン1：同じVMを迅速に戻す

Incident
   ↓
Restore
   ↓
Existing VM

向いているケース：

OS破損
誤変更
Application破損
Ransomwareからの巻き戻し

パターン2：同一Regionの別AZへ新規VMを作る

Japan East AZ1
      ↓
Snapshot
      ↓
Export
      ↓
Japan East AZ2

向いているケース：

AZ障害
元VMを残した検証Recovery
新しいVMとして復旧したい場合

パターン3：別RegionへDR

Japan East
      ↓
Replication
      ↓
Japan West
      ↓
Export
      ↓
Application Recovery

向いているケース：

Region障害
大規模Disaster
Business Continuity

この3つでは必要なRunbookも大きく異なります。

36. 復旧編チェックリスト

#	確認項目	Check
1	RestoreとExportの違いを理解したか	☐
2	障害種別ごとにRecovery方式を決めたか	☐
3	Original / Replica / Archiveのどれを使うか決めたか	☐
4	Replication Target変更時の挙動を理解したか	☐
5	Target Regionを決めたか	☐
6	Target AZを決めたか	☐
7	Target Subscriptionを準備したか	☐
8	Export / Restore Permissionを設定したか	☐
9	Target VM Sizeを決めたか	☐
10	代替VM Sizeを決めたか	☐
11	Regional vCPU Quotaを確認したか	☐
12	VM Family Quotaを確認したか	☐
13	Capacity不足を想定したか	☐
14	必要Disk数をTarget VMが接続できるか	☐
15	VNet / Subnet / NSGを準備したか	☐
16	Route / Firewall / DNSを確認したか	☐
17	Load Balancer等の外部Resourceを確認したか	☐
18	PPGを利用していないか	☐
19	PPG再配置Runbookを作成したか	☐
20	Shared Diskを利用していないか	☐
21	Cluster単位のRecovery手順があるか	☐
22	Generalized VMではないか	☐
23	ADEを利用しているか	☐
24	ADE Cross-Region時のKey / Secret移行を準備したか	☐
25	ADE Cross-Subscription非対応を理解したか	☐
26	Managed Disk単体ExportのADE Region制約を確認したか	☐
27	Trusted Launchを利用しているか	☐
28	Trusted LaunchのReplication非対応を理解したか	☐
29	Encryption at Hostを利用しているか	☐
30	Rubrik Support要件を確認したか	☐
31	SSE + CMKを利用していないか	☐
32	Snapshot Network Access Policyを確認したか	☐
33	Private Access用Permissionを確認したか	☐
34	Replication中のPublic Access要件とPolicyが整合するか	☐
35	RPOを定義したか	☐
36	RTOを定義したか	☐
37	Application Recovery手順を作成したか	☐
38	OriginalからRecovery Testしたか	☐
39	ReplicaからRecovery Testしたか	☐
40	Archiveから必要に応じてRecovery Testしたか	☐
41	Business OwnerによるValidation条件を定義したか	☐
42	最新Rubrik Compatibility Matrixを確認したか	☐

37. Azure VMシリーズの結論

ここまでAzure VMシリーズでは、

基礎編
↓
どんなVMを守れる？

Disk編
↓
どんなDiskを守れる？

配置編
↓
どこへVMを配置できる？

セキュリティ編
↓
暗号化・Policyを越えて戻せる？

高度機能編
↓
Application / File単位で戻せる？

復旧編
↓
本当にサービスを復旧できる？

という順番で整理してきました。

最終的に最も重要なのは、

Backupを取ることではなく、必要な時間内に必要な状態まで戻せること

です。

38. まとめ

RubrikでAzure VMのSnapshotが正常に取得できていても、

Snapshot
○

だけではDRは成立しません。

その先に、

Snapshot
↓
Recovery Copy
↓
Disk
↓
VM Size
↓
Availability Zone
↓
Quota
↓
Capacity
↓
Network
↓
Encryption
↓
OS
↓
Application
↓
Business Validation

があります。

Restoreは既存VMを過去の状態へ戻す方式です。

Exportは新しいVMを作成する方式で、Subscription、Region、Availability Zone、VM Size、VNet、Subnet、NSGなどを選択できます。

Original Copyだけでなく、構成されていればReplica / ArchiveからもRecoveryできます。

ただし、

Replicaが存在することと、Target RegionでVMを起動できることは別です。

AzureはQuotaとCapacityを別々に評価するため、Quotaが十分でもTarget Region / AZに物理CapacityがなければDeploymentは失敗します。

さらに、

ADE
Trusted Launch
Encryption at Host
SSE + CMK
Snapshot Network Access Policy

などは、それぞれ異なる制約を持ちます。

そのため最後に確認すべきなのは、

Backup成功？
    ↓
ではなく

Recovery Test成功？
    ↓
さらに

Application利用可能？
    ↓
さらに

Business再開可能？

です。

「データが戻った」ではなく、「サービスを再開できた」ときに初めてDR成功。

これが、Rubrik × Azure VMシリーズを通して最も重要なポイントです。

Azure VMシリーズ

基礎編：どんなVMでもバックアップできる？対応範囲と制約を整理する
Disk編：Premium SSD v2やUltra Diskも守れる？Managed Diskの制約を整理する
配置編：バックアップがあってもVMが起動できない？AZ・PPG・配置制約を整理する
セキュリティ編：暗号化されたVMも守れる？ADE・CMK・Azure Policyの注意点
高度機能編：VMバックアップだけでは足りない？Application ConsistencyとFile Recoveryを整理する
復旧編：データが戻ればDR成功？Restore・Export・Cross-Region Recoveryを整理する

参考資料

Rubrik Compatibility Matrix：Azure virtual machine supported features and limitations
Rubrik Documentation：Exporting Azure virtual machine snapshots
Rubrik Documentation：Restoring Azure virtual machine using a snapshot
Rubrik Documentation：Replication of Azure snapshots
Rubrik Documentation：Private access to an Azure snapshot
Rubrik Documentation：Mounting Azure virtual disks for data recovery
Rubrik Documentation：Recovering files or folders to an Azure storage account
Rubrik Documentation：Performing an Azure In-place File Recovery
Microsoft Learn：Azure Virtual Machines vCPU quotas
Microsoft Learn：Previous-generation VM size series capacity growth restrictions

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up