ホーム  >  SQLServer / データベース

わかりやすい SQL Serverのバックアップと復元方法

ちょっと、古い内容になりますが、バックアップファイルの出力形式、バックアップの種類、バックアップ処理、圧縮方法、バックアップ流れについて記載しています。

目次
  1. バックアップファイルの出力形式
  2. バックアップの種類
  3. バックアップ処理の流れ
  4. バックアップメディアの破損
  5. バックアップファイルの圧縮
  6. backup/restore以外のバックアップ

バックアップファイルの出力形式

SQL Serverのバックアップファイルには、「MTF(MicrosoftTapeFormat)形式」と呼ばれる磁気テープへ出力するためのフォーマットが採用されています。おそらく、ディスクの価格が今ほどに低くなく、データベースのバックアップはテープに出力して保管しておくことが当たり前だった時代の名残りだと考えられます。
MTF形式は、Windowsオペレーティングシステムがテープにバックアップを行なう際にも使用されています。そのため、SQLServerのバックアップファイルと、Windowsオペレーティングシステムに付属しているNTBackupユーティリティで取得したバックアップは、同じテープの中に共存できます。また、バックアップファイルをディスクへ出力する場合であっても、テープと同じフォーマットが使用されています。

データベースの完全バックアップ

メディアヘッダーデータセット
開始ブロック		SQL Server
設定情報		SQL Server
データストリーム		SQL Server
ログストリーム		データセット
終了ブロック		メディア
終了

バックアップファイルの内容

SQLServerのバックアップファイルはMTF形式に準拠するために、バックアップの開始部分と終了部分にMTF形式用の管理情報を含んでいます。それらの管理情報に挟まれる形で、データベース内のデータやトランザクションログが格納されています。ここではデータベースの完全バックアップを例にして、バックアップファイルの実際の中身の概要を紹介します(図1)。

メディアヘッダー

MTF形式のバックアップに必要となるバックアップファイルの管理情報を格納するための領域です。バックアップファイルのラベルやバックアップファイル出力時のブロックサイズ、パスワード保護をしている場合にはパスワードなどが書き込まれます。

データセット開始ブロック

MTF形式に準拠した実際のバックアップ対象のデータが、これ以降の領域に格納されることを示します。

SQLServer設定情報

バックアップ対象のデータベースの管理情報が格納される領域です。格納される
情報は次のとおりです。
●データベース名
●データベースID
●サーバー名
●データベース互換性レベル
●照合順序

SQLServerデータストリーム

データベースのデータファイル内の使用されている領域が、エクステント単位で格納されます。

SQLServerログストリーム

データベースのログファイルが仮想ログファイルごとに格納されます。

データセット終了ブロック

MTF形式での、実際のバックアップ対象のデータが格納されている領域の終了点を示します。

メディア終了

MTF形式のバックアップファイルの終了ポイントを示します。

バックアップの種類

SQL Serverにはいくつかの種類のバックアップ方式が用意されています。

完全バックアップ

すべての割り当て済みのエクステントとトランザクションログの一部をバックアップします。完全バックアップ実行時にはすべてのGAMページ注2がスキャンされ、割り当て済みのバックアップすべきエクステントが判別されます。また、DCMペオージ3のビットがクリアされます。さらに、バックアップが実行されている期間に行なわれたデータベースへの更新処理の変更分もバックアップに含めるため、バックアップ開始時からバックアップ終了までの期間のトランザクションログのバックアップも一緒に取得されます。

差分バックアップ

完全バックアップを取得した後に、変更が行なわれたエクステント分のみをバックアップします。差分バックアップ実行時にはDCMがスキャンされ、バックアップが必要なエクステントを特定します。また、完全バックアップと同様に、バックアップ実行中のトランザクションログのバックアップが取得されます。

ファイルバックアップ

データベースの任意のファイルのみのバックアップです。完全バックアップと同様に割り当て済みエクステントとトランザクションログの一部をバックアップします。また、ファイル内に存在するDCMのクリアも行ないます。

ファイル差分バックアップ

データベース内の任意のファイルのみに対して行なう差分バックアップです。DCMを使用して、変更されたエクステントだけがバックアップされます。それ以外の点もデータベース差分バックアップと同様です。

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

物理ログファイル内の仮想ログファイルを、順次バックアップします。もしもデータベースが一括ログモデルを選択していた場合は、一括操作が行なわれたエクステントもバックアップに含まれます。一括操作が行なわれたエクステントはBCMページ注4で確認します。

バックアップ処理の流れ

バックアップを実行した際に、内部的に行なわれている処理を紹介します。

1、GAMを使用してデータベースファイルをスキャンする

図1

図1
図1

２，データベースファイルが複数存在する場合は、すべての読込は並列で処理される

・各データベースファイルで並列に処理される

図2

図2

3，割り当て済みのテクステントを、物理的な並び順で読み込む

割り当て済みエクステントを順次スキャン

図3

図3

４，読み込んだエクステントをバックアップファイルに転送する

図4

図4

５，バックアップファイルが複数存在する場合は、並列で処理される

図5

図5

それ以外にも、バックアップ処理ではさまざまな作業が行なわれています。いくつかは並行で実行され、またいくつかはシリアルで実行されます。それらの中で代表的な処理をいくつか紹介します。

  • バッファキャッシュ上のダーティページをフラッシュするために、チェックポイント処理を実行する。このチェックポイント処理の実行には、データファイル上のデータとバッファキャッシュ上のデータの差異を少なくする効果がある。
  • 次回のバックアップのために必要な情報を、バックアップファイルのヘッダーに書き込む
  • msdbシステムデータベースのバックアップ履歴を更新する。msdbシステムデ
    ータベースのバックアップ関連の情報を格納するテーブルには、各データベースに対して実行したバックアップの種類や履歴情報が格納されている

1、ディスクに変更が反映されていないデータがキャッシュ上にダーティページとして存在する

２，このままでは、バックアップ対象のデータベースファイルとの差異が大きい

３，バックアップ前にチェックポイントによってダーティページをディスクにフラッシュ

４，バッファキャッシュとデータベースファイルの差異がなくなり最新のバックアップが可能になる。

バックアップメディアの破損

データベースに何らかの問題が発生したときのためにバックアップを用意しているわけですが、そのバックアップが破損していることもあります。次に代表的な2つの発生原因と予防措置を記載します。

データベース自体が壊れている

バックアップを取得するデータベースが壊れていると、当然それを基に作成されるバックアップも破損した状態になります。これは、定期的にdbcc checkdbコマンドでデータベースの整合性を確認していない場合に陥りがちな問題です。定期的にdbcccheckdbを行なっていないと、数世代分のデータベースバックアップを持っていたとしても、どの時点で破損が発生していたのか判断できなくなります。そのため、直近のバックアップを復元して破損が発覚した場合、一世代前のバックアップを復元したとしても同じ問題が発生する可能性があります。


一方、予防措置は非常にシンプルです。データベースのバックアップを実行する前に、必ずdbcc checkdbを実行してください。その際に整合性のエラーが検出されなければ、これからバックアップしようとしているデータベースはクリーンな状態であると確認できます。

バックアップファイルの生成時にエラーが発生している

データベースのバックアップ実行時に、バックアップファイルの出力先メディア（ディスクやテープなど)の不良によって、正しい内容でバックアップファイルの生成が行なわれないことがあります。正しく生成されなかったバックアップファイルは、当然のことながら正しく復元することができず、障害発生時の対策とはなり得ません。
有効な予防措置としては、バックアップチェックサムの使用が挙げられます。バックアップ実行時に、バックアップファイルに出力されるデータを基にチェックサム値を生成し、バックアップファイルのヘッダーに格納します。格納した値と、実際のバックアップファイルの内容を比較することで、生成したファイルの妥当性を検証できます(図9)。
backupコマンドを、checksumオプションとともに実行するためのコマンドシンタックスは次のとおりです。

backup database N'データベース名'
to disk=N'バックアップファイルのフルバス'
with checksum

checksumオプションを指定すると、バックアップ時にデータベースの検証も行なうため、システムに与える負荷が大きくなります。そのため、デフォルトではオフに指定されています。しかし、バックアップファイルの内容の正当性を確認することは、システムの安定運用にとても重要な意味を持ちます。そのため、バックア
ップ実行時には、可能な限りchecksumオプションを指定することをお勧めします。

破損したバックアップファイルからの復元

何らかの原因でバックアップファイルが破損してしまった場合、どのような対処が考えられるでしょうか。ひと口にバックアップファイルの破損と言っても、バックアップファイルを保存していたディスクやテープ自体に物理的にアクセスできないような障害や、アクセスは可能でもバックアップファイルの内容に一部不正な箇所が含まれるような障害もあります。
前者のようなハードウェア障害の場合は、SQL Serverでは対処できません。後者の場合もSQL Server 2000までは、破損したバックアップファイルに存在している正常な部分のデータを救済するための手段は存在しませんでした。しかし、SQL Server 2005からは、たとえ破損している箇所があったとしても、利用できる部分に関してはデータを使用可能にするための機能が実装されました。
具体的には、復元の実行時にデータの不整合が検出されると、SQL Server 2000までは復元を停止してしまい、バックアップからの復旧が行なわれませんでした。SQL Server 2005以降でもデフォルトの動作は同じですが、次の例のようCONTINUE_AFTER_ERRORオプションを指定することによって、破損が検出された後も復元処理を継続します。この実装によって、少なくともバックアップファイル内の使用可能なデータにはアクセスができるようになりました。

restore database データベース名
from disk=N'バックアップファイルのフルパス'
with CONTINUE_AFTER_ERROR

障害発生時にはとても利用価値の高い機能ですが、いくつか念頭に置いてほしい点があります。1つ目は消失したページに関しての懸念です。破損個所をスキップして復元を継続するということは、データベース内にページの欠落が発生することを意味します。必要なページが存在しないため、そのページに含まれていたデータは消失し、データベース内のページ間のリンクも整合性がとれない状態になっています。そのため、何らかの対処が必要となります。

図B

2つ目は不整合からの復旧方法についてです。復旧方法の基本はdbcc checkdbコマンドです。このコマンドを実行することによって破損の発生箇所や破損範囲を特定して、必要な対処を検討します。実際に必要となる対処に関しては、前章で詳しく紹介しました。多くの場合、修復オプション付きのdbcc checkdbコマンドや、インデックスの再作成といった対処が必要になります。
なお、それらの対処を実施しても復旧できない場合には、select intoコマンドなどを使用して使用可能なデータのみを一時データベースや外部ファイルへ抜き出し、欠落したデータに関しては手動で再作成するなどの対処が必要です。そのような状況に陥らないために、バックアップの出力メディアやバックアップファイルの内容の正当性などには、十分な注意を払うことがとても重要となります。

バックアップファイルの圧縮

データベースのバックアップファイルのサイズは、バックアップ対象となったデータベースのサイズ(データファイルとログファイルのサイズの合計値)よりも小さいことがほとんどです。SQL Server 2005までのバックアップ機能は、特に圧縮を行なっているわけではありません。GAMページを確認しながら、単純に使用済みのエクステントをバックアップファイルへ書き出しているのみです。そのため、データベースのサイズに対して格納しているデータ量が少ないと、データベースサイズとバックアップファイルのサイズの差異は大きくなります。一方、データベースの使用率が100%に近づくほど、両者のサイズも近づくことになります。（図10）

データベース内の使用領域が少ない場合

図10

データベース内の使用領域が多い場合

図10

ここまでは、SQL Server 2005までの話です。SQL Server 2008からは、EnterpriseとDeveloperの両エディションでバックアップファイルの圧縮機能が実装されています。圧縮機能のメリットは、まずバックアップファイルのサイズ自体が従来よりも小さくなることです。ファイルサイズが小さいということは、ディスクI/Oに必要な時間が短くて済むことを意味し、データベースバックアップ時のファイルの書き出しや、バックアップファイルからの復元の際のディスクI/Oに必要となる時間がより短くなります。
ただし、バックアップファイルへの圧縮時や、圧縮されたバックアップファイルからの復元時には、これまでよりも多くのCPUリソースを消費する可能性が高くなると考えられます。そのため、圧縮操作を伴うデータベースのバックアップを導入する際には、考慮すべき点があります。例えば、これまでバックアップと同時間帯に実行していた処理がある場合、処理完了までに要する時間が長くなる可能性があります。そのようなときには、双方の処理の開始時間などの調整が必要になります。

backup/restore以外のバックアップ

データベースのバックアップを保持する手段は、backup/restoreコマンド以外にも存在します。ここでは、その一例であるデータベースファイルのコピーを記載します。
データベースの実体であるデータファイル(.mdfファイル)/ログファイル(ldfファイル)をコピーしておき、データベースのバックアップとして使用します。データベースに障害が発生した場合には、問題のあるデータベースをsp_detach_dbを実行してデタッチし、コピーしてあったファイルをsp_attach_dbを使用してアタッチします。これにはbackup/restoreコマンドと比較した場合に、次のような利点と注意点があります。

利点

  • ほとんどの場合、restore databaseコマンドよりもアタッチのほうが復旧のために必要な時間が少なくて済む
  • ほとんどの場合、backup databaseコマンドよりもデータベースファイルのコビーのほうがバックアップのために必要な時間が短くて済む

注意点

データベースファイルをコピーする際に、データベースをオフラインにする必要がある。backup databaseコマンドと比較すると、必要なディスク領域が大きくなる可能性がある（backup databaseコマンドは未使用の領域はバックアップしないため）

カテゴリー:SQLServer​データベース