Azure VM での SQL Server データベースのバックアップ
このチュートリアルでは、Azure VM 上で稼働している SQL Server データベースを Azure Backup Recovery Services コンテナーにバックアップする方法について説明します。 この記事では、次のことについて説明します。
- コンテナーの作成と構成。
- データベースの検出とバックアップの設定。
- データベースに対する自動保護の設定。
- オンデマンド バックアップを実行します。
前提条件
SQL Server データベースをバックアップする前に、次の条件を確認してください。
- SQL Server インスタンスをホストする VM として、同じリージョンまたはロケールの Recovery Services コンテナーを特定または作成する。
- SQL データベースをバックアップするのに必要な VM のアクセス許可をチェックする。
- VM がネットワーク接続を備えていることを確認する。
- Azure Backup の命名ガイドラインに従って SQL Server データベースが名付けられていることをチェックする。
- データベースに対して有効になっているバックアップ ソリューションが他にないことを確認する。 このシナリオを設定する前に、他のすべての SQL Server バックアップを無効にします。 競合が発生することなく、VM 上で稼働している SQL Server データベースに対して Azure Backup を有効にするのと同時に、Azure VM に対して Azure Backup を有効にできます。
Recovery Services コンテナーを作成する
Recovery Services コンテナーは、時間の経過と共に作成される復旧ポイントを格納する管理エンティティであり、バックアップ関連の操作を実行するためのインターフェイスが用意されています。 たとえば、オンデマンドのバックアップの作成、復元の実行、バックアップ ポリシーの作成などの操作です。
Recovery Services コンテナーを作成するには、次の手順に従います。
Azure portal にサインインします。
ビジネス継続性センターを検索し、ビジネス継続性センター ダッシュボードに移動します。
[コンテナー] ペインで、[+コンテナー] を選択します。
[Recovery Services コンテナー]>[続行] の順に選択します。
[Recovery Services コンテナー] ペインで、次の値を入力します。
[サブスクリプション] : 使用するサブスクリプションを選択します。 1 つのサブスクリプションのみのメンバーの場合は、その名前が表示されます。 どのサブスクリプションを使用すればよいかがわからない場合は、既定のサブスクリプションを使用してください。 職場または学校アカウントが複数の Azure サブスクリプションに関連付けられている場合に限り、複数の選択肢が存在します。
[リソース グループ] :既存のリソース グループを使用するか、新しいリソース グループを作成します。 サブスクリプションの使用可能なリソース グループの一覧を表示するには、[既存のものを使用] を選択してから、ドロップダウン リストでリソースを選択します。 新しいリソース グループを作成するには、[新規作成] を選択し、名前を入力します。 リソース グループの詳細については、「Azure Resource Manager の概要」を参照してください。
[コンテナー名]: コンテナーを識別するフレンドリ名を入力します。 名前は Azure サブスクリプションに対して一意である必要があります。 2 文字以上で、50 文字以下の名前を指定します。 名前の先頭にはアルファベットを使用する必要があります。また、名前に使用できるのはアルファベット、数字、ハイフンのみです。
[リージョン]: コンテナーの地理的リージョンを選択します。 データ ソースを保護するためのコンテナーを作成するには、コンテナーがデータ ソースと同じリージョン内にある "必要があります"。
重要
データ ソースの場所が不明な場合は、ウィンドウを閉じます。 ポータルの自分のリソースの一覧に移動します。 複数のリージョンにデータ ソースがある場合は、リージョンごとに Recovery Services コンテナーを作成します。 最初の場所にコンテナーを作成してから、別の場所にコンテナーを作成します。 バックアップ データを格納するためにストレージ アカウントを指定する必要はありません。 Recovery Services コンテナーと Azure Backup で自動的に処理されます。
値を指定したら、 [確認と作成] を選択します。
Recovery Services コンテナーの作成を完了するには、[作成] を選択します。
Recovery Services コンテナーの作成に時間がかかることがあります。 右上の [通知] 領域で、状態の通知を監視します。 作成されたコンテナーは、Recovery Services コンテナーのリストに表示されます。 コンテナーが表示されない場合は、[最新の情報に更新] を選択します。
注意
Azure Backup は、作成された復旧ポイントがバックアップ ポリシーに従って、有効期限切れ前に削除されないようにできる不変コンテナーをサポートするようになりました。 また、不変性を元に戻せないようにして、ランサムウェア攻撃や悪意のあるアクターなど、さまざまな脅威からバックアップ データを最大限に保護することができます。 詳細については、こちらを参照してください。
SQL Server データベースを検出する
VM 上で稼働しているデータベースを検出します。
Azure portal で、 [バックアップ センター] に移動し、 [バックアップ] をクリックします。
[データソースの種類] として [Azure VM の SQL] を選択し、作成した Recovery Services コンテナーを選択して、 [続行] をクリックします。
![[バックアップ] を選択して VM で実行されているデータベースを表示することを示すスクリーンショット。](media/backup-azure-sql-database/configure-sql-backup.png)
[バックアップの目標]>[VM 内のデータベースを検出] で、 [検出の開始] を選択して、サブスクリプション内にある保護されていない VM を検索します。 サブスクリプション内にある保護されていない仮想マシンの数によっては、少し時間がかかる場合があります。
保護されていない VM は検出後、名前およびリソース グループ別に一覧に表示されます。
VM が予想どおりに一覧表示されない場合、それが既にコンテナーにバックアップされていないかをチェックしてください。
名前の同じ複数の VM が、異なるリソース グループに含まれる可能性があります。
VM の一覧で、SQL Server データベースを稼働している VM を選択し、>[DB の検出] を選択します。
[通知] 領域でデータベース検出を追跡します。 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 権限が必要です。 Azure Marketplace で作成されたすべての SQL Server VM には、SqlIaaSExtension が元からインストールされています。 AzureBackupWindowsWorkload 拡張機能は SQLIaaSExtension を使用して自動的に必要な権限を取得します。
VM をマーケットプレースから作成しなかった場合、VM には SqlIaaSExtension がインストールされておらず、検出操作はエラー メッセージ UserErrorSQLNoSysAdminMembership と共に失敗します。 手順に従ってこの問題を修正します。
バックアップの構成
次のようにバックアップを構成します。
[バックアップの目標]>[手順 2: バックアップの構成] で、 [バックアップの構成] を選択します。
![[バックアップの構成] を選択する](media/backup-azure-sql-database/backup-goal-configure-backup.png)
登録されている可用性グループおよびスタンドアロン SQL Server インスタンスをすべて表示するには、 [リソースの追加] を選択します。
![[リソースの追加] の選択](media/backup-azure-sql-database/add-resources.png)
[バックアップする項目を選択] 画面で、行の左側にある矢印を選択して、そのインスタンスまたは Always On 可用性グループ内の保護されていないデータベースの全一覧を展開します。
保護したいデータベースをすべて選択してから、 [OK] を選択します。
バックアップの負荷を最適化するために、Azure Backup では、1 つのバックアップ ジョブにおけるデータベースの最大数が 50 個に設定されています。
[バックアップ ポリシー] を定義します。 次のいずれかの手順を行います。
既定のポリシーを HourlyLogBackup として選択します。
SQL 用に以前に作成された既存のバックアップ ポリシーを選択する。
RPO とリテンション期間の範囲に基づいて新しいポリシーを定義する。
![[バックアップ ポリシー] を選択する](media/backup-azure-sql-database/select-backup-policy.png)
[バックアップの有効化] を選択して、 [保護を構成] 操作を送信し、ポータルの [通知] 領域で構成の進行状況を追跡します。
バックアップ ポリシーの作成
バックアップ ポリシーでは、バックアップが取得されるタイミングと、それらが保持される期間を定義します。
- ポリシーはコンテナー レベルで作成されます。
- 複数のコンテナーでは同じバックアップ ポリシーを使用できますが、各コンテナーにバックアップ ポリシーを適用する必要があります。
- バックアップ ポリシーの作成時には、日次での完全バックアップが既定値になっています。
- 差分バックアップを追加することは可能ですが、週次で実行するように完全バックアップを構成する場合だけです。
- さまざまな種類のバックアップ ポリシーについて学習してください。
バックアップ ポリシーを作成するには:
[バックアップ センター] に移動し、 [ポリシー] をクリックします。
[データソースの種類] として [Azure VM の SQL Server] を選択し、ポリシーを作成するコンテナーを選択して、 [続行] をクリックします。
[ポリシー名] に新しいポリシーの名前を入力します。
既定の設定を変更するには、 [完全バックアップ] に対応する [編集] リンクを選択します。
- [バックアップ頻度] を選択します。 [毎日] または [毎週] を選択します。
- [毎日] を選択する場合は、バックアップ ジョブが開始されるときに、時刻とタイム ゾーンを選択します。 日次の完全バックアップを選択する場合は、差分バックアップを作成できません。
[リテンション期間] では、すべてのオプションが既定で選択されています。 使用しないリテンション期間の制限を解除してから、使用する間隔を設定します。
- バックアップのすべての種類 (完全、差分、ログ) の最小リテンション期間は 7 日間です。
- 復旧ポイントは、そのリテンション期間の範囲に基づいて、リテンション期間に対してタグ付けされます。 たとえば、日次での完全バックアップを選択した場合、日ごとにトリガーされる完全バックアップは 1 回だけです。
- 特定の曜日のバックアップがタグ付けされ、週次でのリテンション期間の範囲と週次でのリテンション期間の設定に基づいて保持されます。
- 月次および年次のリテンション期間の範囲でも、同様の動作になります。
[OK] を選択して、完全バックアップの設定を受け入れます。
既定の設定を変更するには、 [差分バックアップ] に対応する [編集] リンクを選択します。
- 差分バックアップのポリシーで、 [有効] を選択して頻度とリテンション期間の制御を開きます。
- 差分バックアップは 1 日に 1 回のみトリガーできます。 完全バックアップと同じ日に差分バックアップをトリガーすることはできません。
- 差分バックアップは、最大 180 日間保持できます。
- 差分バックアップの保有期間は、完全バックアップの保有期間よりも長くすることはできません (差分バックアップは復旧時に完全バックアップに依存しているため)。
- マスター データベースでは、差分バックアップはサポートされていません。
既定の設定を変更するには、 [ログ バックアップ] に対応する [編集] リンクを選択します
- [ログ バックアップ] で、 [有効] を選択して、頻度とリテンション期間の制御を設定します。
- ログ バックアップは、15 分ごとの頻度で実行でき、最大 35 日間保持することが可能です。
- データベースが単純復旧モデルである場合、そのデータベースのログ バックアップ スケジュールは一時停止されるため、ログ バックアップはトリガーされません。
- データベースの復旧モデルが [完全] から [単純] に変更された場合、復旧モデルが変更されてから 24 時間以内にログ バックアップが一時停止されます。 同様に、復旧モデルが [単純] から変更された場合、データベースでログ バックアップがサポートされるようになったので、復旧モデルの変更から 24 時間以内にログ バックアップ スケジュールが有効になります。
[バックアップ ポリシー] メニューで、 [SQL バックアップの圧縮] を有効にするかどうかを選択します。 既定では、このオプションは無効になっています。 有効にすると、圧縮されたバックアップストリームが SQL Server によって VDI に送信されます。 Azure Backup は、このコントロールの値に応じて、COMPRESSION / NO_COMPRESSION 句を使用して、インスタンス レベルの既定値をオーバーライドします。
バックアップ ポリシーに対する編集が完了したら、 [OK] を選択します。
Note
各ログ バックアップは、復旧チェーンを形成するために、以前の完全バックアップにチェーンされています。 この完全バックアップは、前回のログ バックアップのリテンション期間が終了するまで保持されます。 これは、完全バックアップのリテンション期間を追加して、すべてのログが確実に復旧されるようにすることを意味します。 週単位の完全、日単位の差分、2 時間ごとのログの各バックアップを実行していると仮定します。 これらのすべてが 30 日間保持されます。 ただし、週単位の完全バックアップは、次の完全バックアップが利用可能になった後でのみ、すなわち 30 + 7 日後に、実際にクリーンアップまたは削除することができます。 たとえば、週単位の完全バックアップが 11 月 16 日に行われたとします。 保持ポリシーに従って、12 月 16 日まで保持されます。 この完全バックアップに対する前回のログ バックアップは、11 月 22 日に予定されている次の完全バックアップの前に行われます。 このログが 12 月 22 日までに利用可能になるまでは、11 月 16 日の完全バックアップは削除されません。 そのため、11 月 16 日の完全バックアップは、12 月 22 日までは保持されます。
オンデマンド バックアップを実行する
- Recovery Services コンテナーで、[バックアップ アイテム] を選択します。
- [SQL in Azure VM](Azure VM 内の SQL) を選択します。
- データベースを右クリックし、[今すぐバックアップ] を選択します。
- バックアップの種類 (完全、差分、ログ、コピーのみの完全) と圧縮 (有効または無効) を選びます。
- On-demand full では、バックアップが最短で "45 日間"、最大で "99 年間" 保持されます。
- On-demand copy only full では、保持するすべての値を受け入れます。
- On-demand differential では、ポリシーに設定されているスケジュールされた差分の保持に従ってバックアップが保持されます。
- On-demand log では、ポリシーに設定されているスケジュールされたログの保持に従ってバックアップが保持されます。
- [OK] を選択して、バックアップを開始します。
- Recovery Services コンテナーに移動し、[バックアップ ジョブ] を選択して、バックアップ ジョブを監視します。
次のステップ
このチュートリアルでは、Azure portal を使用して以下を行いました。
- コンテナーの作成と構成。
- データベースの検出とバックアップの設定。
- データベースに対する自動保護の設定。
- オンデマンド バックアップを実行します。
ディスクから Azure 仮想マシンを復元するには、次のチュートリアルに進みます。