この質問のフォローアップとして、あなたの SQL Server のバックアップ/メンテナンス計画はどのようなもので、どのようにすればそれを改善できるのか知りたいです。
現在、プラン ウィザードから 2 つのプレーン ジェーン メンテナンス プランを実行しています。
最初のものは毎晩実行され、ほぼすべてのことを行います...
もう 1 つは 3 時間ごとに実行され、増分バックアップを行います (私は偏執的ですが、これはおそらくやり過ぎだと思います)。
バックアップはディスクに、フル バックアップは SAN に送信され、1 週間保持されます。
どう思いますか、これは賢明な計画ですか？助言がありますか？
編集: これは SQL Server 2005 です。DB は 5 GB で、1 か月あたり約 1 GB 増加します。
かなりいいですね。私はもっと妄想的です。毎日 2 回の完全バックアップと、1 時間ごとのトランザクション ログ バックアップを行っています。データベースまたはコースのサイズによって異なります。バックアップはディスクに直接行われ、夜間にテープにバックアップされます。
おそらく、毎日メンテナンス タスクを実行する必要はありません。毎晩インデックスを再作成するこの 1 つのテーブルを除いて、私は週末にのみそれらを行います。繰り返しますが、これはデータベースのサイズとアクティビティによって異なります。
CPU とディスクの空き容量が十分にある場合は、ディスク バックアップを圧縮して容量を節約し、テープや他の場所への転送を高速化できます。
ユーザー/顧客/データ管理者と話す必要があります。彼らは、どれだけの仕事を失う可能性があるかを明確に理解する必要があります。SLA がない場合は作成します。悪いニュースに関しては、驚きを望んでいません。
また、復元には時間がかかることも理解する必要があります。回復計画を立てて、許容できる復元時間を作成する必要があります。これは、毎日の完全バックアップ、4 つの差分、5 分ごとのログ バックアップを意味する場合があります。マーカス・エリクソンが言ったように、これはクレイジーでも偏執的でもありません。すべては、あなたの情報と、あなたの組織がそれにかける金銭的価値にかかっています。
3 時間ごとにバックアップを実行することに神経質になっているとは思いません。基本的に、バックアップ計画は復元要件によって測定する必要があります。回復中にどれくらいダウンしても許容できる時間と、ダウンする前に失っても構わないと思っているデータの量。SQL Server の場合、バックアップ プランにトランザクション ログ バックアップを追加することで、失われても構わないと思っているデータの量を大幅に減らすことができます。多くの人は、システムを通過するトランザクションの量に応じて、これらを数分ごとに実行します。復元を行うには、最後の完全バックアップ、最後の増分バックアップ、および増分以降のすべてのトランザクション ログ バックアップを復元するだけです。これにより、データの損失を最小限に抑えることができますが、すべてのトランザクション ログ バックアップを適用するには少し時間がかかる場合があります。私はかなり定期的に次のことを目にします。
私が顧客に推奨する最低限のことは、データベースの完全バックアップを毎晩実行してから、3時間ごとにトランザクションバックアップを実行することです。バックアップを設定しない人の数にはいつも驚かされます。それらは常に悪い呼び出しです。
作成したバックアップから（テストシステムに）実際に復元しようとする場所で、ファイアドリルを行うことを忘れないでください。これは、おそらく月に 1 回行う必要があります。
私の意見では、最良の方法は次のとおりです。
12 時間ごとにデータベースの完全バックアップを作成する
BACKUP DATABASE database TO DISK = 'd:/full.bak'
6 時間ごとの差分バックアップ。障害が発生した場合に、プロセスの復元が容易になります。
BACKUP DATABASE database TO DISK = 'd:/diff.bak' WITH DIFFERENTIAL
もちろん、1 時間ごとに作成する方がよいトランザクション ログのバックアップも必要です。
BACKUP LOG database TO DISK = 'log.bak'
障害が発生した場合、回復プロセスは次のようになります。
ポイント イン タイム リカバリを利用できるようにするには、完全復旧モデルを使用する方がよいことを認めなければなりません。