IT部門は毎晩サーバー全体をバックアップし（SQL Serverインスタンスがこのサーバーにインストールされています）、何か問題が発生した場合に備えて、サーバー全体とネットワーク全体をバックアップします...
それで、私のマネージャーは、IT部門がバックアップするものに対して、フル、差分、およびログSQLバックアップの重要性を尋ねました。これらのファイルを2週間保持して削除するのではなく、サーバーのスペースを節約するために、IT部門が提供するだけだと考えています。
私はそれが正しくないことを知っています。ログバックアップで過去30分間まで復元できるため、ITは翌日にそれを復元しますが、これが唯一の違いですか？
データベースバックアップファイルを同じサーバーに保存/送信するので、ITはそれらを復元しますが、メンテナンスプランにこれらのバックアップジョブがない場合、テーブル、トランザクションなしでSQLインスタンスを復元できます...等私はこれを正しくしていますか？
何かアドバイスをいただければ幸いです。
回答:
データベースのバックアップにより、ポイントインタイムの復元機能が提供されます（FULL復旧モデルがある場合）。IT担当者が数分ごとにバックアップを取っても、それは非常にまれですが、それでもギャップが生じます。
サーバーバックアップはデータベースバックアップに取って代わるものではありません。データベースバックアップファイルを長期間（つまり、今日だけではなく）アーカイブすることで、データベースバックアップを補完します。
結局、あなたとあなたの管理者はあなたのRPO（リカバリポイントの目標-クラッシュでどれだけ回復できる必要があるか）を決定しなければなりません。毎日のサーバーバックアップのみが行われ、データベースバックアップは行われないため、最悪の場合、丸一日の作業が失われる可能性があります。
編集：@Stingは、シャドウコピー（サーバーバックアップを作成するために使用される可能性が最も高いメカニズム）がすべてのデータベースファイル（ログファイルを含む）の正確な同時コピーを取得する可能性が低いという点で有効です。バックアップを復元します。たとえば、シャドウコピーがデータベースファイルを読み取る数ミリ秒前にトランザクションログを読み取る場合、データベースファイルにはコミットされていないトランザクションが含まれる可能性がありますが、トランザクションが1ミリ秒後にコミットされたため、ログにはそのレコードが記録されません。
シャドウコピーからのmdfおよびldfファイルの復元がトランザクション的に一貫しない可能性があります。つまり、これらのシャドウリストアはデータベースのACIDプロパティに準拠していません。
https://msdn.microsoft.com/en-us/library/aa480356.aspx
おそらく復元は機能しますが、実際に何が得られるのか疑問に思われるでしょう。（言うまでもなく、サーバーのバックアップ/シャドウコピーがすべてのサーバーで適切に動作することを確認するテストが必要です）さらに、SQL Server Tを使用できるように、トランザクションログを特定の時点に復元する方法はありません。 -SQL RESTORE LOG / STOPAT。
Windows Serverのバックアップ/復元がSQL Server ACIDテストに準拠するまで、私たちの業界はチャンスを逃す余裕はありません。
このことをすべて言っても、私はいくつかの奇妙な会議に参加しました。問題をIT部門に伝えても問題がIT担当者に気付かれないようであるか、リスクを取る意思がある場合、肩から大きな負担が取り除かれます。何が起こっても、会議の議事録をすべての人が決定した内容と、なぜ誰もが決定したのかを文書化して、会議の出席者に送信します。
これはすべて、IT部門がサーバーレベルのバックアップに使用している製品によって異なります。
たとえば、仮想環境では、VMWareがサーバーのスナップショットを取得します。SQL Serverが関与している場合、VMWareには、ほとんどの管理者が有効にするオプション（またはデフォルトではわからない）があり、スナップショット中にデータベースのIOがフリーズします。これは数秒しかかからないはずですが、アプリケーションに問題を引き起こす可能性があり、データベースを復元するための信頼できる方法ではありません。
サードパーティ製品を使用してサーバーレベルのバックアップを実行している場合は、データベースのファイルレベルのバックアップを取得している可能性があります。その点でも、SQL ServerにはWindowsの観点からロックされた添付のmdfファイルとldfファイルがあるため、ロックされているファイルのバックアップを作成する機能が必要です。たとえば、シマンテックのBackupExecはAdvanced Open File Optionを使用してこれを実行するため、基本的にはロックされたファイルの写真を撮ることができます。そのようなバックアップを使用してデータベースを復元しなければならない場合、ほとんどのDBAはほとんどのDBAをうんざりさせるように、データベースがそのバックアップを取るときの一貫性について考えます。データロードプロセスの実行中にバックアップが実行された場合、保証はありません。そのバックアップは、データロードのどの部分を取得しましたか？
SQL Serverのネイティブバックアップは、適切なバックアップとして検証されるという点で信頼できます。FULLのバックアップを実行したときの状態を正確に把握できます。これは、データの読み込みなどに関してスケジュールされているかどうかです。完全復旧モデルのログバックアップでは、そのデータベースを2番目に復元できます。
あなたのマネージャーがサーバーレベルのバックアップの使用に夢中になっている場合、私は彼らが使用している製品を徹底的に調査します。データベースのVDIバックアップを実行するために購入できるSQL Serverの「アドオン」またはバックアップエージェントがあるかどうかを確認します。
SQL Serverのバックアップが失敗した場合の検証とトラブルシューティングには、マネージャーとの検討および検討が必要です。以前のジョブでNetbackupを頻繁に使用しており、数年前のクライアントに、NetbackupのSQL Serverエージェントの環境での使用をテストすることを望んでいました。これには、サポートも提供する必要がある他のDBAが含まれます。SQL Serverのバックアップ失敗のトラブルシューティングには、Netbackupについて少し知っておく必要があると前もって言った。通常、NetbackupマスターサーバーはUnixサーバーで実行されるため、いくつかのUnixを知っておく必要があります。検討すべきことの1つであり、マネージャーとの良い話し合いのポイントになり、障害のトラブルシューティングの責任者を見つけます。
質問には100万個未満の変数しかありません。IT部門とどのようなバックアップを取るかについて話し合う必要があります。ほとんどの場合、利用できるバックアップは、分単位まで可能です。それらをロードするのにかかる時間は、より多くの変数に依存します。
完璧なシナリオでは、IT部門は、異なる場所にある1つ以上の異なるサーバーにバックアップを保持しています。データベースが置かれているサーバーと同じサーバーにバックアップを保持している可能性があります。そのため、サーバーが停止した場合や建物が焼失した場合、IT部門はおそらくファイルを復元できますが、実行したバックアップはサーバーとともに失われます。
しかし、あなたはいつでも、あなたのサーバがまだ生きている提供、あなたの速度で、バックアップを復元することができます。
他の人が言ったように、それはあなたのニーズが何であるか、リスクに対する許容度、そして回復時間の制御がいかに重要であるかに依存します。あなたがやった愚かなことから回復したいなら、あなたのバックアップはより速く、より良くなるでしょう。制御不能な災害から回復したい場合は、ITバックアップ（推奨）をお勧めします。