次の方法で共有

チュートリアル: Azure VM での SQL Server データベースのバックアップ

このチュートリアルでは、Azure Virtual Machine (VM) 上で稼働している SQL Server データベースを Azure Backup Recovery Services コンテナーにバックアップする方法について説明します。

前提条件

SQL Server データベースをバックアップする前に、次の条件を確認してください。

  1. SQL Server インスタンスをホストする VM として、同じリージョンまたはロケールの Recovery Services コンテナーを特定または作成する。
  2. SQL データベースをバックアップするのに必要な VM のアクセス許可をチェックする。
  3. VM がネットワーク接続を備えていることを確認する。
  4. Azure Backup の命名ガイドラインに従って SQL Server データベースが名付けられていることをチェックする。
  5. データベースに対して有効になっているバックアップ ソリューションが他にないことを確認する。 このシナリオを設定する前に、他のすべての SQL Server バックアップを無効にします。 競合が発生することなく、VM 上で稼働している SQL Server データベースに対して Azure Backup を有効にするのと同時に、Azure VM に対して Azure Backup を有効にできます。

Recovery Services コンテナーを作成する

Recovery Services コンテナーは、経時的に作成された復旧ポイントを保存する管理エンティティです。 バックアップ関連の操作を実行するためのインターフェイスを提供します。 たとえば、オンデマンドのバックアップの作成、復元の実行、バックアップ ポリシーの作成などの操作です。

Recovery Services コンテナーを作成するには、次の手順に従います。

  1. Azure portal にサインインします。

  2. 回復性を検索し、回復性ダッシュボードに移動します。

    回復性を検索して選択する場所を示すスクリーンショット。

  3. [ ボールト ] ウィンドウで、[ + ボールト] を選択します。

    Recovery Services コンテナーの作成を開始する方法を示すスクリーンショット。

  4. [Recovery Services コンテナー]>[続行] の順に選択します。

    コンテナーの種類として Recovery Services を選択する場所を示すスクリーンショット。

  5. [Recovery Services コンテナー] ペインで、次の値を入力します。

    • [サブスクリプション]: 使用するサブスクリプションを選択します。 1 つのサブスクリプションのみのメンバーである場合は、その名前が表示されます。 どのサブスクリプションを使用すればよいかわからない場合は、既定のサブスクリプションを使用してください。 職場または学校アカウントが複数の Azure サブスクリプションに関連付けられている場合にのみ、複数の選択肢が表示されます。

    • [リソース グループ]: 既存のリソース グループを使用するか、新しいリソース グループを作成します。 サブスクリプションで使用可能なリソース グループの一覧を表示するには、[ 既存のものを使用] を選択します。 次に、ドロップダウン リストでリソースを選択します。 新しいリソース グループを作成するには、[新規作成] を選択し、名前を入力します。 リソース グループの詳細については、「Azure Resource Manager の概要」を参照してください。

    • [コンテナー名]: コンテナーを識別するフレンドリ名を入力します。 名前は Azure サブスクリプションに対して一意である必要があります。 2 文字以上で、50 文字以下の名前を指定します。 名前の先頭にはアルファベットを使用する必要があります。また、名前に使用できるのはアルファベット、数字、ハイフンのみです。

    • [リージョン]: コンテナーの地理的リージョンを選択します。 データ ソースを保護するためのコンテナーを作成するには、コンテナーがデータ ソースと同じリージョン内にある "必要があります"。

      重要

      データ ソースの場所が不明な場合は、ウィンドウを閉じます。 ポータルの自分のリソースの一覧に移動します。 複数のリージョンにデータ ソースがある場合は、リージョンごとに Recovery Services コンテナーを作成します。 最初の場所にコンテナーを作成してから、別の場所にコンテナーを作成してください。 バックアップ データを格納するためにストレージ アカウントを指定する必要はありません。 Recovery Services コンテナーと Azure Backup は、その手順を自動的に処理します。

      Recovery Services コンテナーを構成するためのフィールドを示すスクリーンショット。

  6. 値を指定したら、[ 確認と作成] を選択します。

  7. Recovery Services コンテナーの作成を完了するには、[作成] を選択します。

    Recovery Services コンテナーの作成に時間がかかることがあります。 右上の [通知] 領域で、状態の通知を監視します。 作成されたコンテナーは、Recovery Services コンテナーのリストに表示されます。 コンテナーが表示されない場合は、[最新の情報に更新] を選択します。

    バックアップ コンテナーの一覧を更新するボタンを示しているスクリーンショット。

Azure Backup では、復旧ポイントが作成された後、バックアップ ポリシーに従って有効期限が切れる前に削除できないようにするために役立つ不変コンテナーがサポートされるようになりました。 ランサムウェア攻撃や悪意のあるアクターなど、さまざまな脅威からバックアップ データを保護するために、最大限の保護のために不変性を元に戻すことができないようにすることができます。 Azure Backup 不変コンテナーの詳細を確認します。

SQL Server データベースを検出する

VM で実行されているデータベースを検出するには、次の手順に従います。

  1. Azure portal で、[回復性] に移動し、[+ 保護の構成] に移動します。

  2. [保護の構成] ウィンドウで、データソースの種類として[Azure VM 内の SQL] を選択し、[続行] を選択します。

    バックアップのデータソースとして SQL データベースを選択する方法を示すスクリーンショット。

  3. [ スタート: バックアップの構成 ] ウィンドウの [ コンテナー] で、[ コンテナーの選択] をクリックします。

  4. [ コンテナーの選択 ] ウィンドウで、データベースをバックアップする一覧から作成した Recovery Services コンテナーを選択し、[ 選択] をクリックします。

  5. [スタート: バックアップの構成] ウィンドウで、[続行] を選択します。

  6. [ バックアップの目標 ] ウィンドウ の [VM 内の DB の検出] で、[ 検出の開始 ] を選択して、サブスクリプション内の保護されていない VM を検索します。 サブスクリプション内にある保護されていない VM の数によっては、この検索に少し時間がかかる場合があります。

  7. [ 仮想マシンの選択 ] ウィンドウで、SQL Server データベースを実行している VM を選択し、[ DB の検出] を選択します。

    保護されていない SQL データベースを実行している VM の一覧を示すスクリーンショット。

    Note

    • 保護されていない VM は検出後、名前およびリソース グループ別に一覧に表示されます。
    • VM が予想どおりに一覧表示されない場合、それが既にコンテナーにバックアップされていないかを確認してください。
    • 名前の同じ複数の VM が、異なるリソース グループに含まれる可能性があります。

[通知] でデータベースの検出を追跡できます。 この操作に必要な時間は、VM のデータベースの数によって異なります。 選択したデータベースが検出されたら、成功のメッセージが表示されます。

スクリーンショットは、デプロイの成功メッセージを示しています。

Azure Backup によって、VM 上のすべての SQL Server データベースが検出されます。 検出中、バックグラウンドで以下の要素が発生します。

  • Azure Backup によって、ワークロード バックアップ用のコンテナーに VM が登録されます。 登録された VM 上のすべてのデータベースは、このコンテナーのみに対してバックアップできます。

  • Azure Backup によって、AzureBackupWindowsWorkload 拡張機能が VM にインストールされます。 SQL データベースにエージェントがインストールされていません。

  • Azure Backup によって、サービス アカウント NT Service\AzureWLBackupPluginSvc が VM 上に作成されます。

    • すべてのバックアップおよび復元操作に、サービス アカウントを使用します。
    • NT Service\AzureWLBackupPluginSvc には、SQL sysadmin 権限が必要です。 Marketplace で作成されたすべての SQL Server VM には、SqlIaaSExtension が元からインストールされています。 AzureBackupWindowsWorkload 拡張機能は SQLIaaSExtension を使用して自動的に必要な権限を取得します。

  • Marketplace から VM を作成しなかった場合、または SQL 2008 および 2008 R2 を使用している場合、VM に SqlIaaSExtension がインストールされていない可能性があり、UserErrorSQLNoSysAdminMembership というエラー メッセージで検出操作が失敗します。 この問題を修正するには、「VM のアクセス許可を設定する」の手順に従います。

    VM とデータベースを選択する

バックアップの構成

SQL データベースのバックアップを構成するには、次の手順に従います。

  1. [ バックアップの目標 ] ウィンドウの [ 手順 2: バックアップの構成] で、[ バックアップの構成] を選択します。

    [バックアップの構成] の選択を示すスクリーンショット。

  2. 登録されている可用性グループおよびスタンドアロン SQL Server インスタンスをすべて表示するには、[リソースの追加] を選択します。

    [リソースの追加] の選択

  3. [バックアップする項目を選択] 画面で、行の左側にある矢印を選択して、そのインスタンスまたは Always On 可用性グループ内の保護されていないデータベースの全一覧を展開します。

    バックアップする項目を選択

  4. 保護したいデータベースをすべて選択してから、[OK] を選択します。

    データベースの保護

    バックアップの負荷を最適化するために、Azure Backup では、1 つのバックアップ ジョブにおけるデータベースの最大数が 50 個に設定されています。

    • 50 個を超えるデータベースを保護するには、複数のバックアップを構成します。

    • インスタンス全体または AlwaysOn 可用性グループを有効にするには、[AUTOPROTECT]\(自動保護\) ドロップダウン リストで [オン] を選択し、[OK] を選択します。

      Note

      自動保護機能では、既存のすべてのデータベースの保護が一度に有効になるだけでなく、そのインスタンスまたは可用性グループに追加されたすべての新しいデータベースも自動的に保護されます。

  5. [バックアップ ポリシー] を定義します。 次のいずれかの手順を行います。

    • 既定のポリシーを HourlyLogBackup として選択します。

    • SQL 用に以前に作成された既存のバックアップ ポリシーを選択する。

    • RPO とリテンション期間の範囲に基づいて新しいポリシーを定義する。

      [バックアップ ポリシー] を選択する

  6. [バックアップの有効化] を選択して、[保護を構成] 操作を送信し、ポータルの [通知] 領域で構成の進行状況を追跡します。

    構成の進行状況の追跡

バックアップ ポリシーの作成

バックアップ ポリシーでは、バックアップが取得されるタイミングと、それらが保持される期間を定義します。

  • ポリシーはコンテナー レベルで作成されます。
  • 複数のコンテナーでは同じバックアップ ポリシーを使用できますが、各コンテナーにバックアップ ポリシーを適用する必要があります。
  • バックアップ ポリシーの作成時には、日次での完全バックアップが既定値になっています。
  • 差分バックアップを追加することは可能ですが、週次で実行するように完全バックアップを構成する場合だけです。
  • さまざまな種類のバックアップ ポリシーについて学習してください。

バックアップ ポリシーを作成するには:

  1. [回復性] に移動し、[管理>保護ポリシー>+ ポリシーの作成>バックアップ ポリシーの作成を選択します。

  2. [スタート: ポリシーの作成] ウィンドウで、データソースの種類として Azure VM の SQL Server を選択し、ポリシーを作成するコンテナーを選択して、[続行] を選択します。

    スクリーンショットは、新しいバックアップ ポリシーのポリシーの種類を選択する方法を示しています。

  3. [ ポリシーの作成 ] ウィンドウの [ ポリシー名] に、新しいポリシーの名前を入力します。

    ポリシー名を入力する方法を示すスクリーンショット。

  4. 既定のバックアップ頻度設定を変更するには、[完全バックアップ] に対応する [編集] リンクを選択します。

  5. [ 完全バックアップ ポリシー ] ウィンドウで、次のバックアップ スケジュール設定を構成します。

    • [バックアップ頻度] を選択します。 [毎日] または [毎週] を選択します。
    • [毎日] を選択する場合は、バックアップ ジョブが開始されるときに、時刻とタイム ゾーンを選択します。 日次の完全バックアップを選択する場合は、差分バックアップを作成できません。

    新しいバックアップ ポリシーのフィールドを示すスクリーンショット。

  6. [ 保持範囲] では、すべてのオプションが既定で選択されます。 使用しないリテンション期間の制限を解除してから、使用する間隔を設定します。

    • バックアップのすべての種類 (完全、差分、ログ) の最小リテンション期間は 7 日間です。
    • 復旧ポイントは、そのリテンション期間の範囲に基づいて、リテンション期間に対してタグ付けされます。 たとえば、毎日の完全バックアップを選択すると、毎日 1 つの完全バックアップのみがトリガーされます。
    • 特定の曜日のバックアップがタグ付けされ、週次でのリテンション期間の範囲と週次でのリテンション期間の設定に基づいて保持されます。
    • 月次および年次のリテンション期間の範囲でも、同様の動作になります。

    保持範囲の間隔の設定を示すスクリーンショット。

  7. [OK] を選択して、完全バックアップの設定を受け入れます。

  8. [ポリシーの作成] ウィンドウで、既定の設定を変更するには、[差分バックアップ] に対応する [編集] リンクを選択します。

  9. [ 差分バックアップ ポリシー ] ウィンドウで、次の設定を構成します。

    • 差分 バックアップ ポリシーで、Enable を選択して頻度と保持の制御を開きます。
    • 差分バックアップは 1 日に 1 回のみトリガーできます。 完全バックアップと同じ日に差分バックアップをトリガーすることはできません。
    • 差分バックアップは、最大 180 日間保持できます。
    • 差分バックアップの保有期間は、完全バックアップの保有期間よりも長くすることはできません (差分バックアップは復旧時に完全バックアップに依存しているため)。
    • マスター データベースでは、差分バックアップはサポートされていません。

    差分バックアップ ポリシーを示すスクリーンショット。

  10. [ポリシーの作成] ウィンドウで、既定の設定を変更するには、[ログ バックアップに対応する編集] リンクを選択します。

  11. [ ログ バックアップ ポリシー ] ウィンドウで、次の設定を構成します。

    • ログ バックアップで、[有効] を選択し、頻度と保持の制御を設定します。
    • ログ バックアップは、15 分ごとの頻度で実行でき、最大 35 日間保持することが可能です。
    • データベースが単純復旧モデルである場合、そのデータベースのログ バックアップ スケジュールは一時停止されるため、ログ バックアップはトリガーされません。
    • データベースの復旧モデルが [完全] から [単純] に変更された場合、復旧モデルが変更されてから 24 時間以内にログ バックアップが一時停止されます。 同様に、復旧モデルが [単純] から変更された場合、データベースでログ バックアップがサポートされるようになったので、復旧モデルの変更から 24 時間以内にログ バックアップ スケジュールが有効になります。

    ログ バックアップ ポリシーを示すスクリーンショット。

  12. [バックアップ ポリシー] メニューで、[SQL バックアップの圧縮] を有効にするかどうかを選択します。 既定では、このオプションは無効になっています。 有効にすると、圧縮されたバックアップストリームが SQL Server によって VDI に送信されます。 Azure Backup は、このコントロールの値に応じて、COMPRESSION / NO_COMPRESSION 句を使用して、インスタンス レベルの既定値をオーバーライドします。

  13. バックアップ ポリシーに対する編集が完了したら、[OK] を選択します。

Note

各ログ バックアップは、復旧チェーンを形成するために、以前の完全バックアップにチェーンされています。 この完全バックアップは、前回のログ バックアップのリテンション期間が終了するまで保持されます。 これは、完全バックアップのリテンション期間を追加して、すべてのログが確実に復旧されるようにすることを意味します。 週単位で完全バックアップ、日単位で差分バックアップ、2 時間ごとのログ バックアップを実行していると仮定します。 これらのすべてが 30 日間保持されます。 ただし、週単位の完全バックアップは、次の完全バックアップが利用可能になった後でのみ、すなわち 30 + 7 日後に、実際にクリーンアップまたは削除することができます。 たとえば、週単位の完全バックアップが 11 月 16 日に行われたとします。 保持ポリシーに従って、12 月 16 日まで保持されます。 この完全バックアップに対する最後のログ バックアップは、11 月 22 日に予定されている次回の完全バックアップの前に実行されます。 このログが 12 月 22 日までに利用可能になるまでは、11 月 16 日の完全バックアップは削除されません。 そのため、11 月 16 日の完全は、12 月 22 日まで保持されます。

オンデマンド バックアップを実行する

  1. Recovery Services コンテナーで、[バックアップ アイテム] を選択します。
  2. [SQL in Azure VM]\(Azure VM 内の SQL\) を選択します。
  3. データベースを右クリックし、[今すぐバックアップ] を選択します。
  4. バックアップの種類 (完全、差分、ログ、コピーのみの完全) と圧縮 (有効または無効) を選びます。
    • On-demand full では、バックアップが最短で "45 日間"、最大で "99 年間" 保持されます。
    • On-demand copy only full では、保持するすべての値を受け入れます。
    • On-demand differential では、ポリシーに設定されているスケジュールされた差分の保持に従ってバックアップが保持されます。
    • On-demand log では、ポリシーに設定されているスケジュールされたログの保持に従ってバックアップが保持されます。
  5. [OK] を選択して、バックアップを開始します。
  6. Recovery Services コンテナーに移動し、[バックアップ ジョブ] を選択して、バックアップ ジョブを監視します。

次のステップ

このチュートリアルでは、Azure portal を使用して以下を行いました。

  • コンテナーの作成と構成。
  • データベースの検出とバックアップの設定。
  • データベースに対する自動保護の設定。
  • オンデマンド バックアップを実行します。

ディスクから Azure 仮想マシンを復元するには、次のチュートリアルに進みます。

Azure VM 上の SQL Server データベースを復元する

  • Last updated on