Azure における VM バックアップ インフラストラクチャの計画を立てるPlan your VM backup infrastructure in Azure

この記事では、パフォーマンスとリソースに関する提案を行い、VM のバックアップ インフラストラクチャを計画するお手伝いをします。This article provides performance and resource suggestions to help you plan your VM backup infrastructure. さらに、Backup サービスの主要な側面を定義します。これらの側面は、アーキテクチャの決定、容量計画、スケジューリングの際の重要な要素になることがあります。It also defines key aspects of the Backup service; these aspects can be critical in determining your architecture, capacity planning, and scheduling. 必要な環境の準備が済んだら、VM のバックアップを開始する前に行う次の手順は計画の作成です。If you've prepared your environment, planning is the next step before you begin to back up VMs. Azure 仮想マシンについて詳しい情報が必要な場合は、「Virtual Machines のドキュメント」を参照してください。If you need more information about Azure virtual machines, see the Virtual Machines documentation.

Azure における仮想マシン バックアップの動作How does Azure back up virtual machines?

Azure Backup サービスは、スケジュールされた時刻にバックアップ ジョブを開始し、バックアップ拡張機能をトリガーして特定時点のスナップショットを作成します。When the Azure Backup service initiates a backup job at the scheduled time, it triggers the backup extension to take a point-in-time snapshot. Azure Backup サービスは、Windows の_VMSnapshot_ 拡張機能、および Linux の VMSnapshotLinux 拡張機能を使用します。The Azure Backup service uses the VMSnapshot extension in Windows, and the VMSnapshotLinux extension in Linux. 拡張機能は、最初の 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).

Windows VM のスナップショットを取るとき、Backup サービスは Volume Shadow Copy Service (VSS) と連携して仮想マシンのディスクの一貫したスナップショットを取得します。When taking a snapshot of Windows VMs, the Backup service coordinates with the Volume Shadow Copy Service (VSS) to get a consistent snapshot of the virtual machine's disks. Linux VM をバックアップしている場合、VM スナップショットを取るときの整合性を確保できるよう自分のカスタム スクリプトを記述することができます。If you're backing up Linux VMs, you can write your own custom scripts to ensure consistency when taking a VM snapshot. これらのスクリプトを呼び出すための詳細については、この記事の後半で説明します。Details on invoking these scripts are provided later in this article.

Azure Backup サービスがスナップショットを取ると、データはバックアップコンテナーに転送されます。Once the Azure Backup service takes the snapshot, 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.

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

データ転送が完了すると、スナップショットが削除され、回復ポイントが作成されます。When the data transfer is complete, the snapshot is removed and a recovery point is created.


  1. バックアップ プロセス中、Azure Backup には仮想マシンに接続された一時ディスクは含まれません。During the backup process, Azure Backup doesn't include the temporary disk attached to the virtual machine. 詳細については、ブログの一時記憶域をご覧ください。For more information, see the blog on temporary storage.
  2. Azure Backup はストレージ レベルのスナップショットを取得してそのスナップショットをバックアップコンテナーに転送するため、バックアップ ジョブが終了するまでストレージ アカウント キーを変更しないでください。Since Azure Backup takes a storage-level snapshot and transfers that snapshot to vault, do not change the storage account keys until the backup job finishes.
  3. プレミアム VM の場合、ストレージ アカウントにスナップショットをコピーします。For premium VMs, we copy the snapshot to storage account. これは、Azure Backup サービスにデータをコンテナーに転送するために必要十分な IOPS を与えるための措置です。This is to make sure that Azure Backup service gets sufficient IOPS for transferring data to vault. ストレージをこの方法で付加的にコピーするとき、VM の割り当てサイズに基づいて課金されます。This additional copy of storage is charged as per the VM allocated size.

データの一貫性Data consistency

業務に不可欠なデータのバックアップと復元は、その生成元となるアプリケーションの実行中にバックアップを行う必要があるため簡単ではありません。Backing up and restoring business critical data is complicated by the fact that business critical data must be backed up while the applications that produce the data are running. これに対処するために、Azure Backup では、Windows VM と Linux VM のアプリケーション整合性バックアップをサポートしています。To address this, Azure Backup supports application-consistent backups for both Windows and Linux VMs

Windows VMWindows VM

Azure Backup は、Windows VM 上で VSS 完全バックアップを行います ( VSS 完全バックアップの詳細をご覧ください)。Azure Backup takes VSS full backups on Windows VMs (read more about VSS full backup). VSS コピー バックアップを有効にするには、VM に以下のレジストリ キーを設定する必要があります。To enable VSS copy backups, the following registry key needs to be set on the VM.


Linux VMLinux VMs

Azure Backup はスクリプトのフレームワークを提供します。Azure Backup provides a scripting framework. Linux VM をバックアップしているときのアプリケーション整合性を確保するには、バックアップのワークフローと環境を制御する、カスタムの事前スクリプトと事後スクリプトを作成します。To ensure application consistency when backing up Linux VMs, create custom pre-scripts and post-scripts that control the backup workflow and environment. Azure Backup は、VM スナップショットを取る前に事前スクリプトを呼び出し、VM スナップショット ジョブが完了したら事後スクリプトを呼び出します。Azure Backup invokes the pre-script before taking the VM snapshot and invokes the post-script once the VM snapshot job completes. 詳細については、事前スクリプトと事後スクリプトを使用した VM のアプリケーション整合性バックアップをご覧ください。For more details, see application consistent VM backups using pre-script and post-script.


Azure Backup は、ユーザーが書き込んだ事前スクリプトと事後スクリプトだけを呼び出します。Azure Backup only invokes the customer-written pre- and post-scripts. 事前スクリプトと事後スクリプトが正常に実行されると、Azure Backup は復旧ポイントをアプリケーション整合性としてマークします。If the pre-script and post-scripts execute successfully, Azure Backup marks the recovery point as application consistent. ただし、カスタム スクリプトを使用したときのアプリケーション整合性の最終的な責任はユーザーが担います。However, the customer is ultimately responsible for the application consistency when using custom scripts.

この表は、整合性の種類を一覧にしたものです。Azure VM のバックアップと復元で確保される状態をそれぞれ説明しています。This table explains the types of consistency and the conditions that they occur under during Azure VM backup and restore procedures.

整合性Consistency VSS ベースVSS-based 説明と詳細Explanation and details
アプリケーション整合性Application consistency あり - Windows の場合Yes for Windows アプリケーション整合性は、以下を保証するのでワークロードに最適です。Application consistency is ideal for workloads as it ensures that:
  1. "VM が起動します"。The VM boots up.
  2. "破損がない"。There is no corruption.
  3. "データの損失がない"。There is no data loss.
  4. バックアップの時点で VSS または事前/事後スクリプトを使用してアプリケーションを関連付けるので、データとそのデータを使用するアプリケーションとの間で整合性が保たれる。The data is consistent to the application that uses the data, by involving the application at the time of backup--using VSS or pre/post script.
  • Windows VM - ほとんどの Microsoft ワークロードには、データ整合性に関連するワークロード固有のアクションを実行する VSS ライターがあります。Windows VMs- Most Microsoft workloads have VSS writers that do workload-specific actions related to data consistency. たとえば、Microsoft SQL Server には、トランザクション ログ ファイルとデータベースへの書き込みが正常に行われることを保証する VSS ライターがあります。For example, Microsoft SQL Server has a VSS writer that ensures that the writes to the transaction log file and the database are done correctly. Azure Windows VM のバックアップの場合、アプリケーション整合性復旧ポイントを作成するには、VM スナップショットを作成する前に、バックアップ拡張機能が VSS ワークフローを呼び出し、ワークフローを完了する必要があります。For Azure Windows VM backups, to create an application-consistent recovery point, the backup extension must invoke the VSS workflow and complete it before taking the VM snapshot. Azure VM のスナップショットが正確であるためには、すべての Azure VM アプリケーションの VSS ライターも完了する必要があります。For the Azure VM snapshot to be accurate, the VSS writers of all Azure VM applications must complete as well. (VSS の基本と詳しいしくみを確認してください)。(Learn the basics of VSS and dive deep into the details of how it works).
  • Linux VM - ユーザーがカスタムの事前スクリプトと事後スクリプトを実行してアプリケーション整合性を確保できます。Linux VMs- Customers can execute custom pre-script and post-script to ensure application consistency.
  • ファイル システム整合性File-system consistency あり - Windows ベースのコンピューターの場合Yes - for Windows-based computers 復旧ポイントでファイルシステム整合性が保たれるシナリオとしては、次の 2 つがあります。There are two scenarios where the recovery point can be file-system consistent:
    • Azure の Linux VM のバックアップ (事前スクリプト/事後スクリプトがない場合または事前スクリプト/事後スクリプトが失敗した場合)。Backups of Linux VMs in Azure, without pre-script/post-script or if pre-script/post-script failed.
    • Azure 内の Windows VM のバックアップ中の VSS の障害。VSS failure during backup for Windows VMs in Azure.
    どちらの場合でも、次のことを確保することが重要です。In both these cases, the best that can be done is to ensure that:
    1. "VM が起動します"。The VM boots up.
    2. "破損がない"。There is no corruption.
    3. "データの損失がない"。There is no data loss.
    アプリケーションでは、復元されたデータに対する独自の "修正" メカニズムを実装する必要があります。Applications need to implement their own "fix-up" mechanism on the restored data.
    クラッシュ整合性Crash consistency いいえ No この状況は、(ソフト リセットまたはハード リセットにより) 仮想マシンが "クラッシュ" した状況に相当します。This situation is equivalent to a virtual machine experiencing a "crash" (through either a soft or hard reset). クラッシュ整合性は通常、バックアップ時に Azure 仮想マシンがシャットダウンされるときに発生します。Crash consistency typically happens when the Azure virtual machine is shut down at the time of backup. クラッシュ整合性の復旧ポイントは、オペレーティング システムの観点からもアプリケーションの観点からも、ストレージ メディア上のデータの整合性に関して何も保証しません。A crash-consistent recovery point provides no guarantees around the consistency of the data on the storage medium--either from the perspective of the operating system or the application. バックアップ時にディスクに既に存在していたデータのみが、キャプチャされバックアップされます。Only the data that already exists on the disk at the time of backup is captured and backed up.

    保証はありませんが、通常、OS は起動します。その後、chkdsk などのディスク検査手順が実行されて、破損エラーがあれば修正されます。While there are no guarantees, usually, the operating system boots, followed by disk-checking procedure, like chkdsk, to fix any corruption errors. メモリ内にあったデータや、ディスクに転送されていなかった書き込みは、すべて失われます。Any in-memory data or writes that have not been transferred to the disk are lost. 通常、アプリケーションは、データのロールバックを実行する必要がある場合に独自の検証メカニズムに従います。The application typically follows with its own verification mechanism in case data rollback needs to be done.

    たとえば、データベースに存在しないエントリがトランザクション ログにある場合、データベース ソフトウェアは、データの整合性が得られる時点までロールバックします。As an example, if the transaction log has entries that are not present in the database, then the database software does a rollback until the data is consistent. (スパン ボリュームのように) データが複数の仮想ディスクにまたがる場合、クラッシュ整合性の復旧ポイントは、データの正確性に関して何も保証しません。When data is spread across multiple virtual disks (like spanned volumes), a crash-consistent recovery point provides no guarantees for the correctness of the data.

    パフォーマンスおよびリソース使用率Performance and resource utilization

    Azure で VM をバックアップする場合、オンプレミスにデプロイされるバックアップ ソフトウェアと同様に、必要な容量とリソースの使用率を考慮する必要があります。Like backup software that is deployed on-premises, you should plan for capacity and resource utilization needs when backing up VMs in Azure. Azure Storage の制限 には、実行中のワークロードに対する影響を最小に抑え、パフォーマンスを最大にする VM のデプロイメントの構成が定義されています。The Azure Storage limits define how to structure VM deployments to get maximum performance with minimum impact to running workloads.

    バックアップのパフォーマンスを計画する際は、Azure Storage の次の制限に注意してください。Pay attention to the following Azure Storage limits when planning backup performance:

    • ストレージ アカウントあたりの最大送信速度Max egress per storage account
    • ストレージ アカウントあたりの合計要求レートTotal request rate per storage account

    ストレージ アカウントの制限Storage account limits

    バックアップ データがストレージ アカウントからコピーされ、ストレージ アカウントの 1 秒あたりの入力/出力操作数 (IOPS) および送信速度 (またはスループット) メトリックに追加されます。Backup data copied from a storage account, adds to the input/output operations per second (IOPS) and egress (or throughput) metrics of the storage account. このとき同時に、仮想マシンも IOPS とスループットを消費しています。At the same time, virtual machines are also consuming IOPS and throughput. この目的は、バックアップおよび仮想マシンのトラフィックが、ストレージ アカウントの制限を超過しないようにすることです。The goal is to ensure Backup and virtual machine traffic don't exceed your storage account limits.

    ディスクの数Number of disks

    バックアップ プロセスは、バックアップのジョブを可能な限り早く完了しようとします。The backup process tries to complete a backup job as quickly as possible. そのため、バックアップ プロセスは可能な限り多くのリソースを使用します。In doing so, it consumes as many resources as it can. ただし、すべての I/O 操作には 1 秒あたり 60 MB の 「単一 BLOB のターゲット スループット」の制限があります。However, all I/O operations are limited by the Target Throughput for Single Blob, which has a limit of 60 MB per second. 速度を最大にするため、バックアップ プロセスは各 VM のディスクを 「並列」でバックアップしようとします。In an attempt to maximize its speed, the backup process tries to back up each of the VM's disks in parallel. VM にディスクが 4 つある場合、サービスは 4 つすべてのディスクを並列でバックアップしようとします。If a VM has four disks, the service attempts to back up all four disks in parallel. バックアップしているディスクの数は、ストレージ アカウント バックアップ トラフィックを決定する際に最も重要な要因です。The number of disks being backed up, is the most important factor in determining storage account backup traffic.

    バックアップ スケジュールBackup schedule

    パフォーマンスに影響を与えるもう 1 つの要因は、 バックアップ スケジュールです。An additional factor that impacts performance is the backup schedule. すべての VM が同時にバックアップされるようなポリシーを構成すると、トラフィックが輻輳します。If you configure the policies so all VMs are backed up at the same time, you have scheduled a traffic jam. バックアップ プロセスはすべてのディスクを並列でバックアップしようとします。The backup process attempts to back up all disks in parallel. ストレージ アカウントからのバックアップ トラフィックを減らすには、それぞれの VM を 1 日の異なる時間帯に、重複せずにバックアップされるようにします。To reduce the backup traffic from a storage account, back up different VMs at different time of the day, with no overlap.

    容量計画Capacity planning

    以上の要素を総合して、ストレージ アカウントの使用ニーズを計画する必要があります。Putting the previous factors together, you need to plan for the storage account usage needs. ディスクに対する影響およびバックアップ スケジュールの選択肢を確認するには、 VM のバックアップ容量計画に関する Excel スプレッドシート をダウンロードしてください。Download the VM backup capacity planning Excel spreadsheet to see the impact of your disk and backup schedule choices.

    バックアップのスループットBackup throughput

    バックアップ対象の各ディスクは、Azure Backup がディスク上のブロックを読み込み、変更されたデータのみを格納します (増分バックアップ)。For each disk being backed up, Azure Backup reads the blocks on the disk and stores only the changed data (incremental backup). 次の表では、Backup サービスのスループットの平均値を示します。The following table shows the average Backup service throughput values. 次のデータを使うと、特定のサイズのディスクをバックアップするために必要な時間を見積もることができます。Using the following data, you can estimate the amount of time needed to back up a disk of a given size.

    バックアップ操作Backup operation 最適なスループットBest-case throughput
    初回バックアップInitial backup 160 Mbps160 Mbps
    増分バックアップ (DR)Incremental backup (DR) 640 Mbps 640 Mbps

    変更された (バックアップする必要がある) データがディスク全体に分散している場合、スループットが大幅に低下します。Throughput drops significantly if the changed data (that needs to be backed up) is dispersed across the disk.

    VM のバックアップの合計時間Total VM backup time

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

    • バックアップ拡張機能のインストールまたは更新の所要時間。Time needed to install or update the backup extension.
    • スナップショットの時間。スナップショットをトリガーするのにかかった時間です。Snapshot time, which is the time taken to trigger a snapshot. スナップショットは、スケジュールされたバックアップ時刻の近くでトリガーされます。Snapshots are triggered close to the scheduled backup time.
    • キューの待機時間。Queue wait time. Backup サービスは複数の顧客のバックアップを処理するので、スナップショットから Backup コンテナーまたは Recovery Services コンテナーへのバックアップ データのコピーは直ちには開始されない場合があります。Since the Backup service is processing backups from multiple customers, copying backup data from snapshot to the backup or Recovery Services vault might not start immediately. 負荷のピーク時には、処理するバックアップ数に応じて、待機時間が最大 8 時間まで延長される可能性があります。In times of peak load, the wait can stretch up to eight hours due to the number of backups being processed. ただし、毎日のバックアップ ポリシーでは、VM バックアップの合計時間は 24 時間未満になります。However, the total VM backup time is less than 24 hours for daily backup policies.
    • データ転送時間。バックアップ サービスが前回のバックアップからの増分変更を計算し、これらの変更をコンテナー ストレージに転送するために必要な時間です。Data transfer time, time needed for backup service to compute the incremental changes from previous backup and transfer those changes to vault storage.

    バックアップ時間が長い (12 時間超) 理由Why am I observing longer(>12 hours) 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. その後、サービスは識別された各ブロックをさらに詳しく調べて、転送するデータを最小化する可能性を探ります。Then 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. 一部のレガシ アプリケーションでは、小さい断片化した書き込みはストレージにとって最適ではありません。In some legacy applications, small, fragmented writes are not optimal for storage. スナップショットに小さい断片化した書き込みが多く含まれる場合、サービスはアプリケーションによって書き込まれたデータの処理に余分な時間を費やします。If the snapshot contains many small, fragmented writes, the service spends additional time processing the data written by the applications. VM 内部で実行するアプリケーションについて、Azure が推奨するアプリケーション書き込みブロックの大きさは、8 KB 以上です。The recommended application write block from Azure, for applications running inside the VM, is a minimum of 8 KB. アプリケーションが 8 KB 未満のブロックを使っている場合、バックアップのパフォーマンスに影響があります。If your application uses a block of less than 8 KB, backup performance is effected. バックアップのパフォーマンスが向上するアプリケーションの調整については、Azure Storage でのパフォーマンスが最適になるようなアプリケーションのチューニングをご覧ください。For help with tuning your application to improve backup performance, see Tuning applications for optimal performance with Azure storage. バックアップのパフォーマンスに関する記事では Premium Storage の例が使われていますが、ガイダンスは Standard Storage のディスクにも当てはまります。Though the article on backup performance uses Premium storage examples, the guidance is applicable for Standard storage disks.

    合計復元時間Total restore time

    復元操作は、2 つの主要なサブ タスクで構成されています。コンテナーから選択したユーザーのストレージ アカウントへのデータのコピーと、仮想マシンの作成です。A restore operation consists of two main sub tasks: Copying data back from the vault to the chosen customer storage account, and creating the virtual machine. コンテナーからのデータのコピーは、バックアップが Azure 内部で保存される場所や、ユーザーのストレージ アカウントが保存される場所によって異なります。Copying data back from the vault depends on where the backups are stored internally in Azure, and where the customer storage account is stored. データのコピーに使用される時間は、次に依存します。Time taken to copy data depends upon:

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

    ベスト プラクティスBest practices

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

    • 同じクラウド サービスから同時にバックアップを行うクラシック VM の数が 10 を超えないようにスケジュールしてください。Don't schedule more than 10 classic VMs from the same cloud service to back up at the same time. 同じクラウド サービスから複数の VM をバックアップしたい場合は、バックアップの開始時刻を 1 時間ずつずらしてください。If you want to back up multiple VMs from same cloud service, stagger the backup start times by an hour.
    • VM を同時にバックアップする場合は、数が 40 を超えないようにスケジュールしてください。Do not schedule more than 40 VMs to back up at the same time.
    • VM バックアップを非ピーク時にスケジュールします。Schedule VM backups during non-peak hours. こうすれば、バックアップ サービスは IOPS を、ユーザーのストレージ アカウントからコンテナーへデータを転送するために使用します。This way the Backup service uses IOPS for transferring data from the customer storage account to the vault.
    • ポリシーが、異なるストレージ アカウントに分散されている VM にも適用されることを確認します。Make sure that a policy is applied on VMs spread across different storage accounts. 1 つのストレージ アカウント内で同じバックアップ スケジュールによって保護されるディスクは、20 個以下がお勧めです。We suggest no more than 20 total disks from a single storage account be protected by the same backup schedule. 1 つのストレージ アカウント内に 20 を超えるディスクがある場合は、それらの VM を複数のポリシーに分散させることで、必要な IOPS をバックアップ プロセスの転送フェーズ中に実現できます。If you have greater than 20 disks in a storage account, spread those VMs across multiple policies to get the required IOPS during the transfer phase of the backup process.
    • Premium ストレージで実行されている VM を同じストレージ アカウントに復元しないでください。Do not restore a VM running on Premium storage to same storage account. 復元操作のプロセスがバックアップ操作と重なった場合は、バックアップ用の IOPS が減ります。If the restore operation process coincides with the backup operation, it reduces the available IOPS for backup.
    • Premium VM バックアップでは、バックアップが成功するために、Premium ディスクをホストするストレージ アカウントにスナップショットをステージングするための空き領域が 50% 以上あることを確認してください。For Premium VM backup, ensure that storage account that hosts premium disks has atleast 50% free space for staging snapshot for a successful backup.
    • バックアップ用に有効になっている Linux VM の該当の Python のバージョンが 2.7 であることを確認してください。Make sure that python version on Linux VMs enabled for backup is 2.7

    データの暗号化Data encryption

    Azure Backup では、データはバックアップ プロセスの一部として暗号化されません。Azure Backup does not encrypt data as a part of the backup process. ただし、VM 内でデータを暗号化し、保護されたデータをシームレスにバックアップできます ( 暗号化データのバックアップの詳細をご覧ください)。However, you can encrypt data within the VM and back up the protected data seamlessly (read more about backup of encrypted data).

    保護するインスタンスのコストの計算Calculating the cost of protected instances

    Azure Backup を使用してバックアップされている Azure 仮想マシンは、 Azure Backup の価格の対象になります。Azure virtual machines that are backed up through Azure Backup are subject to Azure Backup pricing. 保護するインスタンスの計算は、仮想マシンの "実際" のサイズ ("リソース ディスク" を除く、仮想マシン上の全データの合計) に基づきます。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 “resource disk.”

    VM をバックアップする価格は、仮想マシンに接続されている各データ ディスクの最大サポート サイズに基づき "ません"。Pricing for backing up VMs is not based on the maximum supported size for each data disk attached to the virtual machine. 価格は、データ ディスクに格納された実際のデータに基づきます。Pricing is based on the actual data stored in the data disk. 同様に、バックアップ ストレージの課金は、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.

    たとえば、最大サイズが各 1 TB のデータ ディスクが 2 台追加で搭載されている A2 標準サイズの仮想マシンがあります。For example, take an A2 Standard-sized virtual machine that has two additional data disks with a maximum size of 1 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 1023 GB1023 GB 17 GB17 GB
    ローカル ディスク / リソース ディスクLocal disk / Resource disk 135 GB135 GB 5 GB (バックアップに含まれない)5 GB (not included for backup)
    データ ディスク 1Data disk 1 1023 GB1023 GB 30 GB30 GB
    データ ディスク 2Data disk 2 1023 GB1023 GB 0 GB0 GB

    この場合の仮想マシンの 実際 のサイズは、17 GB + 30 GB + 0 GB = 47 GB です。The actual size of the 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.

    課金は、最初のバックアップが正常に完了するまでは開始されません。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.

    保護が停止されてさらにすべてのバックアップ データが削除されている場合のみ、指定した仮想マシンの課金が停止します。Billing for a specified virtual machine 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.


    ご不明な点がある場合や今後搭載を希望する機能がある場合は、 フィードバックをお送りくださいIf you have questions, or if there is any feature that you would like to see included, send us feedback.

    次の手順Next steps