完全復旧モデルでのバックアップ

更新 : 2006 年 7 月 17 日

完全復旧モデルでは、広範な障害シナリオでデータの損失を防ぐためログ バックアップを使用するので、トランザクション ログのバックアップと復元 (ログ バックアップ) が必要です。ログ バックアップを使用する利点は、ログ バックアップに含まれる任意の時点にデータベースを復元 (特定の時点に復旧) できることです。災害が発生した後でアクティブなログをバックアップできれば、データを損失しないで障害の発生時点までデータベースを復元できます。ログ バックアップを使用することの欠点は、そのためのストレージ領域が必要で、復旧に時間がかかり、複雑になることです。

ms190217.note(ja-jp,SQL.90).gifメモ :
ログ バックアップを使用する利点によって、バックアップの管理のコストが正当化されない場合は、単純復旧モデルを使用することをお勧めします。

通常は完全復旧モデルを使用するデータベースの場合、一括ログ復旧モデルを一時的に使用することで、特定の一括操作を最適化できます。一括ログ復旧モデルには、操作を毎日行うには不向きな制限事項がいくつかあります。詳細については、「一括ログ復旧モデルでのバックアップ」を参照してください。

サンプル バックアップ方法

次の図に、完全復旧モデルで最も簡単なバックアップ方法を示します。この図では、データベース バックアップ Db_1、および 2 つの定期的なログ バックアップ Log_1 と Log_2 が行われています。Log_2 ログ バックアップ後のいずれかの時点で、データベースでデータの損失が発生します。データベース管理者は、これら 3 つのバックアップを復元する前に、アクティブ ログ (ログ末尾) のバックアップを行う必要があります。その後、データベースを復旧しないで Db_1、Log_1、および Log_2 を復元します。次に、ログ末尾のバックアップ (末尾) を復元および復旧します。これにより、障害が発生した時点までデータベースが復旧され、すべてのデータが復旧されます。

完全復旧モデルのデータベースの復元

作業損失の可能性の最小化

最初にデータベースの完全バックアップを完了し、定期的なログ バックアップを開始しておけば、作業損失の可能性は、最新の定期的なログ バックアップからデータベースが破損した時点までの間に限定されます。したがって、作業損失の可能性がビジネス要件として許容される範囲に収まるように、十分な頻度でログ バックアップを行うことをお勧めします。

障害が発生したら、ログ末尾 (まだバックアップされていないログ) のバックアップを試みることができます。ログの末尾のバックアップが成功した場合、障害発生時点までデータベースを復元することにより、作業内容の損失を防ぐことができます。

一連のログ バックアップを使用すると、いずれかのログ バックアップの含まれている任意の時点まで、データベースをロールフォワードできます。危険性を最小限に抑えるためには、定期的なログ バックアップをスケジュールすることをお勧めします。復元時間を最小限に抑えるために、各完全バックアップは同じデータの一連の差分バックアップで補完することができます。

次の図に、データベースの完全バックアップを、データベースの差分バックアップおよび定期的なログ バックアップによって補完するバックアップ方法を示します。トランザクション ログ バックアップを使用することで、作業損失の可能性は、最新のログ バックアップ以降の時間に制限できます。最初のデータベース バックアップの後で、3 回の差分バックアップを実行します。3 回目の差分バックアップは大きくなるため、次のバックアップをデータベースの完全バックアップにします。このバックアップによって新しい差分ベースが作成されます。

データベース バックアップ (完全および差分) とログ バックアップ

この図に示す最初のデータベース バックアップの前 (図の t0 から t1 の間) では、データベースに対する作業が失われる可能性があります。それ以降は、定期的なログ バックアップを行うことで、損失する可能性のある作業範囲が、最新のログ バックアップ (この図では t14 に実行) 以降に行われた変更のみに限定されます。障害が発生した場合、データベース管理者は直ちにアクティブ ログ (ログの末尾) のバックアップを試みる必要があります。このログ末尾のバックアップが成功した場合、データベースを障害発生時点まで復元できます。

一括操作および完全復旧モデル

完全復旧モデルでは、SELECT INTO、CREATE INDEX、データの一括読み込みなどの一括操作を含めた、すべての操作をログ記録することにより、障害が発生した時点または障害発生以前の時点までデータベースを復旧できます (これを特定の時点に復元と呼びます)。

データを失うリスクよりも、データの一括読み込みとパフォーマンスの向上を優先するときは、多くの場合、完全復旧モデルから一時的に一括ログ復旧モデルに切り替えます。一括ログ復旧モデルでは、一括操作のログ記録が最小限に抑えられます。ただし、他のトランザクションは完全にログ記録されます。一括ログ復旧モデルの詳細については、「一括ログ復旧モデルでのバックアップ」を参照してください。

ms190217.note(ja-jp,SQL.90).gifメモ :
SQL Server 2000 以降のバージョンでは、sp_dboptionselect into/bulkcopy データベース オプションを使用すると、復旧モデルが BULK_LOGGED にリセットされます。SQL Server 2000 では、このオプションは SELECT INTO でパーマネント テーブルを作成するために必要です。一方、SQL Server 2005 ではこのオプションが必要なくなったため、使用は避けてください。代わりに ALTER DATABASE を使用してください。このsp_dboption ストアド プロシージャは、将来のバージョンの SQL Server では削除される予定です。

バックアップを使用したデータベースの復元

データベースを復元するには、一連の復元操作 (復元シーケンス) を実行する必要があります。復元シーケンスでは、まず少なくとも 1 つの完全バックアップを復元し、必要に応じて対応する差分バックアップを復元します。

完全バックアップと差分バックアップにはそれぞれ、データベースを復旧するのに十分なログ レコードが含まれています。ただし、通常は連続したログ バックアップを順番に復元し、存在する場合はログ末尾のバックアップで終了します。したがって、データベースの復元を開始する前に、ログ末尾のバックアップを作成する必要があります。ログ末尾のバックアップを使用することで、障害発生時点までデータベースを復元することが可能になります。最後のログ バックアップを復元したら、データベースを復旧する必要があります。

ms190217.note(ja-jp,SQL.90).gifメモ :
完全復旧モデルまたは一括ログ復旧モデルを使用する場合、SQL Server 2005 Enterprise Edition では、データベースをオンラインにしたまま、ファイル、ページ、またはその両方の復元を行えます。これをオンライン復元と呼びます。ファイルまたはページを復元する RESTORE の構文は、データベースがオフラインでもオンラインでも同じです。

詳細については、「SQL Server での復元と復旧の概要」を参照してください。

参照

概念

バックアップ デバイス
マークされたトランザクションの使用 (完全復旧モデル)
SQL Server での復元と復旧の概要
完全復旧モデルまたは一括ログ復旧モデルからの切り替えに関する注意点

その他の技術情報

トランザクション ログの理解と管理
差分バックアップの使用

ヘルプおよび情報

SQL Server 2005 の参考資料の入手

変更履歴

リリース 履歴

2006 年 7 月 17 日

変更内容 :

2005 年 12 月 5 日

変更内容 :
  • 旧版の「完全復旧の概要」を組み込みました。
  • 図を追加しました。