第 2 回 「バックアップについて」～ システム管理 ～

NEC
Eラーニング事業部
鈴木 智行

2002 年 4 月 16 日

目次

2.1. バックアップの種類と復旧モデルの関係
2.2.フル（全体）データベースバックアップとトランザクションログの切り捨て
2.3. トランザクションログバックアップ
2.4. 差分バックアップ
2.5. ファイルとファイルグループのバックアップ
2.6. 復旧モデルとバックアッププロセスの選択

2.1. バックアップの種類と復旧モデルの関係

コンピュータシステムにおいて、障害が発生する可能性を否定することはできません。たとえば不慮または故意のデータ改ざん、プログラムの実行エラー、自然災害などが発生しデータが壊される、最悪の場合はデータが紛失する、といったケースも考えられます。

これらの障害はいくらフォールトトレランス機能を実装しても防ぐことはできません。したがって壊れたデータを現状に復帰するためには、最低限"データをとっておく"（バックアップ）作業が定期的に必要になります。大変な作業に思えるかもしれませんが、SQL Server 2000ではアクティブオンラインバックアップが可能であり、いちいち MSSQLServer サービスを停止して実行する必要はなく、運用時間中に実現できます。またジョブとしてバックアップタスクを登録しておけば、SQL Server エージェントと連携することによって、管理者がいちいち介入しなくても定期的に SQL Server 2000 が自動バックアップします。

バックアップ方法は以下の4種類が用意されており、データベースのサイズや更新頻度およびビジネス環境に基づいてバックアップ方法を組み合わせて、最適なバックアップを実現できます。しかしこれらのバックアップ方法は第 1 回で紹介したデータベースの復旧モデルによって制限されるので注意が必要です。

表 2-1-1 バックアップの種類と復旧モデルの関係

画面 2-1-2 フル復旧モデルでのバックアップ（全てのバックアップ種類が可能）

画面 2-1-3 シンプル復旧モデルでのバックアップ（一部のバックアップ種類が可能）

2.2.フル（全体）データベースバックアップとトランザクションログの切り捨て

フル（全体）データベースバックアップとトランザクションログの切り捨て　フルデータベースバックアップは基本的にデータベースのデータを全てコピーしますが、それだけではなくバックアッププロセス中に実行されたトランザクション情報をバックアッププロセスの開始時の LSN と終了時の LSN を利用して、トランザクションログからコピーします。このためフルデータベースバックアップはバックアッププロセスが終了した時点のデータの整合性を保証できます。

フルデータベースバックアップは以下のようなケースで使用してください。

• データベースのサイズが小さい場合

• データベースが読み取り専用または変更が少ない場合

• 他のバックアップ方法と組み合わせてバックアップを実現するときのベースラインを作成する場合

フルデータベースバックアップはトランザクションログ（正確には最小復旧 LSN より前にあるトランザクションログ）は削除しません。したがって復旧モードをフルあるいは一括ログ記録で設定している場合には、コミットされてデータが確定した不必要なログは管理者が削除する必要があります。この作業をログの切り捨てといいます。

ログの切り捨ては backup log ステートメントに no_log あるいは truncate_only オプション付きで実行します（画面 2-2-1）。no_log オプションと truncate_only オプションを使っても違いはありません。SQL Server 6.5 以前では意味が異なっていましたが、現在は下位互換性のために提供されているだけです。

画面 2-2-1 トランザクションログを切り捨てる

ログの切り捨て作業ではトランザクションログファイルのサイズが物理的に減少することはありません。トランザクションログに（正確には仮想ログ単位で）非アクティブのマークを付けるだけです。

この非アクティブの領域は再利用されますが、もし物理的にサイズを減少したい場合は、トランザクションログファイルの圧縮操作を行ってください（画面 2-2-2）。そうすればトランザクションログファイルのサイズが物理的に減少します。（画面2-2-3）。

画面 2-2-2 トランザクションログファイルを圧縮する（データベースの圧縮）

画面 2-2-3 トランザクションログファイルを圧縮した結果

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

トランザクションログバックアップはトランザクションログをバックアップして、データベースの変更記録をコピーします。少なくとも 1 回はベースラインとなるフルデータベースバックアップを行わないとトランザクションログバックアップを利用してデータベースを復元することはできません（画面 2-3-1）し、2.1 で紹介したとおり復旧モードがシンプルの場合はトランザクションログのバックアップはできません（画面 2-1-3）。

画面 2-3-1 フルデータベースバックアップを行っていない場合のエラーメッセージ

トランザクションログバックアップは以下のようなケースで使用してください。

• データベースのサイズが大きく、フルデータベースバックアップのみでバックアップを計画できない場合

• データベースが頻繁に更新される場合

• 障害の発生時点や特定の時点および名前付きログマークまで復元したい場合

第 1 回で説明したとおり復旧モードが一括ログ記録の場合には、一括操作に使用されるログ領域は最小限にとどめられます。しかし SQL Server では一括操作でどのエクステントが修正されたかを一括変更マップ（BCM） と呼ばれるページで管理しているため、一括操作を完全に復旧することができます。ただし一括操作自体は完全なログとして記録しないので、特定の時点への復元はできません（画面 2-3-2）。

画面 2-3-2 特定の時点への復元ができない場合のエラーメッセージ

フルデータベースバックアップとは異なり、トランザクションログバックアップは最小復旧LSNより前にあるトランザクションログを自動的に削除します。したがってある程度の間隔で、バックアップ計画に組み込んでおけば、トランザクションログが容量を圧迫することはありません。

2.4. 差分バックアップ

差分バックアップは最後のフルデータベースバックアップ以降に変更されたデータベースの変更部分（正確にはエクステント）をコピーします。少なくとも 1 回はベースラインとなるフルデータベースバックアップを行わないと差分バックアップを実行することはできません（画面2-4-1）

画面 2-4-1 フルデータベースバックアップを行っていない場合のエラーメッセージ

またフルデータベースバックアップ同様、トランザクションログ内のコミットされていないトランザクション、および差分バックアッププロセス中に実行されたアクティビティもバックアップするため、バックアッププロセスが終了した時点のデータの整合性を保証できます。

差分バックアップは以下のようなケースで使用してください。

• データベースのサイズが大きく、フルデータベースバックアップのみでバックアップを計画できない場合（特に復旧モードがシンプルの場合）

• 同じデータが何回も変更される場合

• バックアップや復元での時間を節約したり、手順を簡単にしたい場合

差分バックアップでは最後のフルデータベースバックアップ以降、どのエクステントが修正されたかを差分変更マップ （DCM） と呼ばれるページで管理し、中間の変更操作自体は記録しません。したがって 2.1 で紹介したとおり復旧モードがシンプルの場合にも実行できますが、特定の時点への復元はできません。

2.5. ファイルとファイルグループのバックアップ

ファイルとファイルグループのバックアップはファイルまたはファイルグループ単位でバックアップして、データベースの一部をコピーします。しかし、フルデータベースバックアップや差分データベースバックアップとは異なり、トランザクションログのどの部分もバックアップしないので、他のファイルやファイルグループとの整合性をとるために、トランザクションログバックアップが必須になります。したがって 2.1 でも紹介しましたが、復旧モードがシンプルの場合はファイルとファイルグループのバックアップはできません（画面 2-1-3）。

ファイルとファイルグループのバックアップは以下のようなケースで使用してください。

• データベースのサイズが特に大きく、フルデータベースバックアップに時間がかかり、業務上計画できない場合

• ファイルグループ単位でデータ管理をしていて、局所化した障害に対処したい場合

ファイルとファイルグループのバックアップでは、テーブルのインデックスが複数のファイル グループにわたっている場合、テーブルとそのインデックスが格納されたすべてのファイル グループは一緒にバックアップし、トランザクション ログのバックアップを作成する必要があります。このようなバックアップを行わないと、インデックスの一部だけがバックアップされ、後でバックアップを復元するときインデックスを復旧できない場合があります。クラスタ化インデックスの場合はデータとインデックスが必ず同じファイルグループに存在するので特に上記の問題は発生しませんが、非クラスタ化インデックスの場合はインデックスをデータと異なるファイルグループに作成可能（画面 2-5-1）なので注意が必要です。

画面 2-5-1 **　非クラスタ化インデックスを指定のファイルグループ上に作成する**

2.6. 復旧モデルとバックアッププロセスの選択

第 1 回でご紹介したとおり、ログのスペース要件だけ考えればデータベース復旧モデルとしてシンプルモデルを選ぶことが管理者にとって運用上、一番簡単な方法です。しかし上記のとおりシンプルモデルではトランザクションログバックアップが実現できないため、障害発生時点までデータベースを復旧することは不可能です。この状況はデータベース内のデータの重大度が非常に大きい場合、業務に多大な影響を及ぼすことになるかもしれません。この他にもデータベースをスムーズに運用するための必要要件は、業務システムをとりまく環境によって様々であり、どの復旧モデルとバックアッププロセスの組み合わせが正しい選択だとは一概にいえません。

ただし、個人的には復元要件を第一に考えるべきだと思っています。データベースをどの状態に、どのくらいの最低時間で復元するかを考えて、それを満たすバックアッププロセスの組み合わせを選択します。そうすればバックアッププロセスが実行可能な復旧モデルが選択でき、ログのスペース要件に応じて、必要であればトランザクションログを切り捨て／圧縮の管理タスクを運用に組み込み、最終的なバックアップ運用計画を作成することができます。

以下の 5 パターンを挙げてみましたので参考にしてください。

パターン１　フルデータベース／トランザクションログバックアップの組み合わせ

図 2-6-1 フルデータベース／トランザクションログバックアップの組み合わせ

パターン２　フルデータベース／トランザクションログ／差分バックアップの組み合わせ

図 2-6-2 フルデータベース／トランザクションログ／差分バックアップの組み合わせ

パターン３　フルデータベース／差分バックアップの組み合わせ

図 2-6-3 フルデータベース／差分バックアップの組み合わせ

パターン４　フルデータベースのみ

図 2-6-4 フルデータベースのみ

パターン５　ファイルグループ／トランザクションログバックアップの組み合わせ

図 2-6-5 ファイルグループ／トランザクションログバックアップの組み合わせ

優先順位は高くないかもしれませんが、復元要件はデータベースの復旧モデルとバックアッププロセスの BEST な選択にとって必要となるはずです。

次回はこのデータベースの復元に関してとりあげていきたいと思います。

鈴木   智行 : NEC Eラーニング事業部に所属。 入社以来、インストラクタとして教育業務に従事。汎用機、UNIX を経て、1994 年より マイクロソフト認定トレーナー (MCT) として、管理者向け教育を担当。SQL Server は 4.21a から携わっており、現在は主に SQL Server 2000 に関わるデータベース教育を中心に担当。Windows 2000 および SQL Server 2000 での MCSA, MCSE, MCDBA を取得しており、情報処理技術者試験のテクニカルエンジニア （データベース） も取得済。最近は MCA の 3 科目 （データベース、OS／ネットワーク、アプリケーション構築） 全てに合格し、C# を勉強中。