Azure VM バックアップの概要An overview of Azure VM backup

この記事では、Azure Backup サービスによって Azure 仮想マシン (VM) がどのようにバックアップされるかについて説明します。This article describes how the Azure Backup service backs up Azure virtual machines (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, Azure Backup starts a backup job according to the backup schedule you specify.

  2. 最初のバックアップ時に、バックアップ拡張機能が VM にインストールされます (VM が実行されている場合)。During the first backup, a backup extension is installed on the VM if the VM is running.

    • Windows VM の場合、VMSnapshot 拡張機能がインストールされます。For Windows VMs, the VMSnapshot extension is installed.
    • Linux VM の場合、VMSnapshotLinux 拡張機能がインストールされます。For Linux VMs, the VMSnapshotLinux extension is installed.
  3. 実行されている Windows VM については、Backup は Windows ボリューム シャドウ コピー サービス (VSS) と連携して VM のアプリ整合性スナップショットを取得します。For Windows VMs that are running, Backup coordinates with Windows Volume Shadow Copy Service (VSS) to take an app-consistent snapshot of the VM.

    • 既定では、Backup によって完全 VSS バックアップが取得されます。By default, Backup takes full VSS backups.
    • Backup はアプリ整合性スナップショットを取得できない場合、基になるストレージのファイル整合性スナップショットを取得します (VM の停止中はアプリケーションの書き込みは行われないため)。If Backup can't take an app-consistent snapshot, then it takes a file-consistent snapshot of the underlying storage (because no application writes occur while the VM is stopped).
  4. Linux VM の場合、Backup ではファイル整合性スナップショットが取得されます。For Linux VMs, Backup takes a file-consistent backup. アプリ整合性スナップショットの場合は、事前/事後スクリプトを手動でカスタマイズする必要があります。For app-consistent snapshots, you need to manually customize pre/post scripts.

  5. Backup でスナップショットが取得された後、コンテナーにデータが転送されます。After Backup takes the snapshot, it transfers the data to the vault.

    • バックアップは、各 VM ディスクを並列にバックアップすることで最適化されます。The backup is optimized by backing up each VM disk in parallel.
    • バックアップされているディスクごとに、Azure Backup はディスク上のブロックを読み取り、前回のバックアップ以降に変更されたデータ ブロックのみ (差分) を識別して転送します。For each disk that's being backed up, Azure Backup reads the blocks on the disk and identifies and transfers only the data blocks that changed (the delta) since the previous backup.
    • スナップショット データはコンテナーにすぐにコピーされない場合があります。Snapshot data might not be immediately copied to the vault. ピーク時には、数時間かかる場合があります。It might take some hours at peak times. 毎日のバックアップ ポリシーでは、VM のバックアップの合計時間は 24 時間未満になります。Total backup time for a VM will be less than 24 hours for daily backup policies.
  6. Azure Backup がここで有効化された後に Windows VM に加えられた変更は次のとおりです。Changes made to a Windows VM after Azure Backup is enabled on it are:

    • Microsoft Visual C++ 2013 redistributable (x64) - 12.0.40660 が VM にインストールされています。Microsoft Visual C++ 2013 Redistributable(x64) - 12.0.40660 is installed in the VM
    • ボリューム シャドウ コピー サービス (VSS) のスタートアップの種類が手動から自動に変更されています。Startup type of Volume Shadow Copy service (VSS) changed to automatic from manual
    • IaaSVmProvider Windows サービスが追加されます。IaaSVmProvider Windows service is added
  7. データ転送が完了すると、スナップショットが削除され、回復ポイントが作成されます。When the data transfer is complete, the snapshot is removed, and a recovery point is created.

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

Azure VM バックアップの暗号化Encryption of Azure VM backups

Azure Backup を使用して Azure VM をバックアップするとき、保存中の VM は Storage Service Encryption (SSE) を使用して暗号化されます。When you back up Azure VMs with Azure Backup, VMs are encrypted at rest with Storage Service Encryption (SSE). Azure Backup では、Azure Disk Encryption を使用して暗号化されている Azure VM もバックアップできます。Azure Backup can also back up Azure VMs that are encrypted by using Azure Disk Encryption.

暗号化Encryption 詳細Details サポートSupport
Azure Disk EncryptionAzure Disk Encryption Azure Disk Encryption では Azure VM の OS とデータ ディスクの両方が暗号化されます。Azure Disk Encryption encrypts both OS and data disks for Azure VMs.

Azure Disk Encryption は、シークレットとしてキー コンテナーで保護されている BitLocker 暗号化キー (BEK) と統合されます。Azure Disk Encryption integrates with BitLocker encryption keys (BEKs), which are safeguarded in a key vault as secrets. Azure Disk Encryption は、Azure Key Vault キー暗号化キー (KEK) とも統合されます。Azure Disk Encryption also integrates with Azure Key Vault key encryption keys (KEKs).
Azure Backup では、BEK のみで、または BEK と KEK を併用して、暗号化されたマネージドおよびアンマネージド Azure VM のバックアップがサポートされます。Azure Backup supports backup of managed and unmanaged Azure VMs encrypted with BEKs only, or with BEKs together with KEKs.

BEK と KEK の両方がバックアップされて暗号化されます。Both BEKs and KEKs are backed up and encrypted.

KEK と BEK がバックアップされるため、必要に応じて、必要なアクセス許可を持つユーザーは、キーとシークレットをキー コンテナーに復元できます。Because KEKs and BEKs are backed up, users with the necessary permissions can restore keys and secrets back to the key vault if needed. ユーザーは、暗号化された VM を復旧することもできます。These users can also recover the encrypted VM.

暗号化されたキーとシークレットは、承認されていないユーザーによって、または Azure によって読み取ることはできません。Encrypted keys and secrets can't be read by unauthorized users or by Azure.
SSESSE SSE では、Azure Storage により、データを格納する前に自動的に暗号化することで、保存中の暗号化が提供されます。With SSE, Azure Storage provides encryption at rest by automatically encrypting data before storing it. Azure Storage では、取得前にデータの暗号化解除も行われます。Azure Storage also decrypts data before retrieving it. Azure Backup では、Azure VM の保存中の暗号化のために SSE が使用されます。Azure Backup uses SSE for at-rest encryption of Azure VMs.

マネージドおよびアンマネージド Azure VM の場合、Backup では、BEK のみで暗号化された VM と、BEK と KEK を併用して暗号化された VM の両方がサポートされます。For managed and unmanaged Azure VMs, Backup supports both VMs encrypted with BEKs only or VMs encrypted with BEKs together with KEKs.

バックアップされる BEK (シークレット) と KEK (キー) は暗号化されます。The backed-up BEKs (secrets) and KEKs (keys) are encrypted. 承認されたユーザーによってキー コンテナーに復元されたときに限り、読み取りと使用が可能です。They can be read and used only when they're restored back to the key vault by authorized users. 承認されていないユーザーも Azure も、バックアップされたキーまたはシークレットの読み取りまたは使用はできません。Neither unauthorized users nor Azure can read or use backed-up keys or secrets.

BEK もバックアップされます。BEKs are also backed up. そのため、BEK が失われた場合、承認されたユーザーは BEK をキー コンテナーに復元し、暗号化された VM を復旧できます。So, if the BEKs are lost, authorized users can restore the BEKs to the key vault and recover the encrypted VMs. 必要なレベルの権限を持つユーザーのみが、暗号化された VM またはキーとシークレットを、バックアップして復元できます。Only users with the necessary level of permissions can back up and restore encrypted VMs or keys and secrets.

スナップショットの作成Snapshot creation

Azure Backup では、バックアップ スケジュールに従ってスナップショットが取得されます。Azure Backup takes snapshots according to the backup schedule.

  • Windows VM: Windows VM の場合、Backup サービスは VSS と連携して、VM ディスクのアプリ整合性スナップショットを取得します。Windows VMs: For Windows VMs, the Backup service coordinates with VSS to take an app-consistent snapshot of the VM disks.

    • 既定では、Azure Backup は完全 VSS バックアップを取得します。By default, Azure Backup takes full VSS backups. 詳細情報Learn more.

    • Azure Backup によって VSS コピー バックアップが作成されるように設定を変更するには、コマンド プロンプトから次のレジストリ キーを設定します。To change the setting so that Azure Backup takes VSS copy backups, set the following registry key from a command prompt:

      REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v USEVSSCOPYBACKUP /t REG_SZ /d TRUE /fREG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v USEVSSCOPYBACKUP /t REG_SZ /d TRUE /f

  • Linux VM: Linux VM のアプリ整合性スナップショットを取得するには、Linux の事前スクリプトおよび事後スクリプトのフレームワークを使用して、整合性を保証するための独自のカスタム スクリプトを記述します。Linux VMs: To take app-consistent snapshots of Linux VMs, use the Linux pre-script and post-script framework to write your own custom scripts to ensure consistency.

    • Azure Backup では、ユーザーが記述した事前/事後スクリプトのみが呼び出されます。Azure Backup invokes only the pre/post scripts written by you.
    • 事前スクリプトと事後スクリプトが正常に実行されると、Azure Backup は復旧ポイントをアプリケーション整合性としてマークします。If the pre-scripts and post-scripts execute successfully, Azure Backup marks the recovery point as application-consistent. ただし、カスタム スクリプトを使用したときのアプリケーション整合性の最終的な責任はユーザーが担います。However, when you're using custom scripts, you're ultimately responsible for the application consistency.
    • スクリプトの構成方法に関する詳細を確認してください。Learn more about how to configure scripts.

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

次の表では、スナップショットの整合性の種類について説明します。The following table explains the different types of snapshot consistency:

スナップショットSnapshot 詳細Details 復旧Recovery 考慮事項Consideration
アプリケーションの整合性Application-consistent アプリ整合性バックアップでは、メモリの内容と保留中の I/O 操作がキャプチャされます。App-consistent backups capture memory content and pending I/O operations. アプリ整合性スナップショットでは、バックアップが発生する前にアプリ データの整合性を保証するために、VSS ライター (または Linux の事前/事後スクリプト) が使用されます。App-consistent snapshots use a VSS writer (or pre/post scripts for Linux) to ensure the consistency of the app data before a backup occurs. アプリ整合性スナップショットで VM を復旧すると、VM が起動されます。When you're recovering a VM with an app-consistent snapshot, the VM boots up. データの損失や破損はありません。There's no data corruption or loss. アプリは整合性が確保された状態で開始します。The apps start in a consistent state. Windows:すべての VSS ライターが成功したWindows: All VSS writers succeeded

Linux:事前/事後スクリプトが構成されて成功したLinux: Pre/post scripts are configured and succeeded
ファイル システム整合性File-system consistent ファイル システム整合性バックアップでは、同時にすべてのファイルのスナップショットを作成することで整合性が提供されます。File-system consistent backups provide consistency by taking a snapshot of all files at the same time.

ファイル システム整合性スナップショットで VM を復旧すると、VM が起動されます。When you're recovering a VM with a file-system 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. Windows:一部の VSS ライターが失敗したWindows: Some VSS writers failed

Linux:既定 (事前/事後スクリプトが構成されていないか失敗した)Linux: Default (if pre/post scripts aren't configured or failed)
クラッシュ整合性Crash-consistent クラッシュ整合性スナップショットは、通常、バックアップ時に Azure VM がシャットダウンした場合に発生します。Crash-consistent snapshots typically occur if 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 が起動します。その後、ディスク検査が実行されて、破損エラーが修正されます。Although there are no guarantees, the VM usually boots, and then it starts a disk check to fix corruption errors. クラッシュ前にディスクに転送されなかったメモリ内のデータや書き込み操作は、すべて失われます。Any in-memory data or write operations that weren't transferred to disk before the crash are lost. アプリは独自のデータ検証を実装しています。Apps implement their own data verification. たとえば、データベース アプリでは検証のためトランザクション ログを使用できます。For example, a database app can use its transaction log for verification. トランザクション ログにデータベース内に存在しないエントリが含まれている場合、データベース ソフトウェアはデータの整合性が得られるまでトランザクションをロールバックします。If the transaction log has entries that aren't in the database, the database software rolls transactions back until the data is consistent. VM がシャット ダウン状態にあるVM is in shutdown state

バックアップと復元の考慮事項Backup and restore considerations

考慮事項Consideration 詳細Details
ディスクDisk VM ディスクのバックアップは並列です。Backup of VM disks is parallel. たとえば、VM にディスクが 4 つある場合、Backup サービスは 4 つすべてのディスクを並列でバックアップしようとします。For example, if a VM has four disks, the Backup service attempts to back up all four disks in parallel. バックアップは増分的 (変更されたデータのみ) です。Backup is incremental (only changed data).
スケジュール設定Scheduling バックアップ トラフィックを減らすには、異なる VM を一日の異なる時間帯にバックアップし、時間帯が重ならないようにします。To reduce backup traffic, back up different VMs at different times of the day and make sure the times don't overlap. 同時に VM をバックアップすると、トラフィックの渋滞が発生します。Backing up VMs at the same time causes traffic jams.
バックアップの準備Preparing backups バックアップの準備に必要な時間に注意してください。Keep in mind the time needed to prepare the backup. 準備時間には、バックアップ拡張機能のインストールまたは更新と、バックアップ スケジュールに従ったスナップショットのトリガーが含まれます。The preparation time includes installing or updating the backup extension and triggering a snapshot according to the backup schedule.
データ転送Data transfer Azure Backup で前回のバックアップからの増分変更を識別するために必要な時間を考慮してください。Consider the time needed for Azure Backup to identify the incremental changes from the previous backup.

増分バックアップの Azure Backup では、ブロックのチェックサムを計算することによって、変更が特定されます。In an incremental backup, Azure Backup determines the changes by calculating the checksum of the block. ブロックが変更されている場合は、コンテナーに転送するようにマークされます。If a block is changed, it's marked for transfer to the vault. サービスは識別されたブロックを分析して、転送するデータ量をさらに最小化しようとします。The service analyzes the identified blocks to attempt to further minimize the amount of data to transfer. 変更されたすべてのブロックが評価された後、Azure Backup によってコンテナーに変更が転送されます。After evaluating all the changed blocks, Azure Backup transfers the changes to the vault.

スナップショットを取得してからコンテナーにコピーするまでの間、ラグが生じる場合があります。There might be a lag between taking the snapshot and copying it to vault.

ピーク時には、バックアップの処理に最大 8 時間かかる可能性があります。At peak times, it can take up to eight hours for backups to be processed. 毎日のバックアップでは、VM のバックアップ時間は 24 時間未満になります。The backup time for a VM will be less than 24 hours for the daily backup.
初回バックアップInitial backup 増分バックアップの合計バックアップ時間は 24 時間未満ですが、初回バックアップではそうはならないことがあります。Although the total backup time for incremental backups is less than 24 hours, that might not be the case for the first backup. 初回バックアップに必要な時間は、データのサイズと、いつバックアップが処理されるかによって異なります。The time needed for the initial backup will depend on the size of the data and when the backup is processed.
復元キューRestore queue Azure Backup では複数のストレージ アカウントからの復元ジョブが同時に処理され、復元要求はキューに入れられます。Azure Backup processes restore jobs from multiple storage accounts at the same time, and it puts restore requests in a queue.
復元コピーRestore copy 復元処理の間、データがコンテナーからストレージ アカウントにコピーされます。During the restore process, data is copied from the vault to the storage account.

合計復元時間は、1 秒あたりの I/O 操作数 (IOPS) とストレージ アカウントのスループットに依存します。The total restore time depends on the I/O operations per second (IOPS) and the throughput of the storage account.

コピー時間を短縮するには、他のアプリケーションの書き込みおよび読み取りの負荷がないストレージ アカウントを選択します。To reduce the copy time, select a storage account that isn't loaded with other application writes and reads.

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

以下の一般的なシナリオは、合計バックアップ時間に影響を与える可能性があります。These common scenarios can affect the total backup time:

  • 保護された Azure VM への新しいディスクの追加: VM で増分バックアップが行われているときに、新しいディスクが追加されると、バックアップの時間が長くなります。Adding a new disk to a protected Azure VM: If a VM is undergoing incremental backup and a new disk is added, the backup time will increase. 既存ディスクの差分レプリケーションに加えて、新しいディスクの初期レプリケーションが行われるため、合計バックアップが 24 時間を超える場合があります。The total backup time might last more than 24 hours because of initial replication of the new disk, along with delta replication of existing disks.
  • 断片化したディスク: ディスクの変更が連続していると、バックアップ操作は速くなります。Fragmented disks: Backup operations are faster when disk changes are contiguous. 変更がディスク全体に分散および断片化している場合、バックアップは遅くなります。If changes are spread out and fragmented across a disk, backup will be slower.
  • ディスク チャーン: 増分バックアップが実行されている保護されたディスクで毎日のチャーンが 200 GB を超える場合、バックアップの完了に時間がかかる (8 時間を超える) 可能性があります。Disk churn: If protected disks that are undergoing incremental backup have a daily churn of more than 200 GB, backup can take a long time (more than eight hours) to complete.
  • バックアップのバージョン: (インスタント リストア バージョンと呼ばれる) 最新バージョンの Backup では、変更の識別に、チェックサム比較より最適化されたプロセスが使用されます。Backup versions: The latest version of Backup (known as the Instant Restore version) uses a more optimized process than checksum comparison for identifying changes. ただし、インスタント リストアを使用していて、バックアップ スナップショットを削除した場合、バックアップはチェックサム比較に切り替わります。But if you're using Instant Restore and have deleted a backup snapshot, the backup switches to checksum comparison. この場合、バックアップ操作は 24 時間を超えます (または失敗します)。In this case, the backup operation will exceed 24 hours (or fail).

ベスト プラクティスBest practices

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

  • ポリシーで設定されている既定のスケジュール時間を変更します。Modify the default schedule times that are set in a policy. たとえば、ポリシーで既定の時間が午前 0 時の場合、リソースが最適に使用されるよう、数分時間を進めることを検討してください。For example, if the default time in the policy is 12:00 AM, increment the timing by several minutes so that resources are optimally used.
  • 1 つのコンテナーから複数の VM を復元する場合は、ターゲットのストレージ アカウントがスロットルされないようにするために、それぞれ異なる汎用 v2 ストレージ アカウントを使用することを強くお勧めします。If you're restoring VMs from a single vault, we highly recommend that you use different general-purpose v2 storage accounts to ensure that the target storage account doesn’t get throttled. たとえば、VM ごとに異なるストレージ アカウントが必要です。For example, each VM must have a different storage account. たとえば、10 個の VM を復元する場合は、10 個の異なるストレージ アカウントを使用します。For example, if 10 VMs are restored, use 10 different storage accounts.
  • インスタント リストアで Premium Storage を使用している VM のバックアップについては、割り当てられた合計ストレージ領域の 50% の空き領域 (最初のバックアップにのみ必要) を割り当てることをお勧めします。For backup of VMs that are using premium storage, with Instant Restore, we recommend allocating 50% free space of the total allocated storage space, which is required only for the first backup. 最初のバックアップが完了すると、バックアップに 50% の空き領域は不要になります。The 50% free space is not a requirement for backups after the first backup is complete
  • 汎用 v1 ストレージ レイヤー (スナップショット) からの復元は、スナップショットが同じストレージ アカウントにあるため、分単位で完了します。The restores from a general-purpose v1 storage layer (snapshot) will be completed in minutes because the snapshot is in the same storage account. 汎用 v2 ストレージ レイヤー (コンテナー) からの復元には、数時間かかります。Restores from the general-purpose v2 storage layer (vault) can take hours. データが汎用 v1 ストレージで使用できる場合は、復元を高速化するためインスタント リストア機能を使用することをお勧めします。In cases where the data is available in general-purpose v1 storage, we recommend that you use the Instant Restore feature for faster restores. (データをコンテナーから復元する必要がある場合、さらに時間がかかります。)(If the data must be restored from a vault, then it will take more time.)
  • ストレージ アカウントあたりのディスク数の制限は、サービスとしてのインフラストラクチャ (IaaS) VM で実行されているアプリケーションがディスクにどれくらいアクセスするかによって決まります。The limit on the number of disks per storage account is relative to how heavily the disks are being accessed by applications that are running on an infrastructure as a service (IaaS) VM. 通常、1 つのストレージ アカウント上に 5 ~ 10 個以上のディスクが存在する場合は、一部のディスクを別のストレージ アカウントに移動して負荷を分散します。As a general practice, if 5 to 10 disks or more are present on a 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 doesn't start until the first successful backup finishes. この時点で、ストレージと保護する VM の両方に対する課金が開始されます。At this point, the billing for both storage and protected VMs begins. VM のバックアップ データがコンテナーに格納されている限り、課金は継続されます。Billing continues as long as any backup data for the VM is stored in a vault. VM の保護を停止したが VM のバックアップ データがコンテナーに存在している場合、課金は継続されます。If you stop protection for a VM, but backup data for the VM 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.

保護されたインスタンス サイズの計算は、"実際の" VM のサイズに基づきます。The protected-instance size calculation is based on the actual size of the VM. VM のサイズは、一時的なストレージを除く、VM 内のすべてのデータの合計です。The VM's size is the sum of all the data in the VM, excluding the temporary storage. 価格は、VM にアタッチされている各データ ディスクの最大サポート サイズではなく、データ ディスクに格納されている実際のデータに基づきます。Pricing is based on the actual data that's stored on the data disks, not on the maximum supported size for each data disk that's attached to the VM.

同様に、バックアップ ストレージの課金は、Azure Backup に格納されているデータ量 (各回復ポイントの実際のデータの合計) に基づきます。Similarly, the backup storage bill is based on the amount of data that's stored in Azure Backup, which is the sum of the actual data in each recovery point.

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

ディスクDisk 最大サイズMax size 実際のデータ量Actual data present
OS ディスクOS disk 4095 GB4095 GB 17 GB17 GB
ローカル/一時ディスクLocal/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 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. VM のデータ量が大きくなると、課金に使用される保護されたインスタンスのサイズもそれに応じて変化します。As the amount of data in the VM grows, the protected-instance size used for billing changes to match.

パブリック プレビュー:ディスク サイズが最大 30 TB のVM のバックアップPublic Preview: Backup of VM with disk sizes up to 30 TB

Azure Backup では、サイズが最大 30 TB の大規模で強力な Azure Managed Disks のパブリック プレビューがサポートされるようになりました。Azure Backup now supports public preview of larger and more powerful Azure Managed Disks of up to 30 TB in size. このプレビューでは、マネージド仮想マシンの運用レベルのサポートが提供されます。This preview provides production-level support for managed virtual machines.

仮想マシンのバックアップ (各ディスクのサイズは最大 30 TB で、VM 内の全ディスクを結合して最大 256 TB) が、既存のバックアップに影響を与えることなく、シームレスに行われます。The backups for your virtual machines with each disk size up to 30TB and a maximum of 256TB combined for all disks in a VM should work seamlessly without impacting your existing backups. Azure Backup で仮想マシンが構成済みであれば、大容量のディスクに対してバックアップを実行するのにユーザーの操作は必要ありません。There is no user action required to get the backups running for the large sized disks, if the virtual machine is already configured with Azure Backup.

大容量のディスクがある、バックアップが構成されたすべての Azure 仮想マシンは、正常にバックアップされます。All Azure Virtual Machines with large disks having backup configured should be successfully backed up.

次の手順Next steps

Azure VM バックアップの準備に進みます。Now, prepare for Azure VM backup.