SQLフェールオーバークラスターをバックアップする方法

最も明白なことをしない方法を示す巧妙な言葉なしに、ネットワーク上に簡単なステップバイステップの指示がないとき、私はそれが好きではありません。 したがって、今日は不要な紹介なしで、フェールオーバーSQLクラスターを正しくバックアップする方法を説明します。 はい、それはクラスターであり、スタンドアロンのSQLサーバーではありません。 それらについて多くのことが書かれており、何らかの理由でクラスターが回避されています。

長い紹介なしで、私たちのラボを検討してください。

• 内部のWindows Server 2012 r2と特定の数のノードを備えたWindowsクラスター。 便宜上、私のラボにはそのうちの2つしかありません。 正当な質問が発生します：クラスターをクラスターに配置する理由 もう少し詳しく説明します。
• iSCSIを介して3つのディスクがクラスターにフックされます。クォーラム、ベースを持つディスク、ログ用のディスクです。 ここで好きなように、もっと多く、もっと少なくすることができます。 2つのローカルディスク（1つはシステム用、1つはSQL自体のインストール用）、クォーラムディスク、ルートデータベースとシステムデータベース用の結合ディスク、ベース用のディスク、ログ用のディスク、TempDB用のディスク、およびバックアップ用のディスクです。 システムエンジニアは、これも正しいと言います。 しかし、ディスクの数は何の役割も果たさないと思います。 それがあなたのために働くなら、あなたは正しくてよくできています。
• 各ノードにはSQLインスタンスがインストールされており、SQLインスタンスはSQLクラスターの一部であり、WindowsクラスターはSQL Serverの役割を認識します。

さて、始める前に、2つの重要なことに同意しましょう。

• 決定を下し、疑うことを止めます（ここで、浴場、十字架、パンツについての冗談を挿入したかったのですが、 検閲 なしで行うことにしました）。 1つのインフラストラクチャは、1つのソリューションのみで処理する必要があります。 ソリューションAをSQLバックアップに使用し、ソリューションBをクラスターバックアップに使用する場合、Bはどのような状況でもSQLに触れないでください。 または、Bがアプリケーションレベルでマシンの詳細なバックアップを実行できる場合は、ソリューションAをまったく使用しない方が良いでしょう。 なんで？ 両方のアプリケーションがSQLログを転送して正常に実行できると想像してみましょう。 もちろん、SQLは正常に機能しますが、次のバックアップでは、最良の場合はサーバーの一貫性のない状態に関するメッセージを受け取り、最悪の場合、トランザクションログから回復することはできません。
• バックアップソフトウェアには「ミレナと千」のオプションがあることを知っています。それらはすべてinput_reason_hereのおかげで間違いなく優れていますが、 すみませんが 、これを行うことができるのは他のものより悪くなく、おそらくもっと良いことだけです。

行こう！

したがって、すでに明らかなように、ノード全体をバックアップします。 最初の質問はすぐに発生します。MicrosoftSQLクラスターがすぐに使用できるため、落下に対する非常にまともなレベルの保護が提供されるのはなぜですか。 たとえば、いつでもSQLとリソースの役割を別のノードに引き継ぐことができます。

この推論は正しいですが、ノード自体が脆弱であるというオプションは見逃されています。 要するに、OSレベルのクラスターは特定のマシンのOSの機能に関連するリスクを閉じ、SQLクラスターは特にデータベースに関連するリスクを閉じます。 はい、そしてこの構成のバックアップはより興味深いものです。

暗号化マルウェアが私たちのところにやって来て、クラスターノードを1つずつ配置し始めると想像してみましょう。 ここでは、データベースファイルのみをすばやく復元することはできません。 また、OSの更新に失敗したり、ハードウェアが死にかけたりすることもあります。

したがって、サーバー全体のバックアップの必要性について合意したことを検討することを提案し、次にツールを使用します。 Veeam Backup＆Replication 9.5で目標を達成し、驚くべき方法を書きます。別のバージョンの前に、Veeamは仮想マシンのみを集中的にバックアップできましたが、物理サーバーのバックアップを完全にサポートしました。

保護グループ

バックアップには、 保護グループを使用します。 これは、実際には単純な論理エンティティです。バックアップが必要なマシンがグループ化されているコンテナです。 たとえば、ADから複数のオブジェクトをグループ化でき、新しいマシンがバックアップされないという心配はありません。 保護グループは変更を自動的にスキャンし、指定されたスケジュールに従って残りの必要なアクションを実行します。 一言で言えば、特に大規模な混合インフラストラクチャでは非常に便利なことです。

しかし、言葉から行為に移りましょう： Veeam Backup＆Replicationを起動し、 インベントリタブに移動して保護グループ作成ウィザードを起動します

最初のステップでは、必要に応じてグループの名前と説明を指定する必要があります。ここではすべてが明確です。

ただし、次のステップでは、保護グループが保護対象マシンに関する情報を受信する場所を選択する必要があります。 DNS名またはIPを使用して古い方法で手動で追加できます。実際のJediが行うように、CSVファイルの形式でリストを提供できますが、私たちはよりシンプルで、Active Directoryオブジェクトを使用します。 この場合、これはクラスターのすべてのノード（新しいノードを含む）が自動的に検出されることも意味します。

次のステップでは、最初に、接続するドメインコントローラー、ポート、およびユーザーデータのアドレスを指定するよう求められます。

すべてが問題ない場合は、[ 追加 ] をクリックして、必要なOUを選択します。

重要なポイント： クラスターを追加するだけです！ 個別のノードを追加する必要はありません。

私のクラスターはWINCLUと呼ばれ、追加します。

次のステップで、スキャンからマシンを除外するルールを設定します。 現代の世界では、OUには仮想マシンと物理マシンの両方が含まれることが多く、場合によっては異なるシナリオでバックアップされます。 実際、物理マシンと仮想マシンの両方が使用される混合クラスターもあります。 一種の第三レベルの保護。

デフォルトでは、最初の2つのチェックボックスが選択されており、削除する必要はないかもしれませんが、私のラボは完全に仮想であり、最初は物理マシンのバックアップ機能を確認することに同意しました。

次に、使用するユーザーを指定する必要があります。 ある理想的なケースでは、すべてのマシンでローカル管理者権限を持つ特別なユーザーをADに作成しました。 しかし、そうでない場合、Veeamでは各オブジェクトに個別のユーザーを割り当てることができます。

なぜローカル管理者が必要なのですか？

• まず、各マシンにVeeam Agentをインストールします。これにより、ローカルバックアッププロセスが管理されます。
• 第二に、Veeam Agentがこのバックアップを作成するには、VSSを操作するローカル管理者権限が必要です。 それがWindowsの仕組みであり、それについて何もすることはありません。

それとは別に、[ 今すぐテスト ]ボタンに集中する必要があります。 すべてのアカウントが正しく入力されていることを迅速に確認できる素晴らしいことです。クラスターの場合は、事前にすべてのノードが表示されアクセス可能であることを確認してください。

次に、PG参加者をスキャンする間隔と時間を設定する必要があります。 少なくとも週に1回は実行できますが、継続的な更新を設定できます。 それはあなた次第ですが、通常、すべての新しい参加者が最も近い回復ポイントに到達できるように、バックアップの頻度を繰り返すことは素晴らしいオプションです。

以下は、それほど明白ではないが重要なオプションです。

配信サーバーは、Veeam Agentがインストールされるマシンです。 一般に、Veeam Backupサーバーを使用するだけで十分ですが、接続が不十分な地理的に分散したインフラストラクチャでは、より近いオプションを指定することは理にかなっています。 他のすべての場合、変更は意味がありません。

さらに。 エージェントをインストールして自動更新しない理由はわかりませんが、自動化を信用していない場合は安全に拒否できます。 ただし、バージョンの違いにより、別のバックアップポイントがなくなる可能性があることに注意してください。

また、ファイルシステムレベルでディスクの変更を追跡するCBTドライバーをインストールすることに同意することもできます。 これにより、実際に変更されたセクターのみをバックアップに送信できます。つまり、復元ポイントが少なくなり、バックアップが速くなり、サーバーの負荷が少なくなります。 しかし、信頼できない場合、トラフィックはあなたにとって重要ではなく、ディスクは大きく、接続は優れているので、それを置くことはできません。

自動再起動には微妙な違いがあります。最初のインストール中だけでなく、更新中にも使用されます。 そのような贅沢を買う余裕がない場合は、チェックを外すことを忘れないでください。

次のステップで、Distributionサーバーにコンポーネントを再インストールする必要性について通知されます。 彼らがそこにいなくても、すぐに彼らはApplyボタンをクリックすることによってそこにいるでしょう。

最後のステップで、保護グループ（PG）が正常に作成されたことが通知されます。 指定された条件に従ってグループがマシンのリストを作成し、設定に従ってエージェントのインストールを開始します。 必要な操作はすべて行われますが、コーヒーを飲みに行くことができます。

一杯のコーヒーを空にすることにより、ネットワークアクセスエラーのためにノードの1つにエージェントをインストールできなかったことがわかります。 そのような悲しみがあなたに起こった場合は、このノードからクォーラムディスクを切断してください。 頻繁ではありませんが、起こります。 または、これは私の研究室の単なる機能です。 そのため、この問題に最後まで対処する忍耐力がありませんでした。

バックアップを作成

したがって、前の段階ですべてが正常に終了した場合、保護グループにはクラスターと、エージェントが正常にインストールされたノードのリストがあります。 そのため、最も興味深いのは、フェールオーバークラスターモードでバックアップを作成し、すべてのノードとすべての接続されたディスクがバックアップに入るようにすることです。

主な違いは何ですか？また、なぜそれらを別々のマシンとしてバックアップできないのですか？ 技術的には、1つを除くすべてのノード（クラスターロールの現在の所有者）でこれを行うことができます。 額に直接バックアップを開始すると、他のノードはそれとの接触を失い、自分自身の上にブランケットを引っ張り始め、最終的にクラスター全体の崩壊と停止につながります。 これは、ビジーなシステムで頻繁に発生します。

マウスの右ボタン（RMB）を使用してPGをクリックし、バックアップジョブ作成ウィザードを起動して、すぐにフェールオーバークラスターモードを選択します。 このようなタスクは、ローカルエージェントバックアップとは異なり、中央のバックアップサーバーでのみ作成できます。 しかし、これは論理的です。覚えているように、SQLを同時に完全にバックアップしたかったため、ログは定期的にトランキングされます。いずれの場合も、サーバー間の通信が必要になります。

次に、ジョブの名前とバックアップ参加者のリストを選択します。 デフォルトでは、選択されたPGのみが存在しますが、ここで何か追加することもできます。

次のステップでは、個々のディスクのバックアップまたはマシン全体のバックアップを選択する必要があります。 一般に、マシン全体をバックアップできる場合、マシン全体をバックアップする必要があります。 私たちの場合、これは本当です、なぜなら クラスターのノードに表示される可能性があるすべてのクラスターディスクをバックアップする必要があります。

次に、バックアップ用のリポジトリを選択し、復元ポイントの数を指定します。 [ 詳細設定 ]ボタンを使用すると、微調整メニューを呼び出して、バックアップチェーンの作成方法の選択、追加のファイル整合性チェックの有効化などを行うことができます。最も興味深いセクションはGuest Processingセクションであるため、今は時間を無駄にしません。

いわゆるアプリケーション整合性バックアップを取得できるかどうかは、このタブの設定に依存します（これは、統合バックアップとして、またはアプリケーションの状態を考慮したバックアップとして翻訳される場合があります。または、方法と、最も重要な理由はまだわかりません）。 したがって、 アプリケーションに移動して、PGを選択し、 編集をクリックします。

最初のタブにApplication-Aware Processingが含まれていることを確認してください。 この場合、VSSサブシステムが関与し、その作業はエラーなしで成功するはずです。 むしろ、エラーが発生しても機能する場合がありますが、この場合、バックアップは作成されないため、障害の原因を理解する必要があります。 ここで、トランザクションログの運命を判断する必要もあります。Veeamはそれらを無視し、単にバックアップまたは切り取りにコピーできます。

[ SQL ]タブに移動します。 最初に行うことは、SQLサーバーとそのデータベースとの対話用のユーザーアカウントを設定することです。 理想的な世界では、PGの作成時に指定したローカル管理者と一致します。 それ以外の場合、主なことは、このユーザーがデータベース所有者権限を持っている必要があることです。

次に、ログの操作方法を選択します。 たとえば、 完全復旧モードのデータベースがある場合、trankitログが非常に便利です。 または、トランザクションログを別のスケジュールでバックアップして、データベースを適切な時間にすばやくロールバックし、バックアップ間にあったすべてを失わないようにすることができます。 もちろん、ログに対しては何もできません。

Scheduleの最後から2番目のポイントに進み 、お客様の要件に応じてスケジュールを設定します。 誰かが1日1回、誰かが1時間1回、それはあなた次第です。

[ 適用 ]を数回クリックしてタスクを完了し、結果を楽しみます。

理想的な世界では、クラスターとVeeam Server間のリンクとして機能するエージェントをインストールするトリックがない場合、またはエージェントに必要なライセンスをロードするのを突然忘れた場合、ジョブは完全に機能し、次の図が表示されます。

以上です。 バックアップクラスタは、考えるのが常であるほど怖くないことがわかりました。 別のクラスター内のクラスターであっても。

別のバックアップ/レストランのシナリオについて知りたい場合は、コメントでそれを書いてください。可能な限り最善の方法ですべてをお伝えします。