バックアップからのMS SQLデータベースの自動回復

この記事では、MS SQLユーティリティのクイックメンテナンスとバックアップを使用して、ネットワーク上のSQL Serverのテストインスタンスのバックアップから自動データベース回復を構成する方法についてお話したいと思います。 同時に、通常のサービスプランでバックアップが作成されます。 自動回復の必要性は、次の場合に発生する可能性があります。

1. テストサーバー上のデータベースを定期的に更新する必要がある場合。
2. リカバリを通じて作成されたバックアップを定期的に確認する必要がある場合：フル、デルタ、トランザクションログ。

ネットワーク上で、これらのタスクを何らかの方法で自動化できるスクリプトの例を見つけることができます。 ただし、ほとんどのソリューションでは、サブジェクト領域であるT-SQLを十分に理解する必要があり、サービスプランを変更する必要があります。 MS SQL（QMB）ユーティリティのクイックメンテナンスとバックアップを使用して、15〜20分でこれを行う方法を示します。 XMLリカバリプランのメカニズムを使用します。これは、ユーティリティが作成できる一連のバックアップを含むXMLファイルです。 XMLファイルの情報に従って、プログラムは一連のバックアップを受信し、回復用のT-SQLスクリプトを生成し、実行するために実行します。 この機能の詳細については、 こちらをご覧ください 。



この記事の他に、 公式Webサイトでユーティリティの他の機能の詳細をお読みください 。

挑戦する

そのため、いくつかのデータベースが完全復旧モデルで展開されている稼働中のSQL Server（Srv01）があるとします。 任意のバックアップ戦略を持つサービスプランがサーバー上に作成されました。 私の場合、これは次のとおりです。

完全バックアップ-毎週日曜日の24.00

差分バックアップ-日曜日を除く毎晩24時

ログバックアップ-毎日1時間ごとに9.00から23.59まで

バックアップはフォルダーF：\ MS SQL \ Backupに作成されます。 同時に、SQL Serverエージェントはデータベースごとに個別のサブフォルダーを作成します。



タスク：バックアップSQL Server（ロンドン）で毎日23:00に、Srv01で作成されたバックアップからデータベースを可能な限り最後の状態に復元します。 両方のサーバーが単一のローカルネットワーク上にあります。 各データベースを復元した後、その整合性をチェックする必要があります（DBCC CHECKDB）。 したがって、日曜日を除く毎晩、日中に作成されたフルバックアップ、差分およびトランザクションログからのリカバリが実行されます。 月曜日に、月曜日に作成されたフルバックアップとトランザクションログからリカバリが実行されます。 何らかの理由でリカバリが失敗した場合、管理者は電子メール通知を受信する必要があります。



テストSQL Server（ロンドン）が回復を実行できるようにするには、バックアップファイルにアクセスできる必要があることは明らかです。 ここでは2つのオプションが可能です。

1. Srv01でフォルダーF：\ MS SQL \ Backupを共有して、ロンドンで使用できるようにします。
2. QMBを使用して、ロンドンで利用可能な共有ネットワークフォルダーにバックアップをコピーします。

追加の信頼性とセットアップの容易さにより、2番目のオプション、つまり ユーティリティはさらにファイルをネットワークフォルダーにコピーします。

一般的な手順

そのため、次の手順を実行する必要があります。

1. 共有ネットワークフォルダーを設定する
2. QMBユーティリティをインストールする
3. 通知を設定し、プログラムに2つのSQL Server：Srv01とLondonを登録します。
4. プログラムで2つの新しいタスクを作成します。
   
   
   
   
   • ネットワークドライブでのXMLリカバリプランの作成
   • ネットワークドライブからのXMLプランの回復
     
     
     
     
5. プログラムで2つのスクリプトを作成します。
   
   
   
   
   • 共有サーバーにバックアップファイルをコピーしてXMLリカバリプランを作成する運用サーバーSrv01上のスクリプト。 1時間ごとに開始します。
   • 共有フォルダーにあるバックアップからXML回復を実行するロンドンのテストサーバー上のスクリプト。 毎日23.00に開始します。

以下では、各ステップをより詳細に検討します。



QMBインストール



ユーティリティはここからダウンロードできます 。 試用期間は30日間です。



ロンドンのテストサーバーにユーティリティをインストールしました。 一般的に、プログラムは24時間稼働しているコンピューターにインストールできます。 SQL Serverへのインストールはオプションです。 プログラムをインストールするとき、すべてのデフォルト設定のままにします。 インストーラーはQmbServiceとクライアントサービスをインストールします。



SQL Serverの登録と通知の構成



プログラムを初めて起動すると、ウィザードが開きます。 次のステップに進み、「メールアラートを有効にする」チェックボックスを設定して、通知を受信するメールアドレスを入力します。









通知を送信するには、独自のSMTPアカウントを構成することをお勧めしますが、簡単にするために組み込みを使用します。 次に、SQL Serverに接続するSQL Serverの名前とアカウントを入力します。 sysadmin特権を持つアカウント（デフォルトではsa）を指定する必要があります。



次のステップで、プログラムはサーバーのバージョン、ライセンス、およびバックアップ圧縮の兆候を表示します。 デフォルトではすべてのパラメーターを残し、「進む」ボタンをクリックします。



次のウィンドウで、空きディスク容量の追跡を設定できます。 これが不要な場合は、ディスクからすべてのチェックボックスを削除します。









[転送]ボタンをクリックします。



データベースを管理する必要はないので、最後のページで「空のスタンドアロンスクリプトを作成する」を選択します。 次に、「システムデータベースを処理するためのスタンドアロンスクリプトを作成する」のチェックを外し、「完了」ボタンをクリックします。









プログラムはSQL Serverを登録し、新しい空のスクリプトフォームを開きます。

XMLリカバリプランの作成

プログラム内のタスクはすべて、スクリプトの一部として実行されます。 新しいスタンドアロンスクリプトのウィンドウで、名前「 XMLリカバリプランの作成 」を入力します 。









リカバリプランのXMLファイルを作成するスクリプトにタスクを追加します。 [追加]ボタンをクリックします。 タスク選択フォームが開きます。 ボタンをクリックしてください 「新しいタスクを追加します。」 新しいタスクフォームが開きます。









必要なフォーム：

1. タスクタイプを「XMLリカバリプランの作成」に変更します
2. 共有フォルダーへの新しい接続を作成します。 私の場合、これはファイルサーバー上の\\ Server \ Backupフォルダです。
   
   
   
   
   
   
   
   
   
   
   
   注：ドメインのないネットワークの場合、ユーザー名は次の形式で指定する必要があります：Computer \ User
   
   
   
   
3. XMLリカバリプランに含めるデータベースを選択します。 私の場合、これらは3つのデータベースです-Account2013、Account2014、Account2015。
4. タスクの名前を指定します-Account2013、Account2014、Account2015のXMLプランを作成します。

すべてのステップを完了すると、タスクのフォームは次の画像のようになります。









「不足しているアーカイブコピーファイルを共有フォルダーにコピーする」という記号に注意してください。 このオプションにより、プログラムは不足しているバックアップファイルをローカルのSQL Serverドライブからネットワークフォルダーに自動的にコピーします。 同時に、プログラムは作成されたバックアップに関する独自の情報によってソースファイルへのパスを決定します。この情報は、SQL Serverがmsdbシステムデータベースに保存します。



[ 承諾 ]ボタンをクリックし、スクリプトで作成されたタスクを選択します。 スクリプトのフォームで、「スクリプトをスケジュールどおりに実行」フラグを設定し、スケジュールを示します。毎日、1時間後の9:30から22:30まで。 サービスプランは9:00から23:59まで1時間ごとにバックアップログを作成することを思い出させてください。 このようにして、QMBは30分のシフト（9：30、10：30、11：30など）でXMLリカバリプランを更新します。 バックアップがQMBサービスポリシーによって作成された場合、リカバリプランのXMLファイルは自動的に更新されることに注意してください。



スクリプトは次の画像のようになります。









次に、スクリプトを確認します。 これを行うには、「実行」ボタンをクリックします。 すべてが正しく構成されている場合、バックアップファイルがネットワークフォルダーにコピーされ、 RestorationPlan.xmlファイルが作成されます。 プログラムが操作中に必要なバックアップファイルを見つけられない場合、タスクは失敗します。 このようにして、潜在的な問題について事前に知ることができます。 たとえば、多くの場合、管理者はデータベース転送のフルバックアップを（COPY_ONLYパラメーターなしで）作成し、転送後にスペースを占有しないようにすぐに削除します。 ただし、バックアップチェーンが破損し、現在の時点への復元が不可能になります。 プログラムは、XMLリカバリプランを作成する段階でもこの問題を特定します。









スクリプトを保存します。 これで、QMBは1時間ごとに、回復計画のXMLファイルを再作成し、通常のSQL Serverエージェントが作成する新しいバックアップファイルをコピーします。

XMLプランを作成するタスクは、可能な限り最後の時点での回復にのみ必要なファイルをコピーすることに注意してください。 この場合、ファイルはフォルダーなしでコピーされます。 すべてのファイルは、指定されたネットワークフォルダーに配置されます。 このプログラムには、サブフォルダーのコピー、およびネットワークフォルダー内の古いファイルの削除を構成する機能があります。 これは、CMDスクリプトを含むユーザータスクまたはQMBサービスポリシーを使用して実行できます 。

テストサーバーでの回復

スクリプトに配置された特別なタスクを使用して、XMLプランからの回復も同様に実行されます。 ただし、テストSQL Server（ロンドン）でリカバリを実行する必要があるため、このサーバーもプログラムに登録する必要があります。 これを行うには、左側のツリービューで、をクリックします サーバーを登録します。 サーバーの登録手順は、前述の手順とまったく同じです。



サーバーを登録すると、オフラインスクリプトウィンドウが開きます。 Srv01を使用してXMLプランに従ってRestoreという名前を入力し、そのスケジュールを示します：毎日23:00。









ここで、XMLプランを作成するタスクを作成した方法と同様に、スクリプトフォームから新しいタスクを追加します。 ただし、ここで[ タイプ]フィールドで[ XMLプランで復元]を指定し、以前に作成したネットワークフォルダーへの接続を選択して、XMLファイルの名前を指定します。 ソースデータベーススイッチは、XMLリカバリプランのどのデータベースを復元する必要があるかを決定します。









回復が実行されるデータベースは、同じ名前のスイッチによって決定されます。 この場合、同じ名前のデータベースに復元します。 これは、SQL Server上で類似した名前のデータベースが作成/上書きされることを意味します（私の場合、これらは3つのデータベースです：Account2013、Account2014、Account2015）。 したがって、これらのデータベースは最後の状態に更新されます。



バックアップファイルと回復手順を確認するために回復を実行する場合は、[一時データベースに復元]モードを選択する必要があります。 このモードでは、QMBはqmbTempRestoreDb [Random Index]という名前の一時データベースを作成します。このデータベースは、整合性を復元して確認した後に削除されます。



タスクを保存し、シナリオで選択します。









リカバリが成功することを確認するために、手動モードでスクリプトを実行します。 プログラムは各データベースを順次復元し、その整合性をテストします。 データベースのサイズによっては、手順にかなりの時間がかかる場合があります。









スクリプトを保存します。 現在、毎日23:00にプログラムが自動的にデータベースを復元し、障害が発生した場合に電子メール通知を送信します。









さらに、回復計画XMLファイルを使用して、プログラムを使用する管理者は、数回クリックするだけで、他のSQL Serverのデータベースを手動で復元できます。



コメントやEメールsupport@qmbsql.ruで質問にお答えします

ご清聴ありがとうございました！