毎週の完全バックアップと毎日のトランザクションログバックアップのみであるSQLServerバックアップ戦略のリスクは何ですか？
SQLServerのバックアップ戦略が不十分であることをクライアントに納得させようとしています。簡単に言うと、現在のバックアップの「戦略」は、毎週の完全バックアップとそれに続く毎日のトランザクションログバックアップです。データベースのサイズが大きいため、複数の毎日のトランザクションログバックアップを伴う毎日の完全バックアップ戦略に切り替えるか、少なくともすでに実行されているものに毎日の差分バックアップを追加する必要があることをクライアントにすでにアドバイスしました。ただし、これは、すでに持っているよりもはるかに多くのドライブスペースを必要とするため、これに悩まされています。だから、私の質問は-毎週の完全バックアップと毎日のトランザクションログバックアップだけであるバックアップ戦略のために提示される可能性のある潜在的な問題またはリスクは何ですか？完全バックアップが復元された後、t-log復元は各トランザクションを再実行する必要があるため、主にデータベースの復元に数時間または数日かかる場合がありますか？
サイズ設定とアクティビティコンテキストのデータベースの仕様は次のとおりです。
- 使用されるデータベーススペース：約12.5GB
- 1週間分のトランザクションログバックアップ：合計サイズが約400MBの7つのTRNファイル
- 毎週のインデックス再作成後のトランザクションログバックアップ：約3GB
彼らのバックアップ戦略はあなたの意見によって推進されるべきではなく、彼らの目標復旧時点と目標復旧時間によって推進されるべきです。クライアントとその話し合いをしてから、それらの目的を満たすバックアップ戦略を実装します。
そうは言っても、あなたが言及した量とサイズのデータベースとトランザクションログの復元に数分以上かかったとしたら、私は非常に驚きます。それは確かに数時間または数日かかることはありません。
私の最大の関心事は、実際にはトランザクションログのバックアップです。スケジュールされたt-logバックアップの5分前にデータベースを失うと、24時間近くのデータが失われる可能性があります。
より頻繁なログバックアップはそれほど多くのスペースを必要としないはずです-それ以上のトランザクションはありません。より良い復元ポイントを許可する必要があります。
（いいえ、12.5GBのデータベースで復元を実行するのに数日はかかりません。）
この状況での差分の主な利点は、ログバックアップファイルの数が扱いにくいことに気付く可能性があることです。毎週のフルバックアップと毎時のトランザクションログバックアップを実行している場合、それは1日24ファイルです。完全なログバックアップの5分前と最後のログバックアップの55分後にデータベースを失った場合、55分を失う可能性があり、167のログバックアップが必要になります（これらは異なるファイルであると想定しています）。毎晩の差で、彼らは23だけを必要とするでしょう。
（55分が長すぎて失うことができないと判断した場合は、トランザクションログをより頻繁にバックアップし、それに応じてファイル数を増やします。）