Azure VM バックアップについてAbout Azure VM backup

この記事では、Azure Backup サービスが Azure VM をどのようにバックアップするかについて説明します。This article describes how the Azure Backup service backs up Azure VMs.

バックアップ プロセスBackup process

Azure Backup が Azure VM のバックアップを完了する方法を説明します。Here's how Azure Backup completes a backup for Azure VMs.

  1. バックアップの対象として選択されている Azure VM に対して、Azure Backup サービスはユーザーが指定したバックアップ スケジュールに従ってバックアップ ジョブを開始します。For Azure VMs that are selected for backup, the Azure Backup service initiates a backup job in accordance with the backup schedule you specify.
  2. サービスはバックアップの拡張機能をトリガーします。The service triggers the backup extension.
    • Windows VM は VMSnapshot 拡張機能を使用します。Windows VMs use the VMSnapshot extension.
    • Linux VM は VMSnapshotLinux 拡張機能を使用します。Linux VMs use the VMSnapshotLinux extension.
    • 拡張機能は、最初の VM バックアップ中にインストールされます。The extension is installed during the first VM backup.
    • 拡張機能をインストールするには、VM が実行されている必要があります。To install the extension, the VM must be running.
    • VM が実行されていない場合、Backup サービスは基盤となるストレージのスナップショットを取ります (VM が停止している間はアプリケーション書き込みが行われないため)。If the VM is not running, the Backup service takes a snapshot of the underlying storage (since no application writes occur while the VM is stopped).
  3. バックアップ拡張機能によってストレージレベルのクラッシュ整合性/ファイル整合性スナップショットが作成されます。The backup extension takes a storage-level, crash consistent/file-consistent snapshot.
  4. スナップショットが作成されると、データはバックアップ コンテナーに転送されます。After the snapshot is taken the data is transferred to the vault. 効率を最大に高めるために、前回のバックアップ以降に変更されたデータ ブロック (差分) が特定され、そのデータのみが転送されます。To maximize efficiency, the service identifies and transfers only the blocks of data that have changed since the previous backup (the delta).
  5. データ転送が完了すると、スナップショットが削除され、回復ポイントが作成されます。When the data transfer is complete, the snapshot is removed and a recovery point is created.

Azure 仮想マシンのバックアップ アーキテクチャ

データの暗号化Data encryption

Azure Backup では、データはバックアップ プロセスの一部として暗号化されません。Azure Backup doesn't encrypt data as a part of the backup process. Azure Backup では、Azure Disk Encryption を使用して暗号化された Azure VM のバックアップがサポートされています。Azure Backup does support backup of Azure VMs that are encrypted using Azure Disk Encryption.

  • マネージドおよびアンマネージド Azure VM については、Bitlocker 暗号化キー (BEK) のみで暗号化された VM、およびキー暗号化キー (KEK) で暗号化された BEK がサポートされています。Backup of VMs encrypted with Bitlocker Encryption Key(BEK) only, and BEK together with Key Encryption Key(KEK) is supported, for managed and unmanaged Azure VMs.
  • 認証されたユーザーによってキー コンテナーに復元される場合のみ読み取りと使用が可能となるように、BEK (シークレット) と KEK (キー) バックアップがバックアップされます。The BEK(secrets) and KEK(keys) backed up are encrypted so they can be read and used only when restored back to key vault by the authorized users.
  • BEK もバックアップされるため、BEK が失われた場合、認証されたユーザーは BEK を KeyVault に復元し、暗号化された VM を回復できます。Since the BEK is also backed up, in scenarios where BEK is lost, authorized users can restore the BEK to the KeyVault and recover the encrypted VM. 暗号化された VM のキーとシークレットは、暗号化形式でバックアップされるため、認証されていないユーザーや Azure はいずれもバックアップされたキーやシークレットを読み取ったり使用したりすることはできません。Keys and secrets of encrypted VMs are backed up in encrypted form, so neither unauthorized users nor Azure can read or use backed up keys and secrets. 正しいレベルの権限を持つユーザーのみが暗号化された VM、およびキーとシークレットをバックアップして復元できます。Only users with the right level of permissions can back up and restore encrypted VMs, as well as keys and secrets.

スナップショットの整合性Snapshot consistency

アプリの実行中にスナップショットを作成するために、Azure Backup ではアプリ整合性スナップショットを作成します。To take snapshots while apps are running, Azure Backup takes app-consistent snapshots.

  • Windows VM:Windows VM については、Backup サービスはボリューム シャドウ コピー サービス (VSS) と連携して VM のディスクの一貫したスナップショットを取得します。Windows VMs: For Windows VMs, the Backup service coordinates with the Volume Shadow Copy Service (VSS) to get a consistent snapshot of the VM disks.
    • 既定では、Azure Backup は完全 VSS バックアップを取得します。By default, Azure Backup takes full VSS backups. 詳細情報Learn more.
    • Azure Backup が VSS コピー バックアップを作成するように設定を変更する場合は、以下のレジストリ キーを設定してください。If you want to change the setting so that Azure Backups takes VSS copy backups, set the following registry key: [HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\BCDRAGENT] ""USEVSSCOPYBACKUP"="TRUE"
  • Linux VM:Azure Backup がスナップショットを作成する場合に Linux VM にアプリケーション整合性を持たせるには、Linux 事前/事後スクリプト フレームワークを使用します。Linux VMs: To ensure that your Linux VMs are app-consistent when Azure Backup takes a snapshot, you can use the Linux pre-script and post-script framework. VM スナップショットを取るときの整合性を確保できるよう自分のカスタム スクリプトを記述することができます。You can write your own custom scripts to ensure consistency when taking a VM snapshot.
    • Azure Backup は、ユーザーが書き込んだ事前スクリプトと事後スクリプトだけを呼び出します。Azure Backup only invokes the pre- and post-scripts written by you.
    • 事前スクリプトと事後スクリプトが正常に実行されると、Azure Backup は復旧ポイントをアプリケーション整合性としてマークします。If the pre-script and post-scripts execute successfully, Azure Backup marks the recovery point as application-consistent. ただし、カスタム スクリプトを使用したときのアプリケーション整合性の最終的な責任はユーザーが担います。However, you're ultimately responsible for the application consistency when using custom scripts.
    • スクリプトの構成の詳細を確認します。Learn more about configuring scripts.

整合性の種類Consistency types

次の表で、整合性の種類について説明します。The following table explains different types of consistency.

スナップショットSnapshot VSS ベースVSS-based 詳細Details 復旧Recovery
アプリケーションの整合性Application-consistent あり (Windows のみ)Yes (Windows only) アプリ整合性バックアップでは、メモリの内容と保留中の I/O 操作がキャプチャされます。App-consistent backups capture memory content and pending I/O operations. アプリ整合性スナップショットでは、バックアップが発生する前にアプリ データの整合性を保証する VSS ライター (または Linux の事前/事後スクリプト) を使用します。App-consistent snapshots use VSS writer (or pre/post script for Linux) that ensure the consistency of app data before a backup occurs. アプリ整合性スナップショットで復旧する場合、VM が起動します。When recovering with an app-consistent snapshot, the VM boots up. データの損失や破損はありません。There's no data corruption or loss. アプリは整合性が確保された状態で開始します。The apps start in a consistent state.
ファイル システム整合性File system consistent あり (Windows のみ)Yes (Windows only) ファイル整合性バックアップでは、同時にすべてのファイルのスナップショットを作成することでディスク ファイルの整合性バックアップを提供します。File consistent backups provide consistent backups of disk files by taking a snapshot of all files at the same time.

Azure Backup の復旧ポイントは次についてのファイル整合性です。Azure Backup recovery points are file consistent for:

- 事前/事後スクリプトのない、または失敗したスクリプのある Linux VM のバックアップ。-Linux VMs backups that don't have pre/post scripts, or that have script that failed.

- VSS が失敗した Windows VM のバックアップ。- Windows VM backups where VSS failed.
ファイル整合性スナップショットによる復旧では、VM が起動します。When recovering with a file-consistent snapshot, the VM boots up. データの損失や破損はありません。There's no data corruption or loss. 復元されたデータに一貫性が保たれるようにするために、アプリは独自の "修正" メカニズムを実装する必要があります。Apps need to implement their own "fix-up" mechanism to make sure that restored data is consistent.
クラッシュ整合性Crash-consistent いいえ No クラッシュ整合性は多くの場合、バックアップ時に Azure VM がシャットダウンされるときに発生します。Crash consistency often happens when an Azure VM shuts down at the time of backup. バックアップ時にディスクに既に存在していたデータのみが、キャプチャされバックアップされます。Only the data that already exists on the disk at the time of backup is captured and backed up.

クラッシュ整合性の復旧ポイントは、オペレーティング システムやアプリのデータ整合性を保証しません。A crash-consistent recovery point doesn't guarantee data consistency for the operating system or the app.
保証はありませんが、通常、VM が起動します。その後、ディスク検査が実行されて、破損エラーが修正されます。There are no guarantees, but usually the VM boots, and follows with a disk check to fix corruption errors. メモリ内にあったデータやディスクに転送されなかった書き込みは、すべて失われます。Any in-memory data or write that weren't transferred to disk are lost. アプリは独自のデータ検証を実装しています。Apps implement their own data verification. たとえば、データベース アプリの場合、トランザクション ログにデータベース内に存在しないエントリが含まれている場合、データベース ソフトウェアはデータの整合性が得られるまでロールします。For example, for a database app, if a transaction log has entries that aren't in the database, the database software rolls until data is consistent.

サービスとサブスクリプションの制限Service and subscription limits

Azure Backup にはサブスクリプションとコンテナーについてさまざまな制限があります。Azure Backup has a number of limits around subscriptions and vaults.

次の制限は、Azure Backup に適用されます。The following limits apply to Azure Backup.

制限Limit 既定値Default
コンテナーに登録できるサーバー/マシンServers/machines that can be registered in a vault Windows Server/Windows クライアント/System Center DPM: 50Windows Server/Windows Client/System Center DPM: 50

IaaS VM: 1,000IaaS VMs: 1000
コンテナー ストレージ内のデータ ソースのサイズSize of a data source in vault storage 最大 54,400 GB。54400 GB maximum. この制限は、IaaS VM のバックアップには適用されませんThe limit doesn't apply to IaaS VM backup
Azure サブスクリプションのバックアップ コンテナーBackup vaults in an Azure subscription 500 コンテナー (リージョンあたり)500 vaults per region
毎日のバックアップのスケジュールSchedule daily backups Windows Server/クライアント: 3 回 (1 日あたり)Windows Server/Client: 3 a day
System Center DPM: 2 回 (1 日あたり)System Center DPM: 2 a day
IaaS VM: 1 回 (1 日あたり)IaaS VMs: Once a day
Azure VM にアタッチするバックアップ用データ ディスクData disks attached to an Azure VM for backup 3232
Azure VM にアタッチする個々のバックアップ用データ ディスクIndividual data disk attached to Azure VM for backup 4095 GB4095 GB

バックアップ パフォーマンスBackup performance

ディスクに関する考慮事項Disk considerations

バックアップ操作は、VM の各ディスクを並行してバックアップすることで最適化されます。Backup operation optimizes by backing up each of the VM’s disk in parallel. たとえば、VM にディスクが 4 つある場合、サービスは 4 つすべてのディスクを並列でバックアップしようとします。For example, if a VM has four disks, the service attempts to back up all four disks in parallel. バックアップ対象の各ディスクは、Azure Backup がディスク上のブロックを読み込み、変更されたデータのみを格納します (増分バックアップ)。For each disk being backed up, Azure Backup reads the blocks on the disk and stores only the changed data (incremental backup).

スケジュールに関する考慮事項Scheduling considerations

スケジュールのバックアップは、パフォーマンスに影響します。Backup scheduling impacts performance.

  • すべての VM が同時にバックアップされるようにポリシーを構成した場合、バックアップ プロセスはすべてのディスクを並行にバックアップしようとするため、トラフィックが輻輳します。If you configure policies so all VMs are backed up at the same time, you have scheduled a traffic jam, as the backup process attempts to back up all disks in parallel.
  • バックアップ トラフィックを減らすには、重複がないよう、異なる VM を一日の異なる時間にバックアップします。To reduce the backup traffic, back up different VMs at different time of the day, with no overlap.

時間に関する考慮事項Time considerations

バックアップ時間のほとんどはデータの読み取りとコピーに費やされますが、VM のバックアップには、他にも必要な合計時間が増える操作があります。While most backup time is spent reading and copying data, other operations add to the total time needed to back up a VM:

  • バックアップ拡張機能のインストール:バックアップ拡張機能のインストールまたは更新の所要時間。Install backup extension: Time needed to install or update the backup extension.
  • スナップショットのトリガー:スナップショットをトリガーするのにかかった時間です。Trigger snapshot: Time taken to trigger a snapshot. スナップショットは、スケジュールされたバックアップ時刻の近くでトリガーされます。Snapshots are triggered close to the scheduled backup time.
  • キューの待機時間:バックアップ サービスにより複数の顧客ストレージ アカウントからのジョブが同時に処理されるため、スナップショットは Recovery Services コンテナーにすぐにコピーされないことがあります。Queue wait time: Since the Backup service processes jobs from multiple customer storage accounts at the same time, snapshot data may not immediately be copied to the Recovery Services vault. 負荷のピーク時には、バックアップが処理されるまでに最大 8 時間がかかることがあります。At peak load times, it can take up to eight hours before the backups are processed. ただし、毎日のバックアップ ポリシーでは、VM バックアップの合計時間は 24 時間未満になります。However, the total VM backup time is less than 24 hours for daily backup policies.
  • 初回バックアップ:増分バックアップには 24 時間未満の合計バックアップ時間が有効ですが、初回バックアップには有効ではないことがあります。Initial backup: Although the total backup time of less than 24 hours is valid for incremental backups, it might not be for the first backup. 必要な時間はデータのサイズとバックアップが取得された時間に応じて異なります。Time needed will depend on size of the data and when the backup is taken.
  • データ転送時間:バックアップ サービスが前回のバックアップからの増分変更を計算し、これらの変更をコンテナー ストレージに転送するために必要な時間です。Data transfer time: Time needed for backup service to compute the incremental changes from previous backup and transfer those changes to vault storage.

バックアップ時間に影響する要因Factors affecting backup time

バックアップは、スナップショットの作成と、コンテナーへのスナップショットの転送という、2 つのフェーズで構成されています。Backup consists of two phases, taking snapshots and transferring the snapshots to the vault. Backup サービスはストレージ用に最適化されます。The Backup service optimizes for storage.

  • スナップショット データをコンテナーに転送するとき、サービスは前のスナップショットからの増分変更のみを転送します。When transferring the snapshot data to a vault, the service only transfers incremental changes from the previous snapshot.
  • 増分変更を特定するため、サービスはブロックのチェックサムを計算します。To determine the incremental changes, the service computes the checksum of the blocks.
    • 変更されたブロックは、コンテナーに送信されるブロックとして識別されます。If a block is changed, the block is identified as a block to be sent to the vault.
    • サービスは識別された各ブロックをさらに詳しく調べて、転送するデータを最小化する可能性を探ります。The service drills further into each of the identified blocks, looking for opportunities to minimize the data to transfer.
    • 変更されたブロックをすべて評価した後、サービスは変更箇所を結合して、コンテナーに送ります。After evaluating all changed blocks, the service coalesces the changes and sends them to the vault.

バックアップ時間に影響を与える状況には次のようなものがあります。Situations that can affect backup time include the following:

  • 既に保護されている VM に新しく追加されたディスクの初回のバックアップ:VM が増分バックアップの最中である場合、その VM に新しいディスクが追加されると、既存のディスクのデルタ レプリケーションと共に、新しく追加されたディスクの初期レプリケーションも必要になるため、バックアップの所要時間が 24 時間を超える可能性があります。Initial backup for a newly added disk to an already protected VM: If a VM is undergoing incremental backup and a new disk gets added to this VM, then the backup duration can go beyond 24 hours since the newly added disk has to undergo initial replication along with delta replication of existing disks.
  • 断片化:バックアップ製品では、2 つのバックアップ操作間の差分変更がスキャンされます。Fragmentation: Backup product scans for incremental changes between two backups operations. バックアップ操作は、それぞれの変更が併置されている場合のほうが、ディスク上で分散している場合よりも高速に実行されます。Backup operations are faster when the changes on the disk are collocated when compared to changes are spread across then the disk.
  • チャーン:(増分レプリケーションの) ディスクあたりの日次チャーンが 200 GB を超える場合は、操作の完了までに 8 時間以上かかる可能性があります。Churn: Daily churn (for incremental replication) per disk greater than 200 GB can take greater than ~8 hours to complete the operation. VM にディスクが 2 つ以上ある場合、いずれかのディスクでバックアップの時間が長引くと、全体のバックアップ操作に影響が及ぶ可能性があります (またはエラーが発生する可能性があります)。If VM has more than one disk and if one of those disks is taking longer time to backup, then it can impact the overall backup operation (or can result in failure).
  • チェックサム比較 (CC) モード:CC モードでは、インスタント RP で使用される最適化モードと比べて処理が遅くなります。Checksum Comparison (CC) mode: CC mode is comparatively slower than optimized mode used by Instant RP. インスタント RP を既に使用している場合で、Tier-1 のスナップショットを削除した場合は、バックアップが CC モードに切り替わり、バックアップ操作が 24 時間を超える (または失敗する) 結果につながります。If you are already using Instant RP and have deleted the Tier-1 snapshots, then backup switches to CC mode causing the Backup operation to exceed 24 hours (or fail).

復元に関する考慮事項Restore considerations

復元操作は 2 つのメイン タスクで構成されています。選択したストレージ アカウントにコンテナーからデータをコピーすることと仮想マシンを作成することです。A restore operation consists of two main tasks: copying data back from the vault to the chosen storage account, and creating the virtual machine. コンテナーからデータをコピーするために必要な時間は、Azure でバックアップが保存されている場所とストレージ アカウントの場所によって決まります。The time needed to copy data from the vault depends on where the backups are stored in Azure, and the storage account location. データのコピーに使用される時間は、次に依存します。Time taken to copy data depends upon:

  • キューの待機時間:サービスは複数のストレージ アカウントからの復元ジョブを同時に処理するため、復元要求はキューに入れられます。Queue wait time: Since the service processes restore jobs from multiple storage accounts at the same time, restore requests are put in a queue.
  • データ コピー時間:データがコンテナーからストレージ アカウントにコピーされます。Data copy time: Data is copied from the vault to the storage account. 復元時間は、Azure Backup サービスが使用する、選択したストレージ アカウントの IOPS とスループットに依存します。Restore time depends on IOPS and throughput of the selected storage account, which the Azure Backup service uses. 復元処理中のコピー時間を短縮するには、他のアプリケーションの書き込みと読み取りが読み込まれないストレージ アカウントを選びます。To reduce the copying time during the restore process, select a storage account not loaded with other application writes and reads.

ベスト プラクティスBest practices

VM バックアップを構成するときには、次のプラクティスに従うことをお勧めします。We suggest following these practices while configuring VM backups:

  • コンテナーをインスタント RP にアップグレードします。Upgrade vaults to Instant RP. これらの利点考慮事項を確認し、こちらの指示に従ってアップグレードに進んでください。Review these benefits, considerations, and then proceed to upgrade by following these instructions.
  • リソースの使用を最適化するためにデータのスナップショットが取得される場合は、既定で指定されたポリシー時刻を変更することを検討してください (たとえば、Consider modifying the default provided policy time (for ex. 既定のポリシー時刻が午前 12 時 00 分である場合は、それを数分先に進めることを検討してください)。If your default policy time is 12:00AM consider incrementing it by minutes) when the data snapshots are taken to ensure resources are optimally used.
  • インスタント RP 機能を使用しない場合、Premium VM のバックアップには、ストレージ アカウントの総容量の約 50% を割り当ててください。For Premium VM backup on non-Instant RP feature allocates ~50% of the total storage account space. バックアップ サービスでは、スナップショットを同じストレージ アカウントにコピーし、それをコンテナーに転送するために、この容量が必要になります。Backup service requires this space to copy the snapshot to same storage account and for transferring it to the vault.
  • 1 つのコンテナーから複数の VM を復元する場合は、ターゲットのストレージ アカウントがスロットルされないようにするために、それぞれ異なる v2 ストレージ アカウント を使用することを強くお勧めします。For restoring VMs from a single vault, it is highly recommended to use different v2 storage accounts to ensure the target storage account doesn’t get throttled. たとえば、各 VM にはそれぞれ異なるストレージ アカウントを使用する必要があります (10 個の VM を復元する場合は、異なる 10 個のストレージ アカウントを使用することを検討してください)。For example, each VM must have different storage account (If 10 VMs are restored, then consider using 10 different storage accounts).
  • Tier-1 ストレージ レイヤー (スナップショット) からの復元は (ストレージ アカウントが同じなので) 数分で完了しますが、Tier-2 ストレージ レイヤー (コンテナー) の場合は数時間かかる可能性があります。The restores from Tier-1 storage layer (snapshot) will be completed in minutes (since it is the same storage account) against the Tier-2 storage layer (vault) which can take hours. 利用可能なデータが Tier-1 にある場合は、復元を高速化するために、インスタント RP 機能を使用することをお勧めします (データをコンテナーから復元しなければならない場合は、処理時間が長くなります)。We recommend you to use Instant RP feature for faster restores for case where data is available in Tier-1 (if the data has to be restored from vault then it will take time).
  • ストレージ アカウントあたりのディスク数の制限は、IaaS VM で実行されているアプリケーションがディスクにどれくらいアクセスするかによって決まります。The limit on number of disks per storage account is relative to how heavy the disks are being accessed by applications running on IaaS VM. 1 つのストレージ アカウントで複数のディスクがホストされているかどうかを確認してください。Verify if multiple disks are hosted on a single storage account. 通常、1 つのストレージ アカウント上に 5 ~ 10 個以上のディスクが存在する場合は、一部のディスクを別のストレージ アカウントに移動して負荷を分散します。As a general practice, if 5 to 10 disks or more are present on single storage account, balance the load by moving some disks to separate storage accounts.

バックアップのコストBackup costs

Azure Backup を使用してバックアップされている Azure VM は、Azure Backup の価格の対象になります。Azure VMs backed up with Azure Backup are subject to Azure Backup pricing.

  • 課金は、最初のバックアップが正常に完了するまでは開始されません。Billing does not start until the first successful backup completes. この時点では、ストレージと保護するインスタンスの両方に対する課金が開始されます。At this point, the billing for both Storage and Protected Instances begins.
  • 仮想マシンのコンテナー内に格納されたバックアップ データが存在する限り、課金は継続されます。Billing continues as long as there is any backup data stored in a vault for the virtual machine. 仮想マシンの保護を停止しても、仮想マシンのバックアップ データがコンテナーに存在していると、課金は継続します。If you stop protection on the virtual machine, but virtual machine backup data exists in a vault, billing continues.
  • 指定された VM に対する課金は、保護が停止され、かつすべてのバックアップ データが削除されている場合にのみ停止します。Billing for a specified VM stops only if the protection is stopped and all backup data is deleted.
  • 保護が停止してアクティブなバックアップ ジョブがないとき、最後に成功した VM バックアップのサイズは、毎月の課金に使用する保護インスタンスのサイズになります。When protection stops and there are no active backup jobs, the size of the last successful VM backup becomes the Protected Instance size used for the monthly bill.
  • 保護されたインスタンスの計算は、仮想マシンの実際のサイズ (一時ストレージを除く、仮想マシン内のすべてのデータの合計) に基づきます。The Protected Instances calculation is based on the actual size of the virtual machine, which is the sum of all the data in the virtual machine, excluding the temporary storage.
  • 価格は、データ ディスクに格納された実際のデータに基づきます。Pricing is based on the actual data stored in the data disk.
  • VM をバックアップするための価格は、仮想マシンに接続されたデータ ディスクごとのサポートされる最大サイズには基づきません。Pricing for backing up VMs is not based on the maximum supported size for each data disk attached to the virtual machine.
  • 同様に、バックアップ ストレージの課金は、Azure Backup に格納されているデータ量 (各回復ポイントの実際のデータの合計) に基づきます。Similarly, the backup storage bill is based on the amount of data that is stored in Azure Backup, which is the sum of the actual data in each recovery point.

たとえば、最大サイズが各 4 TB のデータ ディスクが 2 台追加で搭載されている A2 標準サイズの仮想マシンがあります。For example, take an A2 Standard-sized virtual machine that has two additional data disks with a maximum size of 4 TB each. 次の表は、これらの各ディスクに格納されている実際のデータです。The following table gives the actual data stored on each of these disks:

ディスクの種類Disk type 最大サイズMax size 実際のデータ量Actual data present
オペレーティング システム ディスクOperating system disk 4095 GB4095 GB 17 GB17 GB
ローカル ディスク/一時ディスクLocal disk / Temporary disk 135 GB135 GB 5 GB (バックアップに含まれない)5 GB (not included for backup)
データ ディスク 1Data disk 1 4095 GB4095 GB 30 GB30 GB
データ ディスク 2Data disk 2 4095 GB4095 GB 0 GB0 GB
  • この場合の VM 仮想マシンの実際のサイズは、17 GB + 30 GB + 0 GB = 47 GB です。The actual size of the VM virtual machine in this case is 17 GB + 30 GB + 0 GB = 47 GB.
  • この保護するインスタンスのサイズ (47 GB) が、毎月の課金の基礎になります。This Protected Instance size (47 GB) becomes the basis for the monthly bill.
  • 仮想マシンのデータ量が大きくなると、課金に使用される保護インスタンスのサイズもそれに応じて変化します。As the amount of data in the virtual machine grows, the Protected Instance size used for billing changes accordingly.

次の手順Next steps

バックアップ プロセスとパフォーマンスに関する考慮事項を確認した後、以下を実施してください。After reviewing the backup process and performance considerations, do the following:

  • Azure ストレージの最適化パフォーマンスのためのアプリの調整についての詳細を確認する。Learn about tuning apps for optimal performance with Azure storage. この記事ではプレミアム ストレージが使われていますが、標準ストレージのディスクにも当てはまります。The article focus on premium storage, but is also applicable for standard storage disks.
  • VM のサポートと制限、コンテナーの作成、および VM のバックアップの準備を確認することで、バックアップを開始する。Get started with backup by reviewing VM support and limitations, creating a vault, and getting VMs ready for backup.