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. 最初のバックアップ時に、バックアップ拡張機能が VM (実行されている場合) にインストールされます。During the first backup, a backup extension is installed on VM if it's 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 は VSS と連携して、VM のアプリ整合性スナップショットを取得します。For Windows VMs that are running, Backup coordinates with VSS to take an app-consistent snapshot of the VM.

    • 既定では、Backup で完全 VSS バックアップを取得します。By default Backup takes full VSS backups.
    • Backup はアプリ整合性スナップショットを取得できない場合、基になるストレージのファイル整合性スナップショットを取得します (VM の停止中はアプリケーションの書き込みは行われないため)。If Backup is unable to take an app-consistent snapshot, then it takes a file-consistent snapshot of the underlying storage (since 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. スナップショットが作成されると、データはバックアップ コンテナーに転送されます。After the snapshot is taken the data is transferred to the vault.

    • Backup は、各 VM ディスクを並行してバックアップすることで最適化されます。Backup is optimized by backing up each VM disk in parallel.
    • バックアップされているディスクごとに、Azure Backup はディスク上のブロックを読み取り、前回のバックアップ以降に変更されたデータ ブロックのみ (差分) を識別して転送します。For each disk being backed up, Azure Backup reads the blocks on disk, and identifies and transfers only data blocks that have changed since the previous backup (the delta).
    • スナップショットが取得された後、データはコンテナーに転送されます。After the snapshot is taken, the data is transferred to the vault.
    • スナップショット データはコンテナーにすぐにコピーされない場合があります。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 that 24 hours for daily backup policies.
  6. データ転送が完了すると、スナップショットが削除され、回復ポイントが作成されます。When the data transfer is complete, the snapshot is removed and a recovery point is created.

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

Azure VM バックアップの暗号化Encrypting 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 (ADE) を使用して暗号化された Azure VM をバックアップできます。In addition, Azure Backup can back up Azure VMs that are encrypted using Azure Disk Encryption (ADE).

暗号化Encryption 詳細Details サポートSupport
ADEADE ADE は Azure VM の OS とデータ ディスクの両方を暗号化します。ADE encrypts both OS and data disks for Azure VMs.

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

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

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

暗号化されたキーとシークレットは、承認されていないユーザーによって、または Azure によって読み取ることはできません。Encrypted keys and secrets can't be read by unauthorized users, or by Azure.
SSESSE SSE では、データを格納する前に自動的に暗号化し、取得前に暗号化を解除することによって、保存中の暗号化を Azure ストレージが提供します。With SSE, Azure storage provides encryption at rest by automatically encrypting data before storing it, and decrypts it before retrieval. Azure Backup では、Azure VM の保存中暗号化のために SSE を使用します。Azure Backup uses SSE for at rest encryption of Azure VMs.
  • マネージドおよびアンマネージド 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 backed up BEK (secrets) and KEK (keys) are encrypted. 承認されたユーザーによってキー コンテナーに復元されたときに限り、読み取りと使用が可能です。They can be read and used only when restored back to key vault by authorized users. 承認されていないユーザーも Azure も、バックアップされたキーまたはシークレットの読み取りまたは使用はできません。Neither unauthorized users nor Azure can read or use backed up keys or secrets.
  • BEK もバックアップされるため、BEK が失われた場合、承認されたユーザーは BEK を KeyVault に復元し、暗号化された VM を復旧できます。Since the BEK is also backed up, if the BEK is lost, authorized users can restore the BEK to the KeyVault, and recover the encrypted VM.
  • 正しいレベルの権限を持つユーザーのみが暗号化された VM、およびキーとシークレットをバックアップして復元できます。Only users with the right level of permissions can back up and restore encrypted VMs, as well as keys and secrets.

スナップショットの取得Taking snapshots

Azure Backup はバックアップ スケジュールに従ってスナップショットを取得します。Azure Backup snapshots in accordance with the backup schedule.

  • Windows VM:Windows VM については、Backup サービスはボリューム シャドウ コピー サービス (VSS) と連携して VM ディスクのアプリ整合性スナップショットを取得します。Windows VMs: For Windows VMs, the Backup service coordinates with the Volume Shadow Copy Service (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 コピー バックアップを作成するように設定を変更する場合は、コマンド プロンプトから次のレジストリ キーを設定してください。REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v USEVSSCOPYBACKUP /t REG_SZ /d TRUE /fIf you want to change the setting so that Azure Backups 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 /f.
  • Linux VM:Linux VM のアプリ整合性スナップショットを取得する場合は、Linux の事前スクリプトおよび事後スクリプトのフレームワークを使用して、整合性を保証するための独自のカスタム スクリプトを記述してください。Linux VMs: If you want to take app-consistent snapshots of Linux VM, use the Linux pre-script and post-script framework to write your own custom scripts to ensure consistency.
    • Azure Backup は、ユーザーが記述した事前/事後スクリプトのみを呼び出します。Azure Backup only invokes the pre/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.

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

次の表で、整合性の種類について説明します。The following table explains different types of 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 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. Windows:すべての VSS ライターが成功したWindows: All VSS writers succeeded

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

ファイル整合性スナップショットによる復旧では、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. Windows:一部の VSS ライターが失敗したWindows: Some VSS writers failed

Linux:既定 (事前/事後スクリプトが構成されていないか失敗した)Linux: Default (if pre/post scripts are not configured or failed)
クラッシュ整合性Crash-consistent クラッシュ整合性は多くの場合、バックアップ時に 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. VM がシャット ダウン状態にあるVM is in shutdown state

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

考慮事項Consideration 詳細Details
ディスクDisk VM ディスクのバックアップは並列です。Backup of VM disk is parallel. たとえば、VM にディスクが 4 つある場合、サービスは 4 つすべてのディスクを並列でバックアップしようとします。For example, if a VM has four disks, the 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, with no overlaps. 同時に VM をバックアップすると、トラフィックの渋滞が発生します。Backing up VMs at the same time causes traffic jams.
バックアップの準備Preparing backups バックアップの準備時間を考慮してください。これには、バックアップ拡張機能のインストールまたは更新と、バックアップ スケジュールに従ったスナップショットのトリガーが含まれます。Consider the backup preparation time, which includes installing or updating the backup extension, and triggering a snapshot in accordance with the backup schedule.
データ転送Data transfer バックアップ サービスが前回のバックアップからの増分変更を計算するために必要な時間です。Time needed for backup service to compute the incremental changes from the previous backup.

増分バックアップでは、変更を特定するために、サービスはブロックのチェックサムを計算します。In an incremental backup, determine the changes the service computers the checksum of the block. ブロックが変更されている場合、コンテナーへの送信用に識別されます。If a block is changed its identified for sending to the vault. サービスは識別されたブロックを精査して、転送するデータをさらに最小化しようとします。The service drills into identified blocks to attempt to further minimize the data to transfer. 変更されているすべてのブロックを評価した後、変更がコンテナーに転送されます。After evaluating all changed blocked the changes are transferred 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 process. 毎日のバックアップでは、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 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.
復元キューRestore queue Azure Backup は複数のストレージ アカウントからの復元ジョブを同時に処理し、復元要求はキューに入れられます。Azure Backup processes restore jobs from multiple storage accounts at the same time, and restore requests are put in a queue.
復元コピーRestore copy 復元処理の間、データがコンテナーからストレージ アカウントにコピーされます。During the restore process, data is copied from the vault to the storage account.

復元時間はストレージ アカウントの IOPS とスループットによって異なります。Restore time depends on IOPS and 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 backup time:

  • 保護された Azure VM に新しいディスクを追加する:増分バックアップが実行されている VM に新しいディスクを追加した場合、既存ディスクの差分レプリケーションに加えて新しいディスクの初期レプリケーションが行われるため、バックアップが 24 時間で終わらないことがあります。Add a new disk to a protected Azure VM: If a VM is undergoing incremental backup and a new disk is added, backup might last more than 24 hours due to initial replication of the new disk, along with delta replication of existing disks.
  • 断片化したディスク:ディスクの変更が併置されていると、バックアップ操作が速くなります。Fragmented disks: Backup operations are faster when disk changes are collocated. 変更がディスク全体に分散および断片化している場合、バックアップは遅くなります。If changes are spread out and fragmented across a disk, backup will be slower.
  • ディスク チャーン:増分バックアップが実行されている保護されたディスクで毎日のチャーンが 200 GB を超える場合、バックアップの完了に時間がかかる (8 時間を超える) 可能性があります。Disk churn: If protected disks 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 versions: If you're using the latest version of Backup (known as the Instant Restore version), it uses a more optimized process than checksum comparison for comparing changes. 最新バージョンを使用していて、バックアップ スナップショットを削除した場合、チェックサム比較を使用したバックアップに切り替わり、バックアップ操作は 24 時間を超えます (または失敗します)。If you're using the latest version and have deleted a backup snapshot, the backup switches to use checksum comparison, and the backup operation will exceed 24 hours (or fail).

ベスト プラクティスBest practices

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

  • ポリシーで設定されている既定のスケジュール時間の変更を検討します。Consider modifying the default schedule time set in a policy. たとえば、ポリシーで既定の時間が 12:00AM の場合、リソースの使用を最適化するために分単位で時間を進めることを検討してください。For example, if the default time is the policy is 12:00AM, consider incrementing it by minutes so that 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 にある場合は、復元を高速化するために、インスタント リストア機能を使用することをお勧めします (データをコンテナーから復元しなければならない場合は、処理時間が長くなります)。We recommend you to use Instant Restore 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 doesn't start until the first successful backup completes. この時点で、ストレージと保護する VM の両方に対する課金が開始されます。At this point, the billing for both storage and protected VMs begins.
  • VM のコンテナー内に格納されたバックアップ データが存在する限り、課金は継続されます。Billing continues as long as there is any backup data stored in a vault for the VM. 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 の実際のサイズ (一時ストレージを除く、VM 内のすべてのデータの合計) に基づきます。The protected instances calculation is based on the actual size of the VM, which is the sum of all the data in the VM, excluding the temporary storage.
  • 価格は、データ ディスクに格納された実際のデータに基づきます。Pricing is based on the actual data stored in the data disk.
  • VM をバックアップするための価格は、VM に接続されたデータ ディスクごとのサポートされる最大サイズには基づきません。Pricing for backing up VMs is not based on the maximum supported size for each data disk attached to the VM.
  • 同様に、バックアップ ストレージの課金は、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 標準サイズの 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 gives 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 accordingly.

次の手順Next steps

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