よく寄せられる質問 - Azure VM のバックアップ

VM を作成するときに、サポートされているオペレーティング システムを実行している VM に対してバックアップを有効にできます。

初回バックアップは常に完全バックアップとなります。その所要時間は、データのサイズと、いつバックアップが処理されるかによって異なります。

バックアップのパフォーマンスを向上させる方法については、バックアップのベストプラクティス、バックアップに関する考慮事項、および「バックアップ パフォーマンス」を参照してください

増分バックアップの合計バックアップ時間は 24 時間未満ですが、初回バックアップではそうはならないことがあります。

いいえ。 バックアップのコストは VM のコストとは別です。 Azure Backup の価格については、こちらを参照してください。

VM の共同作成者の場合は、VM でバックアップを有効にできます。 カスタム ロールを使用している場合、VM でバックアップを有効にするには、次のアクセス許可が必要です。

• Microsoft.RecoveryServices/Vaults/write
• Microsoft.RecoveryServices/Vaults/read
• Microsoft.RecoveryServices/locations/*
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/*/read
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/read
• Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/write
• Microsoft.RecoveryServices/Vaults/backupFabrics/backupProtectionIntent/write
• Microsoft.RecoveryServices/Vaults/backupPolicies/read
• Microsoft.RecoveryServices/Vaults/backupPolicies/write

Recovery Services コンテナーと VM が異なるリソース グループに属している場合は、Recovery Services コンテナーのリソース グループへの書き込みアクセス許可があることを確認してください。

いいえ。 オンデマンド バックアップ ジョブのリテンション期間を指定してください。 ポータルからトリガーした場合、既定では 30 日間保存されます。

Azure Backup に Key Vault へのアクセス許可を付与してください。 Azure Backup PowerShell ドキュメントのバックアップの有効化に関するセクションの説明に従って、PowerShell でアクセス許可を指定します。

はい。バックアップはシームレスに機能します。 何も再構成する必要はありません。

ウィザードにはコンテナーと同じリージョンで、まだバックアップされていない VM のみが表示されます。

はい。 マシンがシャットダウンされていても、バックアップは動作します。 復旧ポイントはクラッシュ整合としてマークされます。

はい。 スナップショットの作成中状態のバックアップ ジョブは取り消すことができます。 スナップショットからのデータ転送が進行中である場合は、ジョブを取り消せません。

Azure Backup サービスによって作成されたリソース グループをロックした場合、バックアップは失敗するようになります。 今後のバックアップを成功させるために、ロックを解除し、そのリソース グループからの復元ポイント コレクションをクリアします。 復元ポイント コレクションをクリアするには、こちらの手順に従います。

Azure Backup では、ResourcePointCollections オブジェクトを格納するための別のリソース グループが AzureBackupRG_<geo>_<number> の形式で作成されます。 このリソース グループはサービスが所有するため、これをロックするとバックアップは失敗します。 ロックを適用できるのは、顧客が作成したリソース グループのみです。

はい、Azure Backup では、Standard SSD マネージド ディスクがサポートされています。

スナップショットは、WA が有効かつ OS ディスクではないデータ ディスクに対してのみ作成できます。 そのため、WA が有効になっているデータ ディスクのみを保護できます。

Azure Backup は、WA 対応のデータ ディスクをバックアップできます。 ただし、バックアップによってデータベースの整合性が確保されるわけではありません。

Azure Backup は、SAP HANA データベース用に RPO が 15 分のストリーミング バックアップ ソリューションを提供します。 これは、SAP による Backint 認定がされており、SAP HANA のネイティブ API を活用してネイティブ バックアップ サポートを提供します。 Azure VM での SAP HANA データベースのバックアップについて参照してください。

スケジュールされたバックアップは、スケジュールされたバックアップ時刻から 2 時間以内にトリガーされます。 たとえば、100 個の VM のバックアップ開始時刻が午前 2 時にスケジュールされている場合は、遅くとも午前 4 時までに 100 個のすべての VM のバックアップ ジョブが進行中になります。 スケジュールされたバックアップが停電のために一時停止され、再開または再試行された場合は、バックアップがこのスケジュールされた 2 時間の枠外で開始される可能性があります。

Azure Virtual Machine のバックアップ ポリシーでは、最小リテンション期間の範囲として 7 日から 9999 日までがサポートされています。 既定では、VM のバックアップはスナップショットに "7 日間" 保持され、コンテナーには "180 日間" 保持されます。 7 日間未満に設定された既存の VM バックアップ ポリシーを変更するには、7 日間という最小リテンション期間の範囲を満たすように更新する必要があります。

VM または VM リソース グループの大文字と小文字を変更しても、バックアップ項目の名前の大文字と小文字は変更されません。これは Azure Backup の想定されている動作です。 大文字と小文字の変更はバックアップ項目には反映されませんが、バックエンドで更新されます。

Azure Backup では、Azure 仮想マシン バックアップ ソリューションを使用した選択的ディスク バックアップと復元がサポートされるようになりました。 詳細については、「選択的ディスク バックアップと Azure VM の復元」を参照してください。

テナントの変更が発生した場合、バックアップを再び機能させるには、マネージド ID を無効にしてから再度有効にする必要があります。

Azure Backup では、ストレージまたはその他の NFS サーバーから Linux または Windows コンピューターにマウントされた NFS ファイルのバックアップはサポートされません。 VM にローカルに接続されているディスクのみがバックアップされます。

復元操作を実行するために必要なすべての VM 構成は、VM バックアップに格納されています。 これには、復元時にアクセスできる、VM 暗号化キーの暗号化コピーが含まれます。 暗号化コピーは、キー コンテナーを使用してのみ、暗号化を解除できます。 一時ディスクやメモリの状態はスナップショットに取得されません。

NIC と IP を除き、Azure Backup はタグをバックアップおよび復元できます。 Azure Backup は、Azure リソース グループのサブスクリプションの制限を受け入れ、最大 50 のタグを復元します。

詳細については、「サブスクリプションの制限」を参照してください。

いいえ。スケジュールされたバックアップを無効にすると、オンデマンド バックアップをトリガーできません。

クラスター内のすべての Azure VM は、個々の Azure VM と見なされます。 そのため、すべてのバックアップ操作は、個々の Azure VM ごとに適用されます。

VM スナップショットの作成には数分かかります。この段階では、アプリケーションのパフォーマンスに対する影響はほとんどありません。 ただし、コンテナーへのデータ転送には数時間かかります。そのため、営業時間外にバックアップをスケジュールすることをお勧めします。 詳しくは、バックアップと復元のベスト プラクティスに関するページを参照してください。

はい。VM に追加された新しいディスクは、次のバックアップ時に自動的にバックアップされます。ただし、VM に選択的ディスク バックアップが構成されている場合はこの限りではありません。 VM に新しく追加されたディスクには、最初のバックアップで取得したフル スナップショット (初期レプリカ) があり、既存のディスクは増分ロジック チェーンを続行します。

暗号化された VM バックアップからのファイルとフォルダーの復元は現在サポートされていません。ファイルとフォルダーを復元するには、VM 全体を回復する必要があります。 暗号化された Azure 仮想マシンを復元する手順を参照してください。 ただし、暗号化される前にバックアップからファイルを回復できます。

はい。これは、コンテナーへのデータ転送フェーズが進行中のときに実行できます。

Azure Backup は、バックアップ データの暗号化キーとシークレットをバックアップします。 通常、キーは Key Vault に復元されませんが、Azure Backup では、キーの損失時にキーを復元できます。

いいえ。1 つの復元ポイントを保持することはできません。 前の復元ポイントを削除すると、チェーンが削除されます。 そのため、復旧ポイントを選択的に保持または削除することはできません。

バックアップ ポイントの最大保有期間は次のとおりです。

• 毎日のバックアップ ポイントの保有期間: 9999 日間
• 毎週のバックアップ ポイントの保有期間: 5163 週間
• 毎月のバックアップ ポイントの保有期間: 1188 か月間
• 毎年のバックアップ ポイントの保有期間: 99 年間

VM の復元は、Azure VM 用の簡易的な作成オプションと考えてください。 このオプションでは、ディスク名、そのディスクが使用するコンテナー、パブリック IP アドレス、およびネットワーク インターフェイス名が変更されます。 この変更では、VM 作成時の一意のリソースが維持されます。 VM は可用性セットには追加されません。

ディスクの復元オプションは、次のような場合に使用できます。

• 作成された VM をカスタマイズする。 たとえば、サイズを変更します。
• バックアップ時に存在しなかった構成設定を追加する。
• 作成されたリソースの名前付け規則を制御する。
• VM を可用性セットに追加する。
• PowerShell またはテンプレートを使用して構成する必要があるその他の設定を追加する

はい。ディスクをアンマネージドからマネージドに移行する前に作成したバックアップを使用できます。

復元プロセスは同じままです。 復旧ポイントが VM にアンマネージド ディスクが存在していた時点のものである場合は、ディスクをアンマネージドとして復元できます。 その時点で VM にマネージド ディスクが存在していた場合は、ディスクをマネージド ディスクとして復元できます。 その後、これらのディスクから VM を作成できます。

PowerShell でこれを行う方法の詳細については、こちらをご覧ください。

マネージド VM の復元が発生した場合、VM の作成に失敗した場合でも、ディスクは復元されます。

はい。 VM を削除しても、コンテナー内の対応するバックアップ アイテムに移動して、復元ポイントから復元できます。

マネージド ディスクの Azure VM については、マネージド ディスクとして復元しているときに、可用性セットへの復元オプションがテンプレートに提供されます。 このテンプレートには、可用性セットと呼ばれる入力パラメーターがあります。

インスタント リストア機能は、迅速なバックアップと、スナップショットからの即時のリストアに役立ちます。

暗号化された VM のキー コンテナーの設定を変更した後も、バックアップは新しい詳細情報のセットで引き続き動作します。 ただし、変更前の復元ポイントからの復元後は、キー コンテナー内のシークレットを復元してから VM を作成する必要があります。 詳細については、こちらの記事を参照してください。

シークレットまたはキーのロールオーバーなどの操作では、この手順は必要ありません。復元後も同じキー コンテナーを使用できます。

はい。VM とドメイン コントローラーとの関係が破損しているために復元された VM にアクセスできます。 詳細については、こちらの記事を参照してください。

はい。データ転送フェーズまで復元ジョブをキャンセルできます。 VM 作成フェーズに入ると、復元ジョブを取り消せなくなります。

合計復元時間は、ストレージ アカウントの 1 秒あたりの入出力操作数 (IOPS) の速度とスループットによって変わります。 合計復元時間は、ターゲットのストレージ アカウントに他のアプリケーションの読み取りや書き込み操作が読み込まれる場合、影響を受けることがあります。 復元操作の速度を向上させるには、他のアプリケーション データが読み込まれないストレージ アカウントを選択します。 Azure VM のバックアップと復元のベスト プラクティスを参照してください。

Azure Backup は、復旧ポイントから "アタッチ" ディスクを使用し、お使いのイメージ参照やギャラリーを参照しません。 そのため、ポリシー内で、"storageProfile.osDisk.createOption を Attach と して" 確認できます。スクリプトの条件は次のようになります。

if (storageProfile.osDisk.createOption == "Attach") then { exclude <Policy> }

電源を切った状態の VM を復元するには、VM を作成するか、ディスクを復元します。ただし、既存の VM を置き換えることはできません。 詳しくは、使用可能な復元オプションに関するページを参照してください。

復元中は、Azure VM の電源がオフ状態である必要があります。 そうしないと、エラー コード UserErrorVmNotShutDown を使用して、事前チェック ステージで復元操作が失敗します。

また、VM ディスクをスワップする前に、VM の電源をオフにする必要があります。

はい。復元をトリガーする既定の上限は、24 時間以内に VM ごとに 20 回の試行で、24 時間枠は UTC 00:00 にリセットされます。

アンマネージド VM の場合、VM ディスクの種類は Premium SSD または HDD であり、VHD が存在する SA によって異なります。 復元中に通常の SA を指定すると、VM ディスクは HDD になり、Premium SA を指定すると、すべてのディスクが Premium SSD になります。

はい。復元プロセスが完了したら、これらのファイルを削除できます。 既定では、Azure Backup は以降の使用のためにこれらのファイルを保持します。

暗号化されたキーは、リージョン間復元 (CRR) の一環でターゲット リージョンに配置されると想定されていません。 このため、復元されたファイルを使用して、暗号化されたキーとシークレットを復元する必要があります。 復元が完了したら、復元されたディスクを使用して Azure 暗号化 VM を作成できます。

Microsoft Windows では、最大 15 文字の VM 名を使用できます。 また、NETBIOS ホスト名と異なる DNS ホスト名は指定できません。 ただし、推奨に従った名前を使用して、Azure VM でホストされている Web サイトのホスト ヘッダーを作成できます。

Azure VM の VM 名前付け規則の制限について確認してください。

はい。クロス サブスクリプションの復元では、Azure ロールベースのアクセス制御 (Azure RBAC) 規則に従って、あるサブスクリプションの復旧ポイントからテナントの下の別のサブスクリプションに Azure VM を復元できるようになりました。 クロス サブスクリプションの復元は、スナップショットおよびとセカンダリ リージョンからの復元ではサポートされていません。

いいえ、暗号化された Azure VM ではサポートされていません。

いいえ。クロス サブスクリプションの復元は、スナップショットからの復元ではサポートされていません。

いいえ。クロス サブスクリプションの復元では、セカンダリ リージョンからの復元はサポートされていません。

はい。クロス サブスクリプションの復元でサポートされています。

はい。クロスゾーン復元では、Azure ロールベースのアクセス制御 (Azure RBAC) ルールに基づいて有効化されたゾーン冗長ストレージ (ZRS) を使用するコンテナー内の回復ポイントを使用して、Azure ゾーン固定 VM を使用可能な別のゾーンに復元できるようになりました。 これは、リージョンをまたがる復元 (CRR) を使用するコンテナーからもサポートされます。

はい。クロスゾーン復元では、Azure ロールベースのアクセス制御 (Azure RBAC) ルールに基づいて有効化されたゾーン冗長ストレージ (ZRS) を使用するコンテナー内の回復ポイントを使用して、Azure 非ゾーン固定 VM を使用可能なゾーンに復元できるようになりました。

いいえ、暗号化された Azure VM ではサポートされていません。

いいえ。クロスゾーン復元は、スナップショットからの復元ではサポートされません。

はい。Azure Backup では、Azure ゾーン固定 VM をセカンダリ リージョンに復元することがサポートされています。

はい。これは、クロスゾーン復元でサポートされています。

Azure portal からディスクのマウントを解除した後、clean パラメータ (python scriptName.py clean) を使用して Python スクリプトを実行してセッションをクリアし、復旧ポイントのマウント パスをマシンから削除します。

VM のバックアップは、変更されたポリシーのスケジュールおよびリテンション期間の設定を使用して実行されます。

• リテンション期間が延長された場合、既存の復旧ポイントは、新しいポリシーに従ってマーキングおよび保持されます。
• リテンション期間が短縮された場合、復旧ポイントは、次回のクリーンアップ ジョブで排除対象としてマーキングされて、その後削除されます。

ただし、復旧ポイントは保有期間の頻度に固有です。 たとえば、年に 1 回の保有ポリシーを追加または変更しても、月に 1 回の既存復旧ポイントの保有には影響しません。

1. バックアップを一時的に停止し、バックアップ データを保持します。

2. Azure Backup で構成された仮想マシンを移動するには、次の手順を実行します。

   1. 仮想マシンの場所を探します。
   2. 名前付けパターン AzureBackupRG_<location of your VM>_1 を持つリソース グループを探します。 たとえば、AzureBackupRG_westus2_1 となります
   3. Azure portal で、 [非表示の型の表示] をオンにします。
   4. AzureBackup_<name of your VM that you're trying to move>_########### という名前パターンを持つ、Microsoft.Compute/restorePointCollections 型のリソースを検索します。
   5. このリソースを削除します。 この操作では、インスタント復旧ポイントのみが削除され、コンテナー内のバックアップされたデータは削除されません。
   6. 削除操作が完了したら、仮想マシンを移動できます。

3. VM をターゲット リソース グループに移動します。

4. バックアップを再開します。

VM は、移動操作の前に作成された使用可能な復元ポイントから復元できます。

VM が別のリソース グループに移動されると、Azure Backup からは新しい VM であると認識されます。

VM を新しいリソース グループに移動した後は、その VM を同じコンテナーで、または別のコンテナーで再度保護することができます。 Azure Backup から見るとこれは新しい VM であるため、別個に課金されます。

古い VM の復元ポイントは、必要な場合は復元のために使用できるようになります。 このバックアップ データが不要な場合は、データの削除によって古い VM の保護を停止できます。

はい。同じバックアップ ポリシーに関連付けることができる VM は最大 100 個です。 VM が 100 個を上回る場合、同じスケジュールまたは異なるスケジュールで複数のバックアップ ポリシーを作成することをお勧めします。

コンテナー内の保護の構成と変更の全体的な上限は、1 日あたり 1000 です。

現在、保有期間の設定は、VM に割り当てられているバックアップ ポリシーに基づいて、バックアップ項目 (VM) レベルで表示できます。

バックアップの保有期間の設定を表示する方法の 1 つとして、Azure portal で VM のバックアップ項目のダッシュボードにアクセスする方法があります。 そのバックアップ ポリシーへのリンクを選択すると、その VM に関連付けられている日次、週次、月次、年次のすべての保有ポイントの保有期間を表示するのに役立ちます。

また、バックアップ エクスプローラーを使用して、すべての VM の保有期間の設定を 1 つのウィンドウに表示することもできます。 任意の Recovery Services コンテナーからバックアップ エクスプローラーに移動し、[バックアップ項目] タブに移動して [詳細ビュー] を選択することで、各 VM の詳細な保有期間の情報を確認します。

Azure VM バックアップでは、転送中の暗号化に HTTPS 通信を使用します。 データ転送では、VM のバックアップにインターネット アクセスを必要としない Azure ファブリック (パブリック エンドポイントではなく) を使用します。

この API では、Azure Backup からファイルを回復するために iSCSI 接続を呼び出すスクリプトをプロビジョニングします。

• このオプションは、API アクションを除外することにより、カスタム ロール定義を使用して無効にすることができます。
• プライベート エンドポイントを使用し、プライベート ネットワーク内から iSCSI サーバーへのアクセスを制限することもできます。
• また、拒否割り当て機能を使用して、このオプションを組織全体で無効にすることもできます。

ポリシーは、保持やスケジュールなどのパラメータの変更後、直ちに有効になります。 これは、変更したポリシーから作成されたすべての新しいバックアップに対して適用されます。 ただし、新しいポリシーに従って復旧ポイント (該当する場合) を排除するには、24 時間かかります。

この機能は、現時点ではサポートされていません。 Azure Backup コミュニティ ポータルで、任意の機能に関する質問を投稿できます。

停止したバックアップのリテンション期間は、ポリシーがアタッチされていないので変更できません。 ただし、保護を再開し、ポリシーを割り当てることができます。

停止したバックアップは、手動で削除されるまで保持されます。

セカンダリ リージョンでのサブスクリプションのアクセス許可を確認する必要があります。 サブスクリプションの登録については、AskAzureBackupTeam@microsoft.com にお問い合わせください。

このトラフィックは Azure リソースによって処理されるため、外部ユーザーが確認することはできません。

RPO: 標準ポリシーを使用している場合、最小 RPO は 1 日、すなわち 24 時間です。 拡張ポリシーを使用する場合、最小 RPO は 4 時間です。

このエラーは、Marketplace 以外のイメージから Azure VM を作成した後に VM を起動しようとした場合、または VM の OS ディスクを Marketplace 以外のイメージに入れ替えようとした場合に表示され、その後 VM のデプロイは失敗します。 この問題を解決するには、VM からプラン情報を削除します。

Azure Backup は、バックアップ中にキー バージョンのシークレットと KEK データをバックアップし、同じものを復元します。 ただし、古いバージョンのキーを使用して ADE VM を起動することもできます。

プライマリ リージョンの障害が発生する前に、セカンダリ リージョンに完全にレプリケートされたバックアップ データはそのまま残ります。 これは、プライマリ リージョンが障害から復旧した後も変わりません。 つまり、レプリケーション スケジュールに従って、障害が発生する前のデータを使用して、セカンダリ リージョンで仮想マシンを復旧できます。 セカンダリ リージョンの RPO は 36 時間であることに注意してください。つまり、データがプライマリリージョンからセカンダリ リージョンに完全にレプリケートされるまで約 36 時間かかります。

24 時間ごとのガベージ コレクター (GC) の実行時に復旧ポイントの有効期限が更新されます。 バックアップ ポリシーを更新すると、GC ジョブに遅延がない場合、有効期限に更新が表示されるまでに最大で 24 時間かかることがあります。

最新の復旧ポイントの有効期限は、新しいものが作成されるまで無限に保持されるため表示されません。 他の復旧ポイントの有効期限は、ガベージ コレクションが実行されるタイミングに応じて (24 時間以内)、作成の 24 時間後に Azure portal でわかるようになります。

いいえ。(元の場所または別の場所への) 復元操作は、スケジュールされたバックアップには影響しません。

• 元の場所に復元する: Azure Backup は既存の VM のディスクを復元ポイントにあるものと置き換えます。 このプロセスには、復元前に現在の VM のスナップショットを作成し、バックアップ スケジュールを維持することが含まれます。
• 別の場所に復元する: Azure Backup は復元ポイントを使用して新しい VM を作成します。 この新しい VM には、元の VM と同じバックアップ スケジュールは設定されていません。Backup ポリシーを手動で構成する必要があります。 「Azure VM の復元について」を参照してください。

これらの復元シナリオでは、元の VM の元のバックアップ ポリシーとスケジュールは影響を受けません。 ただし、(別の場所に) 復元された VM にバックアップ スケジュールを設定する場合は、Backup ポリシーを設定する必要があります。

Azure VM の元の場所への復元 (OLR) または別の場所への復元 (ALR) の場合、Azure Backup は次のようにバックアップ構成を実行します。

記憶域スペース ダイレクトは、2 つの異なる仮想マシンにデータが分散されるため、サポートされません。

アプリケーション整合性 VM バックアップでは、1 つの VM 内の記憶域スペースはサポートされません。 アプリケーション整合性 VM バックアップの場合、VSS は I/O をフリーズし、ディスク スナップショットの整合性を確保します。 記憶域スペースは引き続きバックグラウンドで書き込みを実行できるため、アプリケーション整合性の保証が損なわれます。 これにより、作成されたバックアップがアプリケーションと整合性がなくなる可能性がわずかながら生じます。 現在、記憶域スペースを使用した VM のバックアップと復旧は製品でブロックされていません。

ディスクを削除すると、削除されたディスクのスナップショットやデータ転送が実行されなくなります。 復元ポイントにあるディスクの数は、バックアップ時の VM の状態によって変わります。

ディスクの基になるストレージ アカウントが変更されない限り、ディスクのサイズ変更は増分バックアップで続行され、完全バックアップになります。

初期レプリカでは、バックアップが失敗した場合は完全バックアップが最初から実行されます。 ただし、増分では、最後に成功したバックアップからのスナップショットが最新のスナップショットと比較され、変更されたデータがコンテナーにコピーされます。