Azure Stack での SQL Server のバックアップ

[アーティクル]
03/04/2024

この記事では、Azure Stack 上の SQL Server データベースを保護するように Microsoft Azure Backup Server (MABS) を構成する方法について説明します。

SQL Server データベースの保護ワークフロー

Azure への SQL Server データベースバックアップと Azure からの復旧の管理には、次のことが含まれます。

SQL Server データベースを保護するためのバックアップポリシーを作成する
オンデマンドでのバックアップコピーを作成する
ディスクおよび Azure からデータベースを回復する

前提条件と制限事項

リモートファイル共有にあるファイルを含むデータベースがある場合、保護はエラー ID 104 で失敗します。 MABS では、リモートファイル共有上の SQL Server データの保護はサポートされていません。
リモート SMB 共有に保存されているデータベースを MABS で保護することはできません。
可用性グループのレプリカが読み取り専用として構成されていることを確認します。
システムアカウント NTAuthority\System を SQL Server の Sysadmin グループに明示的に追加する必要があります。
部分的な包含データベースに対して別の場所への回復を実行する場合は、ターゲット SQL インスタンスで包含データベース機能が有効になっていることを確認する必要があります。
ファイルストリームデータベースに対して別の場所への回復を実行する場合、ターゲット SQL インスタンスでファイルストリームデータベース機能が有効になっていることを確認する必要があります。
SQL Server Always On の保護:
- 保護グループの作成時に照会を実行するときに、MABS によって可用性グループが検出されます。
- MABS によってフェールオーバーが検出され、データベース保護が続行されます。
- MABS では、SQL Server のインスタンスに対するマルチサイトクラスター構成がサポートされます。
Always On 機能を使用するデータベースを保護する場合、MABS には次の制限があります：
- MABS では、次のように、バックアップ設定に基づいて SQL Server に設定されている可用性グループ用のバックアップポリシーに従います。
  - セカンダリ優先 - オンラインになっているのがプライマリレプリカのみの場合を除き、バックアップは常にセカンダリレプリカ上で発生します。セカンダリレプリカが複数ある場合は、バックアップの優先度が最も高いノードがバックアップ用に選択されます。プライマリレプリカのみを使用できる場合、バックアップはプライマリレプリカ上で発生します。
  - セカンダリのみ - プライマリレプリカでのバックアップは行いません。オンラインになっているのがプライマリレプリカのみの場合、バックアップは発生しません。
  - プライマリ - バックアップは常にプライマリレプリカ上で発生します。
  - 任意のレプリカ - バックアップは、可用性グループ内の使用可能な任意のレプリカで発生できます。バックアップ元となるノードは、各ノードのバックアップの優先度によって決まります。
- Note
  - 読み取り可能なレプリカ (プライマリ、同期セカンダリ、非同期セカンダリ) であれば、どれでもバックアップを発生させることができます。
  - レプリカがバックアップから除外されている場合 (たとえば [レプリカの除外] が有効であったり、レプリカが読み取り不可としてマークされていたりする場合) は、どのオプションでも、そのレプリカがバックアップ用に選択されることはありません。
  - 読み取り可能なレプリカが複数ある場合は、バックアップの優先度が最も高いノードがバックアップ用に選択されます。
  - 選択されたノード上でバックアップに失敗した場合、バックアップ操作は失敗します。
  - 元の場所への回復はサポートされていません。
SQL Server 2014 以降のバックアップに関する問題:
- SQL Server 2014 では、Microsoft Azure Blob Storage にオンプレミスの SQL Server 用のデータベースを作成するための新機能が追加されました。この構成を保護するために MABS を使用することはできません。
- SQL Always On オプションの [セカンダリを優先する] バックアップ設定には、いくつかの既知の問題があります。 MABS では、常にセカンダリからバックアップが作成されます。セカンダリが見つからない場合、バックアップは失敗します。

開始する前に

Azure Backup Server をインストールして準備します。

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

SQL Server データベースを保護するための Azure へのバックアップポリシーを作成するには、次の手順のようにします。

Azure Backup Server で、[保護] ワークスペースを選択します。
ツールメニューで、[新規] を選択して新しい保護グループを作成します。

Azure Backup Server によって保護グループウィザードが起動されます。ウィザードに従って保護グループを作成します。 [次へ] を選択します。
[保護グループの種類の選択] ブレードで、[サーバー] を選択します。
[グループメンバーの選択] ブレードの [利用可能なメンバー] のリストには、さまざまなデータソースが表示されます。 + を選択すると、フォルダーが展開してサブフォルダーが表示されます。チェックボックスを選択して項目を選択します。

選択メンバーの一覧には、選択したすべての項目が表示されます。保護するサーバーまたはデータベースを選択したら、 [次へ] を選択します。
[データの保護方法の選択] ブレードで、保護グループの名前を指定して、[オンライン保護を利用する] チェックボックスをオンにします。
[短期的な目標値の指定] ブレードで、ディスクへのバックアップポイントの作成に必要な情報を入力して、[次へ] を選びます。

この例では、 [リテンション期間] を 5 日間、バックアップの頻度である [同期の間隔] を 15 分おきに指定しています。 [高速完全バックアップ] は 午後 8 時 00 分に設定されています。

Note

この例では、毎日午後 8 時 00 分に前日午後 8 時 00 分のバックアップポイント以降の変更データを転送することでバックアップポイントが作成されます。このプロセスは、 高速完全バックアップと呼ばれます。トランザクションログは、15 分おきに同期されます。午後 9 時 00 分にデータベースを復旧する必要がある場合は、直前 (この場合は午後 8 時) の高速完全バックアップポイント以降のログからポイントが作成されます。
[ディスク割り当ての確認] ブレードで、使用可能なストレージ領域全体と、考えられるディスク領域を確認します。 [次へ] を選択します。
[レプリカの作成方法の選択] で、最初の回復ポイントの作成方法を選びます。初回バックアップの転送は、帯域幅の輻輳を避けるために手動 (オフライン) で行うか、ネットワーク経由で行うことができます。最初のバックアップを直ちに転送しない場合は、初回の転送時刻を指定できます。 [次へ] を選択します。

初回バックアップでは、データソース (SQL Server データベース) 全体を運用サーバー (SQL Server コンピューター) から Azure Backup Server に転送する必要があります。このデータは場合によっては大きくなり、ネットワーク経由で転送すると帯域幅を超える可能性があります。この理由から、初回バックアップの転送では、帯域幅の輻輳を避けるために手動で転送するか (リムーバブルメディアを使用)、指定した時刻に自動 (ネットワーク経由) で転送するかを選択できます。

初期バックアップが完了した後は、残りのバックアップは初期バックアップのコピーに対する増分バックアップになります。増分バックアップは一般に非常に小さく、ネットワーク経由で容易に転送できます。
整合性チェックをいつ実行するかを選択し、 [次へ] を選択します。

Azure Backup Server は、バックアップポイントの整合性について整合性チェックを実行します。 Azure Backup Server は、運用サーバー (このシナリオでは SQL Server コンピューター) のバックアップファイルとそのファイルのバックアップデータのチェックサムを計算します。一致しない場合、Azure Backup Server 上のバックアップファイルは破損しているものと見なされます。 Azure Backup Server は、チェックサムの不一致に対応するブロックを送信することでバックアップデータを修正します。整合性チェックはパフォーマンス集約型であるため、スケジュールを設定するか、自動的に実行できます。
データソースのオンライン保護を指定するには、Azure で保護されるデータベースを選択し、 [次へ] を選択します。
組織のポリシーに合わせてバックアップスケジュールとリテンションポリシーを選択します。

この例では、バックアップは 1 日に 1 回、午後 12 時 00 分と午後 8 時に作成されます。

Note

すばやく回復するために、ディスク上に短期的な回復ポイントをいくつか作っておくことをお勧めします。これらの回復ポイントは、オペレーショナルリカバリに使用されます。 Azure は、より高い SLA を提供し、可用性を確保するのに適したオフサイトの場所として機能します。

ベストプラクティス: Azure へのバックアップがローカルディスクバックアップの完了後に開始されるようにスケジュールすると、常に最新のディスクバックアップが Azure にコピーされます。
保有ポリシーのスケジュールを選択します。保有ポリシーのしくみの詳細については、「 Azure Backup を使用してテープのインフラストラクチャを置換する」を参照してください。

次の点に注意してください。
- バックアップは 1 日に 1 回、午後 12 時 00 分と午後 8 時に作成され、180 日間保持されます。
- 土曜日の午後 12 時 00 分のバックアップは、104 週間保有されます。
- 先週土曜日の午後 12 時 00 分のバックアップは、60 か月保有されます。
- 3 月の最終土曜日の午後 12 時 00 分のバックアップは、10 年間保有されます。
[次へ] を選択し、初期バックアップのコピーを Azure に転送するための適切なオプションを選択します。 [自動でネットワーク経由] を選択できます
[概要] ブレードでポリシーの詳細を確認したら、[グループの作成] を選択してワークフローを完了します。 [閉じる] を選択すると、[監視] ワークスペースでジョブの進行状況を監視できます。

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

"回復ポイント" は、最初のバックアップが行われるときにのみ作成されます。バックアップポリシーを作成した後、スケジューラによってバックアップが作成されるのを待つのではなく、手動で回復ポイントの作成をトリガーできます。

SQL Server データベースのオンデマンドバックアップを実行するには、次の手順のようにします。

データベースの保護グループの状態に " OK " と表示されるのを待ってから、回復ポイントを作成します。
データベースを右クリックして、[回復ポイントの作成] を選びます。
ドロップダウンメニューから [オンライン保護] を選択し、 [OK] を選択して Azure の回復ポイントの作成を開始します。
ジョブの進行状況は [監視] ワークスペースに表示されます。

Azure からのデータベースの復元

保護されたエンティティ (SQL Server データベース) を Azure から復旧するには、次の手順のようにします。

Azure Backup Server の管理コンソールを開きます。 [回復] ワークスペースに移動すると、保護されているサーバーを確認できます。目的のデータベース (この場合は ReportServer$MSDPM2012) を参照します。 オンライン ポイントとして指定される時刻を [回復元] で選択します。
データベース名を右クリックし、 [回復] を選択します。
MABS に復旧ポイントの詳細が表示されます。 [次へ] を選択します。データベースを上書きするには、回復のタイプとして [元の SQL Server のインスタンスに回復する] を選択します。 [次へ] を選択します。

この例では、MABS は、データベースを別の SQL Server インスタンスまたはスタンドアロンのネットワークフォルダーに回復します。
[回復オプションの指定] ブレードでは、回復で使われる帯域幅を調整するための [ネットワークの使用帯域幅の調整] など、回復に関するオプションを選択できます。 [次へ] を選択します。
[概要] ブレードに、これまでに指定した回復の構成がすべて表示されます。 [回復] を選択します。

回復の状態に、データベースが回復されていることが表示されます。 [閉じる] を選択してウィザードを閉じ、 [監視] ワークスペースで進行状況を確認できます。

回復が完了すると、復元されたデータベースはアプリケーションコンシステントになります。