Azure VM バックアップ上で実行されている SQL Server データベースに関する FAQ

  • よく寄せられる質問

この記事では、Azure 仮想マシン (VM) 上で実行され、Azure Backup サービスを使用する SQL Server データベースのバックアップに関する一般的な質問にお答えします。

Backup

IaaS VM 用の Azure Backup と SQL Server を同じマシン上で使用できますか?

はい、同じ VM上で VM のバックアップと SQL のバックアップを共存させることができます。 この場合はログを切り詰めないようにするため、VM 上でコピーのみの完全バックアップを内部でトリガーします。

このソリューションではバックアップは再試行または自動回復されますか?

状況によっては、Azure Backup サービスが修復バックアップをトリガーします。 自動回復は、次の 6 つの条件のいずれに対しても実行されます。

  • ログまたは差分バックアップが LSN 検証エラーのために失敗した場合は、代わりに次のログまたは差分バックアップが完全バックアップに変換されます。
  • ログまたは差分バックアップの前に完全バックアップが実行されていない場合は、代わりにそのログまたは差分バックアップが完全バックアップに変換されます。
  • 最新の完全バックアップの特定の時点が 15 日より前の場合は、代わりに次のログまたは差分バックアップが完全バックアップに変換されます。
  • 拡張機能のアップグレードのために取り消されたバックアップ ジョブはすべて、アップグレードが完了して拡張機能が開始された後で再トリガーされます。
  • 復元中にデータベースを上書きすることを選択した場合は、次のログ/差分バックアップが失敗し、代わりに完全バックアップがトリガーされます。
  • データベース復旧モデルの変更のために、完全バックアップでログ チェーンをリセットする必要がある場合は、次のスケジュールで完全バックアップが自動的にトリガーされます。

自動修復バックアップ ジョブはキャンセルできますか?

いいえ。自動修復ジョブをキャンセルすることはできません。 ただし、これらの手順に従ってオプトアウトできます。

  1. SQL Server インスタンスで、C:\Program Files\Azure Workload Backup\bin フォルダーで ExtensionSettingsOverrides.json ファイルを作成または編集します。
  2. ExtensionSettingsOverrides.json ファイルで、{"EnableAutoHealer": false} を設定します。
  3. 変更を保存してファイルを閉じます。
  4. SQL Server インスタンスで、タスク マネージャーを開き、AzureWLBackupCoordinatorSvc サービスを再起動します。

SQL サーバー上で実行される同時実行バックアップの数を制御できますか?

はい。 バックアップ ポリシーが実行される速度を調整して、SQL Server インスタンスへの影響を最小限に抑えることができます。 設定を変更するには:

  1. SQL Server インスタンスで、C:\Program Files\Azure Workload Backup\bin フォルダーに ExtensionSettingsOverrides.json ファイルを作成します。

  2. ExtensionSettingsOverrides.json ファイルで、DefaultBackupTasksThreshold の設定をもっと小さい値 (たとえば、5) に変更します。
    {"DefaultBackupTasksThreshold": 5}
    DefaultBackupTasksThreshold の既定値は 20 です。

  3. 変更を保存し、ファイルを閉じます。

  4. SQL Server インスタンスで、タスク マネージャーを開きます。 AzureWLBackupCoordinatorSvc サービスを再起動します。

    バックアップ アプリケーションで多くのリソース量を消費している場合はこの方法が役立つ一方で、SQL Server の Resource Governor では、受信するアプリケーション要求で使用できる CPU、物理 IO、およびメモリの量に対して、より汎用的なやり方で制限を指定できます。

注意

UX では、いつでも、引き続き先に進みいくつでもバックアップをスケジュールできます。 ただし、それらは上の例に従った値 (たとえば、5) のスライディング ウィンドウで処理されます。

成功したバックアップ ジョブでアラートが作成されますか?

いいえ。 成功したバックアップ ジョブではアラートは生成されません。 アラートは、失敗したバックアップ ジョブに対してのみ送信されます。 ポータル アラートの詳細な動作はここに記載されています。 ただし、成功したジョブに対してもアラートを生成することに関心がある場合は、Azure Monitor を使用した監視を使用できます。

今後作成されるデータベースはバックアップに自動的に追加されますか?

はい。この機能は、自動保護で実現できます。

自動保護されたインスタンスからデータベースを削除した場合、バックアップはどうなりますか?

自動保護されたインスタンスからデータベースが削除された場合でも、データベース バックアップは引き続き試行されます。 これは、削除されたデータベースが [バックアップ項目] に異常として表示され始め、引き続き保護されていることを示しています。

このデータベースの保護を停止するための正しい方法は、このデータベースに対してデータを削除した [バックアップの停止] を実行することです。

Azure Disk Encryption (ADE) が有効になっている仮想マシン上のデータベースを保護できますか?

はい、Azure Disk Encryption (ADE) が有効になっている仮想マシン上のデータベースを保護できます。

TDE (Transparent Data Encryption) が有効になっているデータベースを保護し、バックアップ プロセス全体を通してデータベースを暗号化したままにすることはできますか?

はい、Azure Backup では、TDE が有効になった SQL Server データベースまたはサーバーのバックアップがサポートされます。 キーが Azure によって管理される TDE と、キーがユーザーによって管理される (BYOK) TDE がサポートされます。 バックアップでは、バックアップ プロセスの一環として SQL 暗号化は実行されないため、バックアップ時にデータベースが暗号化されたままになります。

Azure Backup では、データ ストリームに対してチェックサム操作が実行されますか?

データ ストリームに対してチェックサム操作は実行されます。 ただし、これを SQL チェックサムと混同しないようにしてください。 Azure ワークロード バックアップでは、データ ストリームに対してチェックサムが計算され、バックアップ操作中に明示的に格納されます。 次に、このチェックサム ストリームが参照として取得され、データの整合性を確保するために復元操作中にデータ ストリームのチェックサムとクロス検証されます。

SQL マシン用の Azure Site Recovery と Azure SQL データベースのバックアップを同じマシンで使用できますか?

はい。 Azure Site Recovery は、"コピーのみの完全バックアップ" をトリガーしますが、ログが切り捨てられないように VM で "アプリケーション整合性スナップショット" を作成します。 詳細情報。

管理

スケジュールされたバックアップ ジョブを [バックアップ ジョブ] メニューで確認できますか?

[バックアップ ジョブ] メニューには、ごく頻繁に実行される可能性があるスケジュールされたログのバックアップを除き、すべてのスケジュール済みおよびオンデマンドの操作が表示されます。 スケジュールされたログ ジョブの場合は、Azure Monitor を使用した監視を使用してください。

自動保護されたデータベースのバックアップ操作の停止を実行した場合、その動作はどうなりますか?

データを保持したバックアップの停止を実行した場合、将来のバックアップは実行されず、既存の復旧ポイントはそのまま残ります。 そのデータベースは引き続き保護されていると見なされ、 [バックアップ項目] に表示されます。

データを削除したバックアップの停止を実行した場合、将来のバックアップは実行されず、既存の復旧ポイントも削除されます。 そのデータベースは保護されていないものと見なされ、[バックアップの構成] ブレードでインスタンスの下に表示されます。 ただし、手動で選択したり、自動保護したりできる他の保護されていないデータベースとは異なり、このデータベースは灰色表示され、選択できません。 このデータベースを再保護するための唯一の方法は、そのインスタンスに対する自動保護を無効にすることです。 これでこのデータベースを選択できるようになり、それに対する保護を構成するか、またはそのインスタンスに対する自動保護を再び有効にします。

データベースが保護された後でその名前を変更すると、どうなりますか?

名前が変更されたデータベースは、新しいデータベースとして処理されます。 このため、サービスはこの状況を、データベースが見つからず、バックアップが失敗したかのように処理します。

名前が変更されているデータベースを選択し、それに対する保護を構成できます。 そのインスタンスに対して自動保護が有効になっている場合は、名前が変更されたデータベースが自動的に検出されて保護されます。

自動保護されたインスタンスの追加されたデータベースが表示されないのはなぜですか?

自動保護されたインスタンスに追加したデータベースは、保護された項目にすぐには表示されない可能性があります。 これは、検出は通常 8 時間ごとに実行され、システムの実際の保護は VM のサイズによって異なるため、さらに時間がかかることがあるためです。 ただし、次の図に示すように、[DB の再検出] を選択することによって検出を手動で実行した場合は、新しいデータベースを直ちに検出できます。

新しく追加されたデータベースの手動検出のスクリーンショット。

復元

復元中にファイルのサブセットのみをファイルとしてダウンロードできますか?

はい。ここに記載されているように、部分的にファイルをダウンロードできます。

ファイルとして復元中に未登録にファイルにダウンロードできますか?

はい。ファイルをダウンロードするには、登録済み VM 内のファイル パスが必要です。 そのパスはネットワーク共有であってもかまいません。 未登録の VM から登録済み VM へのネットワーク共有を構成してから、登録済み VM をターゲットとして選択し、ネットワーク共有をターゲット ファイル パスとして選択します。 ファイルがダウンロードされたら、登録済み VM からネットワーク共有をマウント解除するだけで、未登録の VM でファイルを使用できるようになります。

ExpressRoute と構成された強制トンネリングを使用して Azure 環境をオンプレミス ネットワークに接続すると、すべてのトラフィックがオンプレミス ネットワークに送信されます。 Azure SQL Server ワークロードのバックアップ トラフィックがオンプレミス ネットワークを通過して Recovery Services コンテナーに直接接続することがないように設定を構成するにはどうすればよいですか?

バックアップ操作中、"バックアップ ジョブ" は、3 つのサービス エンドポイント (AzureBackup、AzureStorage、Microsoft Entra ID. In this scenario, we recommend you to configure the Service Endpoint to ) に接続します。このシナリオでは、サービス エンドポイントを `AzureStorage` に構成することをお勧めします。これは、Virtual Network から Storage に直接トラフィックを送信するのに便利です。 Azure Backup と Microsoft Entra ID の場合、トラフィックがオンプレミスではなくバックボーン ネットワークに送信されるように、サービス タグに UDR を構成できます。

次のステップ

Azure VM 上で実行されているSQL Server データベースをバックアップする方法を学習します。