この記事では、Azure Stack 上の SQL Server データベースを保護するように Microsoft Azure Backup Server (MABS) を構成する方法について説明します。
SQL Server データベースの保護ワークフロー
Azure への SQL Server データベース バックアップと Azure からの復旧の管理には、次のものが含まれます。
- SQL Server データベースを保護するためのバックアップ ポリシーを作成する
- オンデマンド バックアップ コピーを作成する
- ディスクと Azure からデータベースを復旧する
Azure Stack 上の SQL Server バックアップでサポートされるシナリオと制限事項
Azure Stack 上の SQL Server をバックアップする前に、サポートされている次のシナリオと制限事項を確認してください。
- リモート ファイル共有上のファイルを含むデータベースがある場合、エラー ID 104 で保護が失敗します。 MABS では、リモート ファイル共有上の SQL Server データの保護はサポートされていません。
- MABS は、リモート SMB 共有に格納されているデータベースを保護できません。
- 可用性グループのレプリカが読み取り専用として構成されていることを確認します。
- システム アカウント NTAuthority\System を SQL Server の Sysadmin グループに明示的に追加する必要があります。
- 部分的包含データベースに対して別の場所の復旧を実行する場合は、ターゲット SQL インスタンスで 包含データベース 機能が有効になっていることを確認する必要があります。
- ファイル ストリーム データベースの別の場所の回復を実行する場合は、ターゲット SQL インスタンスで ファイル ストリーム データベース 機能が有効になっていることを確認する必要があります。
- SQL Server Always On の保護:
- MABS は、保護グループの作成時に問い合わせを実行するときに可用性グループを検出します。
- MABS はフェールオーバーを検出し、データベースの保護を継続します。
- MABS では、SQL Server のインスタンスのマルチサイト クラスター構成がサポートされています。
- Always On 機能を使用するデータベースを保護する場合、MABS には次の制限があります。
- MABS では、次のように、バックアップ設定に基づいて SQL Server で設定されている可用性グループのバックアップ ポリシーが適用されます。
- セカンダリを優先する - プライマリ レプリカが唯一のレプリカオンラインである場合を除き、セカンダリ レプリカでバックアップを実行する必要があります。 複数のセカンダリ レプリカが使用可能な場合は、バックアップの優先度が最も高いノードがバックアップ用に選択されます。 プライマリ レプリカのみを使用できる場合は、プライマリ レプリカでバックアップを実行する必要があります。
- セカンダリのみ - プライマリ レプリカでバックアップを実行しないでください。 プライマリ レプリカのみがオンラインの場合、バックアップは実行されません。
- プライマリ - バックアップは常にプライマリ レプリカで実行する必要があります。
- 任意のレプリカ - バックアップは、可用性グループ内の任意の可用性レプリカで実行できます。 バックアップ元のノードは、各ノードのバックアップの優先順位に基づきます。
-
注
- バックアップは、読み取り可能なレプリカ (プライマリ、同期セカンダリ、非同期セカンダリ) から行うことができます。
- レプリカがバックアップから除外されている場合 (たとえば、 レプリカの除外 が有効になっているか、読み取り不可としてマークされている場合)、そのレプリカはいずれのオプションでもバックアップ用に選択されません。
- 複数のレプリカが使用可能で読み取り可能な場合は、バックアップの優先度が最も高いノードがバックアップ用に選択されます。
- 選択したノードでバックアップが失敗した場合、バックアップ操作は失敗します。
- 元の場所への復旧はサポートされていません。
- MABS では、次のように、バックアップ設定に基づいて SQL Server で設定されている可用性グループのバックアップ ポリシーが適用されます。
- SQL Server 2014 以降のバックアップの問題:
- SQL Server 2014 では、 Microsoft Azure Blob Storage 上にオンプレミスの SQL Server 用のデータベースを作成するための新機能が追加されました。 MABS を使用してこの構成を保護することはできません。
- SQL Always On オプションの "セカンダリを優先する" バックアップ設定には、いくつかの既知の問題があります。 MABS は常にセカンダリからバックアップを取得します。 セカンダリが見つからない場合、バックアップは失敗します。
[前提条件]
Azure Stack で SQL Server をバックアップする前に、 Azure Backup Server をインストールして準備します。
Azure Stack 上の SQL Server データベースのバックアップ ポリシーを作成する
SQL Server データベースを Azure に保護するバックアップ ポリシーを作成するには、次の手順に従います。
Azure Backup Server で、保護ワークスペースを選択します。
ツール メニューの [ 新規 ] を選択して、新しい保護グループを作成します。
Azure Backup Server によって保護グループ ウィザードが開始され、 保護グループの作成が開始されます。 [次へ] を選択します。
[ 保護グループの種類の選択 ] ブレードで、[サーバー] を選択 します。
[ グループ メンバーの選択 ] ブレードの [使用可能なメンバー] リストには、さまざまなデータ ソースが表示されます。 +を選択してフォルダーを展開し、サブフォルダーを表示します。 チェック ボックスをオンにして項目を選択します。
選択したすべての項目が[選択したメンバー]リストに表示されます。 保護するサーバーまたはデータベースを選択したら、[ 次へ] を選択します。
[ データ保護方法の選択 ] ブレードで、保護グループの名前を指定し、[ オンラインで保護する ] チェック ボックスをオンにします。
[ 短期目標の指定 ] ブレードで、ディスクへのバックアップ ポイントを作成するために必要な入力項目を含め、[ 次へ ] を選択します。
この例では、 保有期間の範囲 は 5 日で、 同期の頻度 は 15 分ごとに 1 回です。これはバックアップの頻度です。 高速完全バックアップ は 午後 8:00 に設定されています。
注
この例では、毎日午後 8 時に、前日の午後 8:00 のバックアップ ポイントから変更されたデータを転送することでバックアップ ポイントが作成されます。 このプロセスは、 高速完全バックアップと呼ばれます。 トランザクション ログは 15 分ごとに同期されます。 午後 9 時にデータベースを復旧する必要がある場合は、最後の高速完全バックアップ ポイント (この場合は午後 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 時に作成されます。
注
迅速な回復のために、ディスクにいくつかの短期的な回復ポイントを置くことをお勧めします。 これらの復旧ポイントは、運用復旧に使用されます。 Azure は、SLA が高く、可用性が保証された適切なオフサイトの場所として機能します。
ベスト プラクティス: ローカル ディスク バックアップの完了後に Azure へのバックアップを開始するようにスケジュールすると、最新のディスク バックアップが常に Azure にコピーされます。
保持ポリシーのスケジュールを選択します。 保持ポリシーのしくみの詳細については、「 Azure Backup を使用してテープ インフラストラクチャを置き換える」の記事を参照してください。
この例では:
- バックアップは 1 日に 1 回午後 12:00 と午後 8 時に作成され、180 日間保持されます。
- 土曜日の午後 12 時にバックアップは 104 週間保持されます
- 先週の土曜日の午後 12:00 のバックアップは、60 か月間保持されます
- 3 月の最後の土曜日の午後 12:00 のバックアップは、10 年間保持されます
[ 次へ ] を選択し、初期バックアップ コピーを Azure に転送するための適切なオプションを選択します。 [ネットワーク経由で自動的に] を選択できます
[概要] ブレードでポリシーの詳細を確認したら、[グループの作成] を選択してワークフローを完了します。 [ 閉じる ] を選択し、[監視] ワークスペースでジョブの進行状況を監視できます。
Azure Stack で SQL Server データベースのオンデマンド バックアップを実行する
復旧ポイントは、最初のバックアップが行われるときにのみ作成されます。 バックアップ ポリシーを作成した後は、スケジューラがバックアップを実行するのを待つのではなく、手動で復旧ポイントの作成をトリガーできます。
SQL Server データベースのオンデマンド バックアップを実行するには、次の手順に従います。
復旧ポイントを作成する前に、データベースの保護グループの状態が [OK] と 表示されるまで待ちます。
データベースを右クリックし、[ 復旧ポイントの作成] を選択します。
ドロップダウン メニューで [ オンライン保護 ] を選択し、[ OK] を 選択して Azure での復旧ポイントの作成を開始します。
[監視] ワークスペースでジョブの進行状況を表示します。
Azure から Azure Stack 上の SQL Server データベースを復旧する
保護されたエンティティ (SQL Server データベース) を Azure から復旧するには、次の手順に従います。
Azure Backup Server 管理コンソールを開きます。 保護されたサーバーを表示できる [回復 ] ワークスペースに移動します。 必要なデータベース (この場合は ReportServer$MSDPM2012) を参照します。 回復の開始をオンラインのポイントとして指定された時点から選択します。
データベース名を右クリックし、[回復] を選択 します。
MABS には、復旧ポイントの詳細が表示されます。 [次へ] を選択します。 データベースを上書きするには、回復の種類として [SQL Server の元のインスタンスに回復する] を選択します。 [次へ] を選択します。
この例では、MABS はデータベースを別の SQL Server インスタンスまたはスタンドアロン ネットワーク フォルダーに復旧します。
[ 回復オプションの指定 ] ブレードで、ネットワーク帯域幅の使用調整などの回復オプションを選択して、回復で使用される帯域幅を調整できます。 [次へ] を選択します。
[ 概要 ] ブレードには、これまでに提供されたすべての回復構成が表示されます。 [ 回復] を選択します。
回復状態には、復旧中のデータベースが表示されます。 [閉じる] を選択してウィザードを閉じ、[監視] ワークスペースで進行状況を表示できます。
復旧が完了すると、復元されたデータベースはアプリケーション整合性になります。