VM高ワークロードSQL Serverのバックアップをスキップしますか？
非常に大量のトランザクションワークロード（非常に高いデータ変更率）でSQL Serverを仮想化したユーザーにとって、VMバックアップをどのように処理するか、またはそれらを実行するかどうかに興味があります。
もちろん、トランザクション的に一貫性のあるネイティブデータベースバックアップのチェーンを個別に管理しています。ただし、仮想化レベルの標準ポリシーは、常にすべてのVMをバックアップすることでした。これは現在、一般的なサードパーティを使用していますVMバックアップソリューション（開始VMスナップショット、スナップショットデータをバックアップアプライアンスにコピーし、スナップショットをリリースする）。ただし、これらのサーバーにはデータの変更率が非常に高いため、変更ファイルが非常に急速に大きくなり、システムは、スナップショットのリリース中にマージする必要のあるデータの量を制限するところに達しています。
VMバックアップを完全にスキップするという考えをもてあそんでいます。他のアプリをSQL Serverにインストールすることを許可していません。ベースOSとSQL設定はかなりバニラです。したがって、失敗したシナリオでは、テンプレートから新しいVMを展開し、SQLビットをインストールして、データベースのバックアップの復元を開始するだけで、それほど多くの時間はかかりません。
考え？代替？私が見落としている落とし穴？ご入力いただきありがとうございます。
1つのオプションは、ユーザーデータベースのデータファイルとログファイルを含むディスクを独立したディスクに設定することです。そのため、VMスナップショットバックアップにはこれらのディスクは含まれません。データベースのバックアップ戦略が適切である限り、VMバックアップにデータファイルとログファイルを含める必要はありません。もちろん、同じディスクにアプリケーションとデータベースファイルがインストールされている場合は、これができない場合があります。
ここで役立つことの1つは、VMバックアップに含まれる is のディスクの1つにマスター、モデル、およびmsdbを置くことです。これにより、VMバックアップが復元されるシステムデータベースを復元する必要はありません。これは少し面倒です。システムデータベースを移動するプロセスをスクリプト化しました SQL Serverシステムデータベースファイルを移動するスクリプト にあります。
このアプローチを使用する場合、VMバックアップを復元し、データベースファイル用のディスクとディレクトリを作成してから、データベースを復元する必要があるため、サーバーの復元にはある程度の作業が必要です。
このアプローチの副次的な利点は、ボリュームが非常に大きい場合（マルチテラバイト）、すべてのディスクのVMスナップショットは通常、サーバーを数秒間一時停止するため、この方法では効果的にそれを排除できます「見事な」効果。クラスター/可用性グループを使用している場合、一時停止によって可用性グループが少しオフラインになることがあります。
しない VMのバックアップを停止したい理由の1つは、新しいサーバーを構築したり、古いバックアップからOSを復元したりすると、すべてのWindows Updateをインストールするのに多くの時間が必要であり、これによりかなりのダウンタイムが生じる可能性があります。 VMテンプレート（または使用中のデプロイメント方法）が更新されている場合、これはもちろん問題にはなりません。