次の方法で共有

  • [アーティクル]

トランザクション ログのバックアップ

このトピックは、完全復旧モデルまたは一括ログ復旧モデルを使用するデータベースのみに関連しています。

このトピックでは、トランザクション ログのバックアップと復元 (適用) の方法について説明します。完全復旧モデルと一括ログ復旧モデルでは、データを復旧するためにトランザクション ログを定期的にバックアップすること (ログ バックアップ) が必要不可欠です。SQL Server 2005 以降のバージョンでは、完全バックアップの実行中でもログをバックアップできます。

最初のログ バックアップを作成する前に、データベース バックアップや一連のファイル バックアップの最初のバックアップを行って、完全バックアップを作成する必要があります。ファイル バックアップだけを使ったデータベースの復元は複雑になる可能性があります。したがって、可能な時点でデータベースの完全バックアップを行うことから始めることをお勧めします。その後、トランザクション ログを定期的にバックアップする必要があります。その結果、作業損失の可能性が最小限に抑えられるだけでなく、トランザクション ログの切り捨ても可能になります。一般に、トランザクション ログは、通常のログ バックアップ後に毎回切り捨てられます。ただし、ログの切り捨ては遅らせることができます。詳細については、「ログの切り捨てが遅れる原因となる要因」を参照してください。

ログ バックアップは、ビジネス要件に対応するために十分な頻度で作成することをお勧めします。特に、ログ ドライブに障害が起こった場合に生じる作業損失に対する許容範囲を考慮してください。ログ バックアップを行う適切な頻度は、作業損失に対する許容範囲と、ログ バックアップを保存、管理、復元できる量とのバランスによります。15 分から 30 分間隔でログ バックアップを行えば十分でしょう。業務上、作業損失の可能性を最小限に抑えることが求められる場合は、ログ バックアップの頻度を増やすことを検討します。ログ バックアップの頻度を増やせば、ログ切り捨ての頻度も高くなり、ログ ファイルが小さくなる利点もあります。

復元する必要があるログ バックアップの数を制限するには、定期的なデータのバックアップが不可欠です。たとえば、データベースの完全バックアップを毎週実行し、差分バックアップを毎日実行するようにスケジュールできます。

注意注意

既定では、バックアップ操作が成功するたびに、SQL Server エラー ログおよびシステム イベント ログにエントリが 1 つ追加されます。ログを頻繁にバックアップすると、これらの成功メッセージがすぐに蓄積され、他のメッセージを探すのが困難になるほどエラー ログが大きくなることがあります。そのような場合、これらのエントリに依存するスクリプトがなければ、トレース フラグ 3226 を使用することによってこれらのログ エントリを除外できます。詳細については、「トレース フラグ (Transact-SQL)」を参照してください。

ログ チェーン

ログ バックアップの連続的なシーケンスを、ログ チェーンと呼びます。ログ チェーンは、データベースの完全バックアップから始まります。通常、新しいログ チェーンが開始されるのは、データベースが最初にバックアップされたとき、または復旧モデルを単純復旧から完全復旧または一括ログ復旧に変更したときだけです。

データベースの完全バックアップの作成時に既存のバックアップ セットを上書きしない限り、既存のログ チェーンはそのまま残ります。ログ チェーンがそのまま残っている場合は、メディア セット内にあるデータベースの完全バックアップからデータベースを復元し、その後で復旧ポイントに達するまで後続のログ バックアップをすべて復元できます。復旧ポイントは、最後のログ バックアップの末尾、または任意のログ バックアップの特定の復旧ポイントである場合があります。

データベースを障害の発生時点まで復元するには、ログ チェーンが途切れていないことが条件になります。つまり、トランザクション ログ バックアップのシーケンスは、障害の発生時点まで途切れずに続いている必要があります。ログのシーケンスの始まりは、復元するデータ バックアップの種類 (データベース バックアップ、部分バックアップ、ファイル バックアップ) によって異なります。データベース バックアップまたは部分バックアップの場合、ログ バックアップのシーケンスはデータベース バックアップまたは部分バックアップの最後から始まっている必要があります。一連のファイル バックアップの場合、ログ バックアップのシーケンスはファイル バックアップの完全なセットから始まっている必要があります。

ファイル バックアップのみを使用している場合は、最初の完全ファイル バックアップの始めからログをバックアップする必要があります。最初の完全ファイル バックアップの直後にログのバックアップを開始できます。最初のログ バックアップには時間かかるため、このような開始方法をお勧めします。ログのバックアップを行っている間に、他のファイルをバックアップします。データベースをファイル バックアップのみから復元するには、最初のバックアップから最新のバックアップまでの間をカバーする 1 つ以上のログ バックアップを使用して、完全ファイル バックアップのセットを補完する必要があります。

注意注意

一連のバックアップの中でログ チェーンの先頭のバックアップを識別するには、backupset テーブルの begins_log_chain 列に対してクエリを行うか、バックアップ デバイスに対して RESTORE HEADERONLY を実行して、結果セット内の BeginsLogChain 列を参照してください。

トランザクション ログ バックアップは、定期的に行うことが必要です。ログ バックアップでは、バックアップされたトランザクションを復元できるだけでなく、ログを切り捨ててバックアップされたログ レコードをログ ファイルから削除できます。ログのバックアップ頻度が適切でないと、ログ ファイルがいっぱいになることがあります。トランザクション ログがいっぱいになった場合の処理方法の詳細については、「満杯になったトランザクション ログのトラブルシューティング (エラー 9002)」を参照してください。

重要な注意事項重要

ログ バックアップが見つからないか破損している場合は、新しいログ チェーンを開始します。この操作を行うには、データベースの完全バックアップまたはデータベースの差分バックアップを作成し、トランザクション ログをバックアップしてから、新しいログ チェーンを開始します。なくなったログ バックアップより前の時点にデータベースを復元する場合に備えて、そのログ バックアップより前のトランザクション ログ バックアップは保持しておくことをお勧めします。バックアップの保護方法の詳細については、「バックアップと復元のセキュリティについての考慮事項」を参照してください。

ログ バックアップの作成方法の詳細については、「トランザクション ログ バックアップの作成」および「ログ末尾のバックアップ」を参照してください。

ログ バックアップの使用方法

ログ バックアップを復元すると、トランザクション ログに記録された変更がロールフォワードされ、ログ バックアップ操作が開始された時点のデータベースの正確な状態が再現されます。データベースを復元するときは、復元するデータベースの完全バックアップ後に作成されたログ バックアップを復元するか、復元する最初のファイル バックアップの先頭からログ バックアップを復元する必要があります。通常、最新のデータまたは差分バックアップを復元した後、復旧ポイントに到達するまで一連のログ バックアップを復元する必要があります。その後、データベースを復旧します。その結果、復旧を開始したときに不完全だったトランザクションがすべてロールバックされ、データベースがオンラインになります。データベースが復旧された後は、それ以上バックアップを復元できません。

重要な注意事項重要

オフライン復旧前、または障害発生後の作業損失を防ぐには、ログ末尾をバックアップして、まだバックアップされていないすべてのログ レコードをキャプチャすることをお勧めします。詳細については、「ログ末尾のバックアップ」を参照してください。

トランザクション ログ バックアップの適用.