SQLバックアップで「バックアップ整合性の検証」をオフにすることの影響/リスクを理解する

現在、環境内のSQL Server 2005/2008 / 2008R2 / 2012サーバーでのバックアップには標準のメンテナンスプランを使用しており、[バックアップの整合性の確認]ボックスは常にオンになっています。

バックアップの一部は非常に長時間実行されるため、このオプションをオフにすることをお勧めしますが、管理者はこの変更の影響とリスクを文書化する必要があります。

このオプションの使用と履歴を理解していますが、（私の意見では）発生する可能性のあるエラーが検証中ではなくバックアップステップ中に発生する場合、バックアップジョブの時間を2倍にする必要はありません。

私が間違っている？ストリーミングテープなどではなくディスクにバックアップする場合、これをオフにすることは最小限のリスクですか？（必要に応じて、ネットワーク経由でEMC DD-800バックアップアプライアンスにバックアップします。）

これをオフにしても安全な場合の公式のMS推奨事項はありますか？

環境内のすべてのバックアップで「検証」を実行していますか？それらをスポットチェックしますか？

編集：明確にするために、メンテナンスプランで[バックアップの整合性の検証]をチェックすると、SQLは各バックアップの直後に各データベースで完全な復元を行います。これは、元のバックアップと同様にデータ/ IOを集中的に使用し、（基本的に）バックアップジョブの全体的な時間を2倍にします。これは、ありません（私の知る限り、ウィザードで行うことができない）、バックアップの「チェックサム」オプションを有効にすると同じ。

私が間違っている？ストリーミングテープなどではなくディスクにバックアップする場合、これをオフにすることは最小限のリスクですか？

いいえ、あなたは正しいです:-)

RESTORE VERIFYONLY破損した場合にデータベースを回復できることを保証するだけではありません。本来、整合性チェックは実行されません。

より良い方法は、定期的にバックアップを取り、別のサーバーで有効な復元を実行し、そのサーバーでDBCC CHECKDBを実行することです。

これは、GUIがT-SQLで実現できるような多くのオプションを公開しないため、メンテナンスプランの大ファンではない理由の1つですbackup .. with CHECKSUM。

ポールランダルの神話ブログ

24p）RESTORE…WITH VERIFYONLYを使用してバックアップ全体を検証します

いいえ。VERIFYONLYを使用すると、バックアップヘッダーがバックアップヘッダーのように見えることのみが検証されます。それはあなたがWITH CHECKSUMを使用してバックアップを取り、RESTOREない場合にのみ、... WITH VERIFYONLYだ と、復元はバックアップ全体にわたるチェックサムを含むより広範なチェックが、ないことWITH CHECKSUMを使用します。

環境内のすべてのバックアップで「検証」を実行していますか？それらをスポットチェックしますか？

VERIFYONLYを実行しません。代わりに、CHECKSUMを使用してバックアップを作成し、それらを別のサーバーでCHECKDBして復元します。創造的になりたい場合は、データベースバックアップを検証するための統計サンプリングのアプローチに従うことができます 。

これは、バックアップで「チェックサム」オプションを有効にすることとは異なります（私の知る限り、ウィザードでは実行できません）。

オプションがBACKUPコマンドに対して自動的に有効になるように、トレースフラグ3023を有効にすることができCHECKSUMます。いつものように、環境内のトレースフラグの動作をテストしてください！

一番下の行は-メンテナンスプランを捨て、より賢明なバックアップソリューション （ヒント：Olaのバックアップソリューション）を使用します。これにより、ニーズに基づいてカスタマイズできます。

（必要に応じて、ネットワーク経由でEMC DD-800バックアップアプライアンスにバックアップします。）

ディスクにローカルでバックアップしてから、サーバーからネットワーク共有（バックアップサーバー）にバックアップをローカルにコピーするPowerShell転送ジョブを実行します。ネットワーク共有に直接コピーするよりも高速です。

また、ファイルの即時初期化を有効にします。これは、データファイルの自動成長に役立ち、復元時間の短縮に役立ちます（データベースを復元する必要がある場合）。オプションがあると便利です。

良い読み物は次のとおりです。バックアップ：回復戦略の計画

結論としては、どこかでデータベースの復元を行わない限り、特定のバックアップファイルが適切であると完全に確信することはできません。

バックアップを検証する理想的なテストは、日々のプロセスの一部としてデータベースバックアップとデータベースログバックアップが常に復元される環境をセットアップすることです。これは、ログ配布を使用する利点の1つです...

それでもverifyonlyに固執したい場合は、これを行うためだけに環境をセットアップできます。これにより、（おそらく）実稼働サーバーから作業がオフロードされ、ジョブ時間が短縮されます。

最後に、メンテナンス計画からの移行を検討しましたか？Olaのスクリプトのようなスクリプトは、バックアップとメンテナンスを除きます：https : //ola.hallengren.com/

技術的には、verfyonlyの復元は復元の実行に似ていますが、データベースを実際に復元して有効なバックアップをチェックするより良いチェックはありません。verifyonlyが成功したが、破損のためにデータベースが復元されないインスタンスがありました。私の意見では、バックアップが正常であることの検証としてこれを期待していません。現在、すべてのデータベースを別のインスタンスに復元してその有効性を確認するシステムを開発しました。明らかにそれが常に可能であるとは限らないため、特定のデータベースを1週間サンプリングしてみてください。longとshortは、verifyonlyを100％信頼していません。