トランザクションログをバックアップすることがなぜそれほど重要なのですか？

現在、クライアント向けのバックアップソリューションを実装しており、ERPソリューションではSQL Serverを使用しています。

ERPソリューションは別の会社によってセットアップされました。そして、彼らはトランザクションログをバックアップして切り捨てることが非常に重要だと私に言っています。

私はこのトランザクションログを少し読んでいますが、なぜこれがそんなに重要なのか分かりません とにかくマシン全体をすでにバックアップしているときにわかりません（SQL Serverを認識して使用するArcServe UDPを使用していますVSS）。SQL Server VMのクリーンアップタスクが既にログの切り捨てを処理していることは理解していますが、UDPではSQL Serverログの切り捨ても許可されています。

トランザクションログは、すべてのトランザクションのログであるため、破損したデータベースの復元に使用できることを理解しています。しかし、私はすでにデータベース全体の1時間ごとのバックアップを持っているので、なぜ気にする必要があるのでしょうか？

DBリカバリモードが「フル」に設定されている場合にのみ、これを行う必要があります。「シンプル」に設定されている場合、トランザクションログのバックアップを作成する必要はありません。ただし、これら2つのオプションの違いに注意してください！

まず第一に：特定の時点まで DBを復元できるようにするには、「フル」モードを使用する必要があります。（タイミングを非常に正確に調整できるので、復元ポイントのミリ秒も指定できると思います）「シンプル」モードでは、最後の完全バックアップにのみ戻ることができます。

トランザクションログのバックアップ/切り捨てを行わない場合、全体の時間（フルモード）で成長します。.trnファイルがデータベース自体の2倍以上の大きさのデータベースを見ました。これは、DBに変更が加えられた頻度に依存します。

もう1つのポイントは、ログバックアップは通常、完全バックアップよりも高速であることです。

したがって、1時間ごとに完全バックアップを作成するバックアップ計画は最適ではないと思います。ただし、状況によって異なります。

あなたが言う場合：DBを最後の1時間に復元できるなら、すべては大丈夫です。->また、1時間ごとに完全バックアップを保持する場合は、回復モードを「単純」に設定することも検討できます。

私の意見では、早朝に完全バックアップを作成してから、1時間ごとにトランザクションログのバックアップを行うことをお勧めします。それははるかに高速である必要があり、必要な時点に復元することができます。また、.trnファイルはあまり大きくなりません...

お役に立てれば。

上手。回復モデルをフルに設定し、SQLのバックアップ（サーバーバックアップではなく）を使用してトランザクションログをバックアップしない場合、トランザクションログは利用可能なすべてのディスク領域を消費するまで拡大し続けるため、注意が必要です。（以前、同僚がシステムドライブにSQL Serverをインストールし、トランザクションログをバックアップしなかったのを見ました。Windowsを食べました。）

はい、特定の時点に復元されます。分まで。Twinklesが言うように、はい、人々はテーブルなどを落とします。

データベース全体の1時間ごとのバックアップに何を使用しているのか、また、それがマシン全体に使用しているのと同じ製品であるかどうかはわかりません。その場合、非SQL対応のバックアップソリューションはリストアにサポートされません。たとえば、VSSがMDFおよびLDFファイルをコピーするのにかかる時間は、内部タイムスタンプの不一致を引き起こす可能性があります。

複数のERPシステムも管理しています。そして問題は、多くの場合、夜間に他のシステムとデータを同期する長時間実行されるバッチジョブがあることです。そして、時には1時間以上かかります。したがって、クラッシュが発生した場合にやりたいことは、一貫性のあるデータがある場所にジャンプすることです。（これは、2つのバッチジョブ間で正しいことを意味します。）時刻だけを見ると、この時点でデータベースの状態が正確にわからない場合があります。

しかし、もちろん状況によって異なります。自動化されたジョブなどがない場合は、1時間ごとのバックアップでまったく問題ありません。

これを行う理由はいくつかあります。

1. 通常、データベースシステムはビジー状態で、1秒あたり数千のトランザクションを実行している可能性があります。データは、異なるファイルシステム上の複数のファイルに分散している可能性があります。復元後にデータベースが一貫した（別名使用可能な）状態にあることを確認するのは簡単ではありません。バックアップソリューションがタスクに任されている場合は素晴らしいですが、仕事に賭ける前にこれを確認する方が良いでしょう。
2. 例：誰かが重要なデータを含むテーブルを誤って削除した。ポイントインタイムリカバリ機能を備えたデータベースバックアップがある場合、システム全体を復元することなく、データをすばやく復元できます。
3. データベースが完全復旧モードの場合、SQL Serverのトランザクションログが大きくなります。トランザクションログのストレージ領域は、トランザクションログがバックアップされている場合にのみ再利用されます。トランザクションログを定期的にバックアップしないと、スペースがなくなるまでファイルシステムがいっぱいになります。新しいトランザクションは開始できないため、この時点ですべてが直ちに停止します。

データベースが1時間でバックアップできる容量を超えた場合、別のモデルが必要になります。

データベースの完全バックアップではログが切り捨てられますが、「SQL対応」である必要があります。そのシナリオでは、バックアップソフトウェアがSQL Serverに何をバックアップし、何を切り捨てるかを伝えるためです。

他の人が言及するように、「完全」復旧モデルのデータベースがある場合、完全なSQL対応バックアップを作成するまで、トランザクションログは無期限に増大します。

ここでは、バックアップではなく回復が本当に問題です。そして、それは技術的な決定ではなく、ビジネス上の決定です！

ビジネスオーナーが1時間以上データベーストランザクションを失うことに問題がない場合（やり直しが非常に困難または不可能な場合があります）、モデルは機能します。バックアップからデータベース全体を復元するときにシステムが数時間ダウンしても問題ない場合、モデルは機能します。

ただし、ビジネスでERPシステムを運用上の重要な資産と見なしている場合（すべてではありませんか？）、重要なサービスの最大許容回復時間（RTO、回復時間目標）を設定することがビジネス上の決定になります。

また、ビジネス所有者またはシステムの利害関係者は、インシデント（RPO（Recovery Point Objective）とも呼ばれる）で損失を被るリスクのあるデータの量を定義する必要があります。

「データを失うことはありません！ERPシステムは24時間365日利用できる必要があります！」...費用対効果が高いとは限りません。このような完全に冗長なノンストップシステムの構築に関連するコストを提示すると、より合理的な数値が算出されます。;）

重要なのは、トランザクションの損失を避けることができれば、ビジネスを数百または数千の労働時間を節約できる可能性があるということです。それはどの会社でも大きな節約になり、会社の規模に応じて成長します...

誰もがこれに対して素晴らしい反応を示しましたが、別の重要なメモを追加したいと思います... 1、2。

SQL Server復旧モデルの詳細とデータ損失に関するビジネス要件を知ることは非常に重要です。ただし、この場合、バックアップ製品がSQL Serverでどのように機能するかを理解することが不可欠です。（上記のコメントに基づいて、VSSコピーを介してディスクボリュームをバックアップしているように思われます。これは、SQL Serverのバックアップが追加で必要かどうかを意味します。）

同様の製品を最近評価したので、質問する必要がある重要なポイントのいくつかは次のとおりです。

• 完全復旧のデータベースの特定の時点までの復元はどのように実行されますか？
• 完全復旧で新しいデータベースの初期バックアップはどのように処理されますか？
• バックアップ製品は、特定の時点に復元するためにSQL Serverログバックアップを必要としますか？（私の場合、答えはイエスでした。）
• ストレージインフラストラクチャは、通常のSQL負荷に加えて、VSSコピー/差分のデータ量を（一定の間隔で）処理できますか？

これがお役に立てば幸いです。

私のチームが最近の評価で得た経験は、上記の質問に対する非常に興味深い答えを提供しました。確かなことの1つは、VSSバックアップ製品を使用した場合、バックアップがより複雑になることです。

他の多くの人がすでに言っているように、VMまたはストレージのいずれかをバックアップ/スナップショットするためにサードパーティのツールを使用している場合、有効なバックアップがないというリスクがあります。SQL Serverバックアップを管理するすべてのサードパーティツールは、VSSを使用してSQL Serverを実装および接続します。これは、SQL ServerがデータファイルへのすべてのI / Oを静止し、一貫性のあるスナップショットを取得できるように要求するためです。そうでない場合は、さまざまな状態の多くのトランザクションを持つことができ、それらのトランザクションをロールフォワードまたはロールバックできるかどうかは復元でわかりません。

サードパーティ製のVM /ストレージスナップショットツールをすべて使用したことはありませんが、システムデータベースが存在するストレージのスナップショットを作成できませんでした。SQLServerはそれらのデータベースを静止できません。それらはすべて、これらのデータベースをストリーム方式でバックアップしました。つまり、BACKUP DATABASEコマンドを発行してから、バックアップファイル自体をスナップしました。

それに加えて、多くの人が言っているように、完全復旧モデルを使用していて、BACKUP LOGステートメントを定期的に発行しない場合、ディスクに空きがなくなるまでトランザクションログは増大し続けます。

あなたが尋ねる必要がある本当の質問、そして私は上でそれを見逃しているかもしれません...あなたはこれらのバックアップから何度も正常に復元しましたか、そしてそれらの復元のデータの一貫性に満足しています。個人的には、それでも私には十分ではありませんが、それはサイコロのロールのように感じられ、それはバックアップとリカバリに関しては優れたDBAが決してとらないことです。

トランザクションログは単なる回復メカニズムではないことを認識してください。適切なログメンテナンスは、データベース全体のパフォーマンス（トランザクションスループットなど）でも重要な役割を果たします。

ログファイルを頻繁にバックアップすると、いくつかのことが行われます。

1. 物理ログファイルのVLFカウントが減少し、パフォーマンスが向上します。
2. データベースを回復する必要がある場合に、ログバックアップを使用する準備が整います。
3. 完全バックアップよりもかなり高速です

1時間ごとにフルバックアップを実行しても問題がなければ、ログバックアップをより頻繁に行うことでどれだけの利益が得られるかはわかりません。結局のところ、完全バックアップでは、完全な復元を保証するために必要なだけのログもバックアップされます。

一方、アプリが1時間ごとのフルバックアップの間に大量のトランザクションを生成する場合、元の開発者がよりきめ細かいログメンテナンスを提案した理由を説明できます。多くのトランザクションにより、ログのVLFカウントが増加し、ログが切り捨てられるまでパフォーマンスが低下する可能性があります。これは、アプリケーション内で（クエリタイムアウトの期限切れ）エラー（ハングする直前）として表されるのを見てきました。

トランザクションログのメンテナンスに関連する推奨事項については、この記事「トランザクションログスループットを向上させるための8つの手順」で詳しく説明しています。さらに、この記事の「効果的なデータベースメンテナンスのヒント」では、狙いを定めるためのやや任意のVLFカウント（<200）について言及していますが、これは私にとって非常にうまく機能しています。

他の人は、トランスログバックアップなどの理由のほとんどをすでに示しています。すでにサーバーをバックアップしているとき、これがなぜ良い戦略であるかについては疑問があるようです。

上記以外のいくつかの理由があります。サードパーティアプリがバックアップの取得に失敗した場合、復元できますか？バックアップを復元しようとしましたか？テンプレートから構築したばかりの新しいサーバーについてはどうですか（DRを考えてください）。異なる照合順序を持つドメイン上の別のサーバーについてはどうですか？またはSQLインスタンス？

サードパーティのアプリが復元の最速の方法ではない場合があること以外は、理由なしに冗長バックアップを取ります。サードパーティアプリが保存しているストレージも影響を受けたり、独自の理由で破損したりする場合があります。