SQL Server 2005 の SQL ライタ :

SQL Server バックアップ アプリケーション ベンダ向けガイド

公開日: 2005年9月1日

Srini Acharya、Kangrong Yan、Mark Wistrom、Steve Schmidt

概要 : SQL Server 2005 では、ライタ (SQL ライタ) を提供することによって、ボリューム シャドウ コピー サービス (VSS) がサポートされます。その結果、サード パーティのバックアップ アプリケーションは VSS フレームワークを使用して、データベース ファイルをバックアップできます。この資料では SQL ライタ コンポーネントについて説明し、SQL Server データベースの VSS スナップショットの作成と復元プロセスにおける SQL ライタの役割について説明します。また、VSS フレームワーク内で SQL ライタとバックアップ アプリケーションが連携するための SQL ライタの構成方法と使用方法についても詳しく説明します。

トピック

はじめに
SQL ライタを構成する
バックアップ/復元操作とサポートされるバージョン
スナップショット作成プロセス
復元プロセス
バックアップと復元オプションの詳細
バックアップ
復元
バックアップ
ロールフォワードを伴なわない完全復元
追加のロールフォワードを伴う完全復元
部分ファイル情報の形式
ファイルのバックアップ
バックアップ時の注意事項
復元前フェーズ
ファイルの復元
復元後
OnIdentify
ベース タイムスタンプを設定する
差分バックアップ
差分バックアップ中のバックアップ アプリケーションの役割
差分復元中のバックアップ アプリケーションの役割
マルチデータベース トランザクション
自動復旧スナップショットのセキュリティ
データベースの自動終了
ファイルの一覧
停止中のインスタンス
システム データベース
単純復旧モデルのユーザー データベース
ユーザー データベースのロールフォワード
付録
関連資料

はじめに

Microsoft® SQL Server™ 2005 では、ボリューム シャドウ コピー サービス (VSS) を使用して、SQL Server データからスナップショットを作成できます。これは VSS 準拠のライタ (SQL ライタ) を用意することによって実現できます。その結果、サード パーティのバックアップ アプリケーションは VSS フレームワークを使用して、データベース ファイルをバックアップできます。この資料では SQL ライタ コンポーネントについて説明し、SQL Server データベースの VSS スナップショットの作成と復元プロセスにおける SQL ライタの役割について説明します。また、VSS フレームワークのコンテキスト内で SQL ライタとバックアップ アプリケーションが連携するための SQL ライタの構成方法と使用方法についても詳しく説明します。

用語の定義

仮想デバイス インターフェイス

SQL Server では、仮想デバイス インターフェイス (VDI) というアプリケーション プログラミング インターフェイスを用意しています。独立系ソフトウェア ベンダはこの VDI を使用してバックアップ操作と復元操作を提供することで、自社製品に SQL Server を統合できます。これらの API は信頼性やパフォーマンスを最大限に引き出すように設計されているので、一連のホット バックアップ機能やスナップショット バックアップ機能など、SQL Server のバックアップと復元のあらゆる機能がサポートされます。

詳細については、Microsoft Web サイトの「SQL Server 2000 Virtual Backup Device Interface Specification」(英語) を参照してください。

MSDE ライタ

既定の VSS ライタは、Microsoft® Windows® XP および Windows 2003 の VSS フレームワークに同梱されました。このライタは SQL Server 2000 以前のバージョンと連携して、バックアップ操作を行います。SQL Server 2005 をインストールした場合は、SQL ライタが推奨ライタになります。SQL ライタを有効にしていない場合は、引き続き MSDE ライタが機能し、既定のライタになります。

リクエスタ

1 つ以上の元のボリュームから 1 つ以上のスナップショットのセットを取得することを要求するプロセス (自動または GUI のいずれか)。この資料では、SQL Server データベースのスナップショットを作成しているバックアップ アプリケーションを表すためにリクエスタという用語を使用することもあります。

VSS について

VSS は、Windows システム上で VSS アプリケーションを実行するためのシステム インフラストラクチャを提供します。VSS では、ユーザーと開発者のどちらもほとんど意識することなく、次のことが行われます。

• シャドウ コピーの作成や使用の際に、プロバイダ、ライタ、およびリクエスタのアクティビティを調整します。

• 既定のシステム プロバイダを提供します。

• 任意のプロバイダが機能するのに必要な低レベルのドライバ機能を実装します。

VSS サービスは要求時に開始されるので、VSS 操作を正しく行うためにはこのサービスを有効にする必要があります。

VSS コンポーネント

VSS では、協調動作する次のコンポーネントのアクティビティが調整されます。

• プロバイダ - シャドウ コピー データを所有し、シャドウ コピーのインスタンスを作成します。

• ライタ - データを変更し、シャドウ コピー同期プロセスに参加するアプリケーションです。

• リクエスタ - シャドウ コピーの作成と破棄を開始します。ここでは、リクエスタがバックアップ アプリケーションであるシナリオに注目して説明します。

VSS では、これらのコンポーネント間の調整が行われます。

図 1

拡大表示する

図 1 に、一般的な VSS スナップショット操作に参加するすべてのコンポーネントを示します。このようなシナリオでは、SQL Server (SQL ライタを含む) は、図中の [ライタ] ボックスのライタの 1 つとして動作します。その他のライタには、Exchange Server などがあります。

この資料の後半部分は、読者が VSS フレームワークの用語に精通していることを前提としています。詳細については、「Volume Shadow Copy Service」(英語) のドキュメントを参照してください。

SQL ライタについて

SQL ライタは、SQL Server アプリケーションによって提供される VSS ライタです。このライタは、SQL Server と VSS の相互作用を扱います。SQL ライタは、SQL Server 2005 に同梱されるスタンドアロン サービスで、SQL Server のインストールの一環としてインストールされます。SQL ライタは既定では無効になっています。サーバー コンピュータ上で実行するには明示的に有効にする必要があります。

図 2 では、VSS スナップショット バックアップ操作での SQL ライタの役割を示します。

図 2

拡大表示する

SQL ライタを構成する

SQL ライタ サービスは SQL Server 2005 のインストールの一環としてシステムにインストールされますが、既定で開始されるようには設定されていません。SQL ライタを開始して使用するには、次の操作を行う必要があります。

• MSDE ライタが SQL Server 2005 データベースを列挙するのを無効にします。

• SQL ライタのサービス アカウントを構成します。

• SQL ライタ サービスを開始します。

MSDE ライタについて

Windows XP および Windows 2003 に同梱される VSS フレームワークには、SQL Server インスタンスと連携する既定のライタ (MSDE ライタ) があります。このライタではインストール済みの SQL Server データベースの基本的なバックアップ機能を提供しますが、SQL Server 2005 インスタンスで SQL ライタが提供するような差分バックアップやその他の高度なオプションに対する追加機能がありません。

SQL ライタは、この資料の「サポートされるバックアップ/復元操作」で説明する追加オプションが用意されているので、SQL Server 2005 インスタンスでデータベースをバックアップする場合の推奨ライタです。ただし、MSDE ライタも SQL Server 2005 と連携するので、次に説明するように SQL ライタを明示的に有効にしていない場合は、既定のライタとして動作します。

SQL Server 2005 インスタンスを無視するように MSDE ライタを構成する

SQL Server 2005 がインストールされても、SQL ライタは既定では有効になりません。この構成では、MSDE ライタが SQL Server 2005 のインスタンスも含めて、システム上のすべての SQL Server インスタンスの既定のライタとして動作します。SQL ライタを有効にする前に、MSDE ライタが SQL Server 2005 のインスタンスを無視するように構成する必要があります。これを行うには、次のレジストリ キーを設定します。

Key: HKLM\SYSTEM\CurrentControlSet\Services\VSS\Settings
Value: “MSDEVersionChecking” DWORD

このレジストリ値が 0 以外の値に設定されているときは (既定ではこのレジストリ値は存在せず、その場合は 0 に設定されていると解釈されます)、MSDE ライタはライタ メタデータ列挙フェーズ中にすべての SQL Server 2005 インスタンスを自動的に無視します。この設定では、MSDE ライタは無効になりません。MSDE ライタは、(存在すれば) システム上の旧バージョンの SQL Server のインスタンスの列挙を続け、そのインスタンスと連携します。

SQL ライタを無効にし、MSDE ライタを SQL Server 2005 と連携させるには、このレジストリ値を削除するか、0 に設定する必要があります (これは SQL Server 2005 のインストール時の既定の設定です)。

SQL ライタのサービス アカウントを構成する

SQL ライタのアカウントは、インストール時にローカル システム アカウントを使用するようにインストールされます。SQL ライタは VDI API だけを使用して SQL Server と対話する必要があるので、SQL ライタのアカウントには SQL Server と VSS の両方に対して十分なアクセス権が必要です。サービスがローカル システム アカウントを使用するように構成することで、サービスを適正に実行するのに必要な権限が許可されます。

SQL ライタを開始する

VSS アプリケーションからバックアップや復元を要求したときに正しく機能するには、その時点で SQL ライタ サービスが実行されている必要があります。SQL ライタ サービスを開始するには、[コントロール パネル]、[管理ツール] の順に開き、[サービス] ダイアログ ボックスを表示します。そのダイアログ ボックスで、SQL VSS Writer サービスを明示的に開始します。または、コマンド ラインから net start SQLwriter コマンドを使用して開始することもできます。

サーバーを起動するときにサービスを自動的に開始するように設定することをお勧めします。

バックアップ/復元操作とサポートされるバージョン

バージョン サポート

SQL ライタは SQL Server 2005 に同梱されており、SQL Server 2005 インスタンスのみをサポートします。旧バージョンの SQL Server インスタンスの場合は、MSDE ライタ (VSS フレームワークに同梱) が使用されます。

SQL ライタは、Windows 2003 プラットフォームと Windows XP でのみインストールおよびサポートされます。

SQL Express

SQL ライタでは SQL Server Express 2005 インスタンスも列挙されます。また、SQL Server Express から起動されたユーザー インスタンスも列挙されます。

サポートされるバックアップ/復元操作

SQL Server 2005 (SQL ライタを使用) では、VSS に基づくバックアップ操作で次のモードがサポートされます。

• 非コンポーネントベース

• コンポーネントベース

非コンポーネントベースのバックアップ操作

非コンポーネントベースのバックアップでは、スナップショット セット内のボリュームの一覧によってデータベースが自動的に選択されます。SQL ライタは欠落したデータベースをチェックし、見つかった場合はエラーを発生します。"欠落したデータベース" は、ボリュームの一覧で選択されるファイルのサブセットに含まれていて存在しないデータベースです。

非コンポーネントベース モデルでは、単純復旧モデルが設定されたデータベースのみがサポートされます。復元後のロールフォワードはサポートされません。

コンポーネントベースのバックアップ操作

コンポーネントベースのバックアップでは、SQL ライタから返されるメータデータからデータベースをアプリケーション (VSS バックアップ アプリケーション)で明示的に選択することになるので、このモードをお勧めします。スナップショット セットには、このようなデータベースをバックアップするのに必要なすべてのボリュームを含めます。VSS インフラストラクチャでは、選択したデータベースのセットに必要なボリュームが自動的に追加されることはありません。バックアップするすべてのボリュームは、ボリューム スナップショット セットに含まれている必要があります。バックアップするすべてのボリュームがスナップショット セットに含まれていることを確認するのは、バックアップ アプリケーションの役割です。SQL ライタが欠落したデータベースを検出した (バックアップするボリュームがスナップショットに含まれていない) 場合は、バックアップに失敗します。

この後の説明では、VSS スナップショット作成プロセスの一環として、コンポーネントベースのバックアップが使用されることを想定しています。

SQL ライタでサポートされるスナップショット操作

SQL ライタでは多くの機能強化が MSDE ライタに加えられましたが、特に以下の追加機能がサポートされるようになりました。

フルテキスト サポート : SQL ライタでは、ライタのメタデータ ドキュメント内のデータベース コンポーネントの下にファイルを再帰指定することで、フルテキスト カタログ コンテナが報告されます。フルテキスト カタログ コンテナは、データベース コンポーネントが選択されるときにバックアップ内に自動的に含められます。

差分バックアップ / 復元 : SQL ライタでは、"部分ファイル" と "最終更新時刻による差分ファイル" という 2 つの VSS 差分メカニズムにより、差分バックアップと復元がサポートされます。

• 部分ファイル - SQL ライタでは、データベース ファイル内で変更が加えられたバイト範囲を報告するために、VSS 部分ファイル メカニズムが使用されます。

• 最終更新時刻による差分ファイル - SQL ライタでは、フルテキスト カタログ内で変更が加えられたファイルを報告するために、最終更新時刻による差分ファイル メカニズムが使用されます。

移動を伴う復元 : SQL ライタでは、復元中に VSS の新しいターゲット指定がサポートされます。VSS の新しいターゲット指定では、復元操作の一環として、データベース ファイルやログ ファイル、またはフルテキスト カタログ コンテナを再配置できます。

データベース名の変更 : リクエスタでは、SQL データベースを新しい名前で復元することが必要な場合があります。たとえば、元のデータベースと並列にデータベースを復元する場合などです。SQL ライタでは、復元操作中にデータベース名の変更がサポートされます。

コピーのみのバックアップ : 場合によっては、特殊な目的にバックアップを行う必要があることがあります。たとえば、テスト目的にデータベースのコピーを作成する必要がある場合などです。このようなバックアップでは、データベースのバックアップと復元手順の全体に影響を与えてはいけません。COPY_ONLY オプションを使用することで、バックアップが "帯域外" で行われ、通常のバックアップ シーケンスには影響を及ぼしません。SQL ライタでは、SQL Server 2005 インスタンスを使って、"コピーのみ" のバックアップがサポートされます。

データベース スナップショットの自動復旧 : VSS フレームワークを使用することで取得される SQL Server データベースのスナップショットは、一般的に復旧されていない状態です。実行中のトランザクションをロールバックし、データベースを一貫性のある状態にする復旧フェーズを経なければ、スナップショット内のデータに安全にアクセスすることはできません。Windows 2003 SP1 上で実行されている SQL Server 2005 と VSS フレームワークにより、VSS バックアップ アプリケーションはスナップショット作成プロセスの一環として、スナップショットの自動復旧を要求できます。

これらの新機能とその使用法の詳細については、この資料の「バックアップと復元オプションの詳細」を参照してください。

サポートされない機能

• ログ バックアップ - SQL ライタではサポートされません。

• ファイルまたはファイル グループのバックアップ - サポートされません。

• ページ復元 - サポートされません。

次の表では、SQL ライタ/SQL Server 2005 を VSS フレームワークと連携させることによって、すべてのエディションの SQL Server 2005 でサポートされるスナップショット バックアップの種類を一覧します。

スナップショット作成プロセス

VSS フレームワークは、SQL Server スナップショット作成中にリクエスタ (バックアップ アプリケーション) と SQL ライタのアクティビティを調整します。VSS フレームワークでは、この調整を可能にするために、リクエスタとライタの各インターフェイスが定義されます。VSS に参加するリクエスタ アプリケーションとライタは、それぞれこれらのインターフェイスを実装する必要があります。SQL ライタは、必要なライタ インターフェイスを実装します。VSS フレームワークはスナップショット作成プロセスの一環として、SQL ライタのインターフェイスを呼び出します。SQL ライタはシステム上の SQL Server インスタンスと相互作用し、スナップショットの作成を容易にします。

VSS フレームワークでは、リクエスタ (バックアップ アプリケーション) で使用するための一連の API が定義されます。バックアップ アプリケーションの開発者は、VSS フレームワークのスナップショット作成プロセスと連携するために、これらの API の呼び出しパターンに従う必要があります。この後は、SQL ライタの観点からスナップショット作成プロセスについて説明します。また、リクエスタ、VSS フレームワーク、SQL ライタ、および SQL Server インスタンス間の内部相互作用の一部についても詳しく説明します。これらの手順と VSS フレームワーク インターフェイスの詳細については、「Volume Shadow Copy Service」(英語) のドキュメントを参照してください。

スナップショット作成ワークフロー

図 3 に、コンポーネントベースのスナップショットの作成とバックアップ操作中のデータの流れ図を示します。この概要を次のフェーズに細分化すると、バックアップが実行される際に関係する基本タスクをより深く理解できます。

• バックアップの初期化

• バックアップ検出フェーズ

• バックアップ前タスク

• ファイルの実際のバックアップ

• バックアップ終了

図 3

拡大表示する

バックアップの初期化

バックアップのこのフェーズでは、リクエスタ (バックアップ アプリケーション) からスナップショット インターフェイス IvssBackupComponents にバインドし、バックアップに備えてこのインターフェイスを初期化します。また、VSS API IVssGatherWriterMetadata を呼び出して、すべてのライタからメタデータを収集することを VSS フレームワークに指示します。

VSS フレームワークは、OnIdentify イベントを使用して、SQL ライタを含めて登録済みの各ライタにそのライタのメタデータを要求します。SQL ライタは SQL Server インスタンスに照会し、データベースごとにバックアップ メタデータ情報を取得し、"ライタ メタデータ ドキュメント" を作成します。このフェーズは、"メタデータ列挙" とも呼ばれます。

ライタ メタデータ ドキュメントは、ライタからリクエスタ (バックアップ アプリケーション) に渡される情報を含むドキュメントです。ライタ メタデータ ドキュメントには、次の情報が含まれます。

• アプリケーション ID とフレンドリ名

• ファイルとコンポーネントが存在する場所

• バックアップに含まれるファイルと含まれないファイル

• 復元時に使用するオプション

• この情報が VSS フレームワーク経由で戻されるリクエスタ

SQL ライタ メタデータ ドキュメント

これは、ライタ (この場合は SQL ライタ) が IVssCreateWriterMetadata インターフェイスを使用して作成する XML ドキュメントで、ライタの状態やコンポーネントに関する情報が保持されます。ライタ メタデータ ドキュメントの構造上の詳細については、VSS API のマニュアルを参照してください。ここでは、SQL ライタ メタデータ ドキュメントの詳細の一部を示します。

• ライタ ID 情報

  • ライタ名 - L"SQLWriter"

  • ライタ クラス ID : 0xa65faa63, 0x5ea8, 0x4ebc, 0x9d, 0xbd, 0xa0, 0xc4, 0xdb, 0x26, 0x91, 0x2a

  • ライタ インスタンス - L"SQL Server 2005:SQLWriter"

  • VSS の使用法の種類 - VSS_UT_USERDATA

  • VSS のソースの種類 - VSS_ST_TRANSACTEDDB

• ライタ レベルの情報 - VSS_APP_BACK_END

• 復元方式の指定 – VSS_RME_RESTORE_IF_CAN_REPLACE

• サポートされるバックアップ スキーマ (IVssCreateWriterMetadata::SetBackupSchema API)

  • VSS_BS_DIFFERENTIAL – 差分バックアップ

  • VSS_BS_TIMESTAMPED – タイムスタンプ ベース – フルテキスト カタログ ファイル用

  • VSS_BS_LAST_MODIFY – 最終更新時刻に基づく差分バックアップ

  • VSS_BS_WRITER_SUPPORTS_NEW_TARGET – 新しいターゲットの場所オプションをサポートする

  • VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE – "移動を伴う" 復元をサポートする

  • VSS_BS_COPY – "コピーのみ" のバックアップ オプションをサポートする

• コンポーネント レベルの情報

  これには、SQL ライタによって提供されるコンポーネント レベル固有の情報が含まれます。

  • 種類 - VSS_CT_FILEGROUP

  • 名前 - コンポーネントの名前 (データベース名)

  • 論理パス – サーバー インスタンスのパス (名前付きインスタンスの場合は "server\instance-name"、既定のインスタンスの場合は "server" の形式になります)

  • コンポーネント フラグ
    VSS_CF_APP_ROLLBACK_RECOVERY – ファイルの一貫性を確保し、バックアップ以外のシナリオ (アプリケーション ロールバックなど) で使用できるように、SQL Server スナップショットで常に "復旧" フェーズを要求することを示します。

  • 選択可能 - True

  • 復元用に選択可能 - True

• サポートされる復元方法 - VSS_RME_RESTORE_IF_CAN_REPLACE

SQL Server 2005 でのコンポーネント セット構造の拡張は、フルテキスト カタログの導入のみです。VSS データベース ファイルやログ ファイルには再帰指定がないことから考えると、フルテキスト カタログは VSS データベース ファイルやログ ファイルとして表現できないコンテナ ディレクトリです。そのため、SQL ライタでは VSS ファイル グループ コンポーネント (VSS_CT_FILEGROUP) を使用して、データベース ファイル、ログ ファイル、フルテキスト カタログ ファイルを表すデータベース レベルのコンポーネントやファイル グループのファイルを表現することになります。

この資料の最後に示した「ライタ メタデータ ドキュメント : 例」を参照してください。

バックアップの検出

このフェーズでは、リクエスタがライタ メタデータ ドキュメントを調べ、バックアップが必要な各コンポーネントの "バックアップ コンポーネント ドキュメント" を作成および設定します。また、必要なバックアップ オプションやパラメータもこのドキュメントの一部に含めます。SQL ライタの場合は、バックアップが必要な各データベース インスタンスは独立したコンポーネントです。

バックアップ コンポーネント ドキュメント

これは、リクエスタが (IVssBackupComponents インターフェイスを使用して) 復元操作やバックアップ操作の過程で作成する XML ドキュメントです。バックアップ コンポーネント ドキュメントには、バックアップ操作または復元操作に参加している 1 つ以上のライタからの、これらの操作に明示的に含まれるコンポーネントの一覧が保持されます。暗黙に含まれるコンポーネントの情報は保持されません。それに対して、ライタ メタデータ ドキュメントには、バックアップに参加できるライタ コンポーネントのみが保持されます。バックアップ コンポーネント ドキュメントの構造上の詳細については、VSS API のマニュアルを参照してください。

バックアップ前タスク

VSS でのバックアップ前タスクは、バックアップ用のデータを含むボリュームのシャドウ コピーの作成に重点が置かれます。バックアップ アプリケーションでは実際のボリュームではなく、シャドウ コピーからデータが保存されます。

通常、リクエスタは、ライタでのバックアップの準備およびシャドウ コピーの作成の間待機します。SQL ライタがバックアップ操作に参加している場合は、バックアップとシャドウ コピーに備えて、ファイルだけでなく、ライタ自体も構成する必要があります。

バックアップの準備

リクエスタでは、実行すべきバックアップ操作の種類を設定する (IVssBackupComponents::SetBackupState) 必要があり、その後、IVssBackupComponents::PrepareForBackup を使用して、バックアップの準備を行うことを VSS 経由でライタに通知する必要があります。

SQL ライタには、バックアップが必要なデータベースを詳しく示すバックアップ コンポーネント ドキュメントへのアクセス許可が与えられます。バックアップするすべてのボリュームは、ボリューム スナップショット セットに含まれている必要があります。SQL ライタが欠落したデータベースを検出した (バックアップするボリュームがスナップショットに含まれていない) 場合は、スナップショット後のイベント中にバックアップが失敗します。

スナップショットの開始

リクエスタでは、VSS フレームワーク インターフェイスの DoSnapshotSet を呼び出すことによってスナップショット プロセスを開始します。

スナップショットの作成

このフェーズでは、VSS フレームワークと SQL ライタの間で一連の相互作用が必要になります (実際には、すべてのライタがこのフェーズに関係します。ライタはアプリケーションごとに 1 つ存在します)。

1. スナップショットを準備します。

   SQL ライタでは、スナップショットの作成を準備するために SQL Server を呼び出します。

2. 固定します。

   SQL ライタから SQL Server を呼び出して、スナップショットでバックアップされる各データベースのすべてのデータベース入出力が行われないように固定します。保持イベントが VSS フレームワークに返されると、VSS でスナップショットが作成されます。

3. 固定を解除します。

   SQL ライタはこのイベントで SQL Server インスタンスを呼び出して、入出力操作の "固定を解除" するか、通常の入出力操作を再開します。

   注 : 実際には、データベースへのすべての書き込みがブロックされないように、スナップショット作成フェーズは高速 (60 秒未満) に行われます。

スナップショット後

スナップショットの自動復旧が必要な場合は、SQL ライタによりスナップショット内のデータベースごとに自動復旧が行われます。詳細については、「自動復旧スナップショット」を参照してください。

ファイルの実際のバックアップ

このフェーズでは、リクエスタが必要に応じてデータをバックアップ メディアに移動できます。この段階では、リクエスタと VSS フレームワーク間での相互作用が行われます。SQL ライタは関与しません。

1. ライタの状態を取得します。
   ライタの状態を返します。リクエスタは、この時点ですべてのエラーを処理する必要がある場合があります。

2. バックアップを行います。
   リクエスタは、必要に応じてこの時点でデータをバックアップ メディアに移動できます。

バックアップの完了

このイベントはバックアップが正常に完了したことを示します。

また、現在のバックアップがデータベースの完全バックアップで、コピーのみのバックアップではない場合は、SQL ライタはこの時点で差分ベースとしてこのバックアップをコミットすることもできます。

ライタ メタデータの保存

リクエスタは、バックアップ コンポーネント ドキュメントと各ライタのメタデータをスナップショットと共に保存する必要があります。このライタのメタデータは、復元操作に SQL ライタと SQL Server で必要になります。

バックアップ終了

リクエスタは、IVssBackupComponents インターフェイスを解放するか、IVssBackupComponents::DeleteSnapshots を呼び出すことによって、シャドウ コピーを終了します。

復元プロセス

ここでは、復元操作のワークフローと関連するさまざまな手順について説明します。

復元操作のワークフロー

次の図は、VSS 復元操作中のデータの流れ図を示します。この概要を次のフェーズに細分化すると、復元が実行される際に関係する基本タスクをより深く理解できます。

• 復元の初期化

• 復元の準備

• ファイルの実際の復元

• 復元のクリーンアップと終了

図 4

拡大表示する

VSS のコンポーネントベースのすべての復元シナリオでは、SQL ライタによって 2 つの個別のフェーズでデータベースの復元が処理されます。

• 復元前 : 検証の処理、ファイル ハンドルを閉じるなどの処理が行われます。

• 復元後 : データベースをアタッチし、必要に応じてクラッシュ復旧が行われます。

バックアップ アプリケーションでは、これらの 2 つのフェーズの間で、基盤となる SQL の関連データを移動する役割を担います。

復元の初期化

リクエスタでは、復元の初期化フェーズ中に、保存されたバックアップ コンポーネント ドキュメントにアクセスできる必要があります。

バックアップ操作中に生成されたバックアップ コンポーネント ドキュメントは、バックアップ データの一部として保存されます。バックアップ アプリケーションでは、このデータを VSS フレームワークに戻す必要があります。SQL ライタでは、復元プロセスの冒頭にこのデータへのアクセス権を取得します。

復元の準備

リクエスタでは、復元の準備で保存されたバックアップ コンポーネント ドキュメントを使用して、復元対象と復元方法を判断します。リクエスタは、復元するコンポーネントを選択し、必要に応じて適切な復元オプションを設定します。

IVssBackupComponents::SetAdditionalRestores(true)

リクエスタでは、バックアップ コンポーネント ドキュメントで必要な詳細をすべて設定したら、IVssBackupComponents::PreRestore を呼び出して、ライタが処理する復元前イベントを VSS 経由で生成します。

SQL ライタでは、提供されたバックアップ コンポーネント ドキュメントを調べて適切なデータベースを特定し、バックアップ時以降に作成された追加ファイルを削除します。また、ディスク容量をチェックし、開かれているデータベース ファイルを閉じます。その結果、リクエスタは復元フェーズで必要なデータをコピーできます。このフェーズでは、リクエスタが実際のファイル コピーを始める前に、すべてのエラー状態を早期検出できます。SQL Server でもデータベースを復元状態にします。この時点以降は、復元が正常に行われるまで、データベースを開始できません。

ファイルの復元

これは、純粋にリクエスタ固有の操作です。リクエスタ (バックアップ アプリケーション) には、必要なデータベース ファイル (差分復元の場合はデータの関連範囲) を適切な場所にコピーする役割があります。SQL ライタはこの操作には関与しません。

クリーンアップと終了

すべてのデータが適切な場所に復元されたら、復元操作が完了したことを通知するリクエスタからの呼び出し (IvssBackupComponents::PostRestore) により、SQL ライタは復元後の操作を開始できることを認識します。SQL ライタはこの時点で、クラッシュ復旧の再実行フェーズを行います。復旧が要求されない場合 (つまり、リクエスタから SetAdditionalRestores(true) が指定されない場合)、このフェーズで復旧手順も実行されます。

バックアップと復元オプションの詳細

ここでは、SQL ライタでサポートされるバックアップと復元のすべてのオプションを詳しく説明します。

リクエスタがボリューム シャドウ コピーを作成する

データベース ファイルのバックアップ ボリュームがボリューム スナップショット セットに追加されているので、SQL ライタは (バックアップ/復元操作のコンテキスト以外から) ボリューム シャドウ コピーの作成プロセスに関与できます。この場合、SQL ライタはメタデータの列挙、固定、固定解除、スナップショットの準備、スナップショット後の調整に参加するだけです (詳細については、データの流れ図を参照してください)。

完全バックアップ/復元

SQL ライタでは、非コンポーネントベース モードとコンポーネント ベース モードの両方で完全バックアップと完全復元操作がサポートされます。

非コンポーネントベースのバックアップと復元

非コンポーネントベースのバックアップでは、リクエスタはバックアップまたは復元するボリューム ツリーまたはフォルダ ツリーを指定します。指定されたボリュームまたはフォルダ内のデータがすべてバックアップまたは復元されます。

バックアップ

非コンポーネントベースのバックアップの場合、SQL ライタではスナップショット セット内のボリュームの一覧を使用して、データベースが自動的に選択されます。ライタは欠落したデータベースをチェックし、見つかった場合はエラーを発生します。"欠落したデータベース" は、ボリュームの一覧で選択されるファイルのサブセットに含まれていて存在しないデータベースです。SQL ライタでは、復元後のロールフォワード (差分復元またはログ復元) はサポートされません。

復元

リクエスタでは、非コンポーネントベース モードでバックアップしたデータベースが復元されます。このモードでの復元では、ログ復元や差分復元など、復元後のロールフォワードを伴う復元は行えないことに注意してください。

非コンポーネントベースの復元操作の場合、SQL Server インスタンスをオフラインにするか、対象のデータベースを削除またはデタッチして、ファイルがオフラインになっていることを確認してから、復元を実行する必要があります。ファイルが適切にコピーされてから、データベースをアタッチします。これらの操作は、SQL ライタのスコープ外で行われます。

コンポーネントベースのバックアップと復元

コンポーネントベースのバックアップでは、リクエスタはバックアップまたは復元するデータベース コンポーネントを (SQL ライタがクライアントに返したメタデータから) 明示的に選択します。

バックアップ

コンポーネントベースのバックアップの場合、バックアップするすべてのボリュームがボリューム スナップショット セットに含まれている必要があります。SQL ライタが欠落したデータベースを検出した (バックアップするボリュームがスナップショットに含まれていない) 場合は、バックアップに失敗します。完全バックアップでは、データベース データと、復元時にデータベースをトランザクションとして一貫性のある状態にするために必要なすべてのログ ファイルがバックアップされます。

ロールフォワードを伴なわない完全復元

データベース バックアップの完全復元では、復元後にロールフォワードを行わなくても正しく復元される場合もあります。これは、ロールフォワードを容易にするメタデータが存在しなかったり、場合によっては、ロールフォワードが必要ないことも考えられます。ここでは、この 2 つの状況について簡単に説明します。

メタデータなし/ロールフォワードなし

バックアップ操作中にライタのメタデータ (コンポーネントベースのバックアップ メタデータ) が保存されていない場合は、SQL Server インスタンスをオフラインにするか、対象のデータベースを削除またはデタッチして、ファイルがオフラインになっていることを確認してから、復元を実行する必要があります。ファイルが適切にコピーされてから、データベースをアタッチします。これらの操作は、SQL ライタのスコープ外で行われます。

メタデータが存在しても追加のロールフォワードの必要がない

リクエスタでは、コンポーネントベース モードでバックアップしたデータベースが復元されます。

追加のロールフォワードを伴う完全復元

リクエスタでは、SetAdditionalRestores(true) オプションを指定する復元を実行できます。このオプションは、リクエスタが復元に続いてロールフォワード復元 (ログ復元、差分復元、増分復元など) を行うことを示します。これにより、復元操作の最後に復旧手順を実行しないように SQL Server に指示されます。

バックアップ中にライタのメタデータが保存されていて、復元時に SQL ライタがその情報を使用できる場合に限り、これが可能になります。リクエスタから VSS に復元操作を実行するように指示する前に、SQL Server サービスが実行されている必要があります。

SQL ライタでは次のシーケンスが行われます。

1. 各データベースの復元を準備します。ここでは、リクエスタ アプリケーションがデータベース ファイルをコピーまたはマウントできるように、すべてのファイル ハンドルを閉じます。

2. リクエスタ アプリケーションが、ファイルをコピーまたはマウントします。

3. (NORECOVERY を指定して) 復元を完了します。データベースを "復元中" 状態でオンラインにします。

通常の SQL バックアップ (差分バックアップやログ バックアップ) では、その後、VDI を使用するか、VSS フレームワークを使って差分復元を適用することで、データベースをロールフォワードできます。

フルテキスト サポート

SQL ライタでは、ライタのメタデータ ドキュメント内のデータベース コンポーネントの下にファイルを再帰指定することで、フルテキスト カタログ コンテナが報告されます。フルテキスト カタログ コンテナは、データベース コンポーネントが選択されるときにバックアップ内に自動的に含められます。

差分バックアップ/復元

差分バックアップ操作では、前回差分バックアップを行った以降に変更されたデータだけがバックアップされます。差分バックアップには、データベース ファイルの中で変更が行われた部分だけが含まれます。バックアップ アプリケーションやリクエスタが差分バックアップを行うためには、データベース内で変更が加えられた場所に関する情報が必要です。この情報により、ファイルの適切な部分をバックアップできます。SQL ライタは、差分バックアップ操作中に、"VSS 部分ファイル情報" で指定されるような形式でこのような情報を提供します。この情報を使用して、データベース ファイル内の変更部分のみをバックアップできます。

バックアップ

リクエスタは、VSS を使ってバックアップ操作を開始するときに、バックアップ コンポーネント ドキュメントに DIFFERENTIAL オプション (VSS_BT_DIFFERENTIAL) を設定する (IVssBackupComponents::SetBackupState) ことで、差分バックアップを実行できます。SQL ライタから VSS に (SQL Server から返された) 部分ファイル情報を渡します。リクエスタでは、VSS API (IVssComponent::GetPartialFile) を呼び出すことで、このファイル情報を取得できます。リクエスタはこの部分ファイル情報を使って、データベース ファイルのバックアップに変更済みのバイト範囲だけを選択できます。

• SQL ライタではバックアップ前タスクにより、選択したデータベースごとに 1 つの差分ベースが存在することを確認します。

• SQL ライタはスナップショット後イベント中に SQL Server から部分ファイル情報を取得し、IVssComponent::AddPartialFile 呼び出しを使用して、バックアップ コンポーネント ドキュメントにこの情報を追加します。

部分ファイル情報の形式

SQL ライタでは、差分バックアップ中にバックアップされるデータベースごとに、各データベース ファイルの部分ファイル情報が格納されます。リクエスタ (バックアップ アプリケーション) はこの情報を使用して、ファイルの実際のバックアップ中に、ファイルの関連部分だけをバックアップ メディアにコピーします。この部分ファイル情報の形式の詳細については、「Volume Shadow Copy Service」(英語) のドキュメントを参照してください。

リクエスタでは、IVssComponent::GetPartialFileCount と IVssComponent::GetPartialFile を呼び出すことによって、このようなファイルを判断できます。IVssComponent::GetPartialFile では、ファイルへのパスとフィル名、およびファイル内でバックアップする必要のあるものを示す範囲文字列を返します。

部分ファイル情報の取得に関する詳細については、VSS のドキュメントを参照してください。

ファイルのバックアップ

バックアップ アプリケーションでは、このフェーズでバックアップ コンポーネント ドキュメントに保存されたメタデータを参照して、ファイル内の関連部分のみをバックアップする必要があります。フルテキスト カタログ ファイルの場合は、ファイルのタイムスタンプに基づいてこのバックアップが行われます。このことについては、この資料の後半で説明します。

• 差分バックアップは、常に、そのデータベースに対して存在する最新のベース バックアップに基づいて行われます。SQL Server は、復元時にベース バックアップと差分バックアップの不一致を検出します。したがって、差分が目的の完全バックアップに基づいていることを確認するのはバックアップ アプリケーションまたはシステム管理者の役割です。何らかの帯域外の手順で別の完全バックアップが行われた場合、バックアップ アプリケーションはそのベース バックアップを "所有していない" ことになるので、差分を復元することはできません。

• 現時点では、バイト範囲情報 (部分ファイル情報) が大きすぎる (64KB のバッファ サイズを超える) 場合、SQL Server では完全バックアップを行うことをユーザーに指示するエラーがスローされます。

バックアップ時の注意事項

バックアップでは、ファイルの追加、削除、圧縮、拡張、論理名の変更、物理名の変更などに注意が必要です。

ベースの取得後にファイルが新しく追加された

SQL データベースのすべてのヘッダーが部分指定に存在している必要があるので、このようなファイルを部分指定に含めます。ヘッダー ページ以外に、すべての割り当て済みページも部分指定に含める必要があります。

ベースの取得後にファイルが削除された

ベースの取得後でもデータ ファイルを削除できます。このように削除されたファイルは、差分バックアップ中にライタ メタデータ ドキュメントに含まれません。さらに、削除されたファイルに関連付けられる部分情報も存在しません。

ベースの取得後にファイルが圧縮された

サーバーでファイル圧縮が無効になるまでは、そのファイルから部分情報が収集されません。その結果、データ ファイル内の圧縮された範囲に対応する部分情報が含められることはなくなります。

ベースの取得後にファイルが拡張された

部分情報を収集する前に拡張が行われている場合は、部分情報に拡張領域の割り当て済みページが含められます。部分情報を収集した後に拡張が行われた場合は、部分情報に拡張領域の変更が含められません。この後の説明で、ログのロールフォワードによってこのような変更が復元されることを確認します。

ベースの取得後にファイル論理名が変更された

ライタ メタデータ ドキュメントやバックアップ コンポーネント ドキュメントでファイルの論理名が参照されることはないので、ファイルの論理名を変更してもバックアップや復元には影響しません (詳細については、「ライタ メタデータ ドキュメント : 例」を参照してください)。

ベースの取得後にファイル物理名が変更された

データベース ファイルの物理名の変更は、データベースを再起動するまで有効にはなりません。したがって、部分情報バッファ内のデータベース構成情報やファイル パス情報は依然として変更前の物理パスに基づいています。変更前のパスは、スナップショットのデータベース ファイルに対してのみ有効なパスです。

復元

差分復元中にリクエスタが SQL ライタに提供するバックアップ メタデータには、バックアップの種類に関する情報が含まれています。そのため、SQL ライタでは特別な処理は必要ありません。SQL Server 自体が差分復元を実行します。SQL Server では、VSS を使用しないネイティブの差分復元と同じ方法でこのような差分復元を処理します。

復元前フェーズ

このフェーズ中に SQL Server では、すべてのファイルのサイズを差分バックアップのファイル メタデータに基づく適切なサイズに変更します。ファイルが拡張される場合、拡張部分はゼロ (0) クリアされます。新しいファイルを作成する必要がある場合 (ベースの取得後にファイルが作成された場合)、SQL Server では新しいファイルを作成し、内容をすべてゼロ (0) クリアします。また、すべてのファイル ハンドルを閉じます。その結果、バックアップ アプリケーションはバックアップ メディアから復元されるデータでファイルを上書きできます。

ファイルの復元

クライアントでは、部分ファイル指定に基づいてファイルを復元する必要があります。データは、ライタ メタデータに保存された部分ファイル指定で指定されているのと同じオフセットまたは範囲でデータベース ファイルに復元される必要があります。

復元時にも、ファイルの追加、削除、圧縮、拡張、論理名の変更、物理名の変更などに注意が必要です。

完全ベースの取得後にデータベース ファイルが追加された

このように追加されたファイルは、復元準備フェーズ中に SQL Server によって事前に作成される必要があります。作成されるファイルは適切なサイズに拡張され、ゼロ (0) クリアされます。クライアントでは、部分指定に従ってデータを設定する必要があるだけです (部分指定には割り当て済みのすべてのエクステントが含まれます)。

完全ベースの取得後にデータベース ファイルが削除された

SQL Server が提供する部分情報には、このように削除されたファイルを追跡する情報は含まれません。SQL Server には、復元されるファイルのメタデータを既存のコンテナと比較することによって、削除されたファイルを検出し、それらを実際に削除する役割があります。これは、復元前の準備手順として行われます。

完全ベースの取得後にデータベース ファイルが拡張された

このように拡張されたファイルは、復元準備フェーズ中に SQL Server によって適切なサイズに拡張される必要があります。拡張される領域は、SQL Server によってゼロ (0) クリアされる必要があります。そのため、領域が拡張された場合でも、クライアントでは部分情報に従ってデータを安全に設定できます。部分情報を取得した後にファイルが拡張された場合は、差分バックアップと共にバックアップされたログを再生することによって、拡張された領域内の変更が復元されます。

完全ベースの取得後にデータベース ファイルが圧縮された

SQL Server には、メタデータで要求されたサイズにファイルを切り詰める役割があります。これは、復元前の準備手順として行われます。

完全ベースの取得後にデータベース ファイルの論理名が変更された

ライタ メタデータ ドキュメントやバックアップ コンポーネント ドキュメントでは論理名は参照されないので、論理名の変更は復元には影響しません。クライアントが論理名の変更をプライマリ データベース ファイルに適用すると、その変更が復元されます。プライマリ データベース ファイルにはシステム カタログ 情報が含まれています。

完全ベースの取得後にデータベース ファイルの物理名が変更された

差分バックアップの時点までに物理名の変更が有効になっていない場合、クライアントでは変更前の名前でデータが復元されます。復元後にデータベースを再起動すると、物理名の変更が有効になります。差分バックアップの時点までに物理名の変更が既に有効になっている場合、部分データが存在すればそのデータは新しい物理パスからバックアップされます。

復元後

SQL ライタでは、復元後のイベント中に、通常の再実行操作とデータベースの復旧 (SetAdditionalRestores() が False に設定されている場合) が行われます。

フルテキスト カタログの差分バックアップ/復元

SQL Server 2005 のフルテキスト カタログはデータベース リソースの一部なので、他のデータベース ファイルと共にバックアップまたは復元する必要があります。フルテキスト カタログの差分バックアップは、タイムスタンプに基づきます。SQL Server 2005 VSS の差分バックアップ/復元には、ベース バックアップが 1 つしかありません。つまり、コンテナが異なっても差分ベースは同じです。VSS フルテキスト カタログ バックアップの場合、フルテキスト カタログ コンテナごとに 1 つのタイムスタンプがあるネイティブの SQL 差分バックアップとは異なり、差分バックアップが 1 つのタイムスタンプに基づいており、このタイムスタンプがすべてのフルテキスト カタログ コンテナ用になります。

VSS では、このタイムスタンプがコンポーネント全体のプロパティとして表現されます。このプロパティは完全バックアップ中に設定され、その後の差分バックアップ中に使用されます。

OnIdentify

SQL ライタは OnIdentify で IVssCreateWriterMetadata::SetBackupSchema() を呼び出し、値 VSS_BS_TIMESTAMPED を設定します。これにより、SQL ライタが差分ベースの管理を担当していることがバックアップ アプリケーションに示されます。

ベース タイムスタンプを設定する

ベース タイムスタンプは、完全バックアップ中に設定します。ライタは OnPostSnapshot() で IVssComponent::SetBackupStamp() を呼び出し、バックアップ ドキュメントにコンポーネントと共にタイムスタンプを格納します。

差分バックアップ

バックアップ アプリケーションでは、ベース完全バックアップからこのタイムスタンプを取得し、ライタが IVssComponent::GetPreviousBackupStamp() を呼び出して使用できるようにします。OnPostSnapshot() で IVssComponent::AddDifferencedFilesByLastModifyTime() を呼び出して、このタイムスタンプを各フルテキスト カタログに設定します。

差分バックアップ中のバックアップ アプリケーションの役割

バックアップ アプリケーションでは、差分バックアップ中に以下のことを行います。

• コンポーネント内のファイル セットの "最終更新時刻" で指定されたタイムスタンプよりも新しい最終更新タイムスタンプが設定されたすべてのファイル (ファイル全体) をバックアップします。

• 削除されたファイルの追跡および検出を行います。

差分復元中のバックアップ アプリケーションの役割

バックアップ アプリケーションでは、差分復元中に以下のことを行います。

• バックアップされたすべてのファイルを復元します。ファイルが存在しない場合は、新しいファイルを作成します。ファイルが既に存在する場合は、既存のファイルに上書きします。

• 復元されるファイルが既存のファイルよりも大きい場合は、内容を設定する前にファイルを拡張します。

• 復元されるファイルが既存のファイルよりも小さい場合は、復元されるファイルと同じサイズに切り詰めます。

• 削除すべきフィルをすべて削除します。つまり、差分バックアップの時点で存在していなかったファイルを削除します。

コピーのみのバックアップ

特殊な目的にバックアップが必要になることがあります。たとえば、テストの目的でデータベースのコピーを作成する必要がある場合などです。このようなバックアップでは、データベースのバックアップと復元手順の全体に影響を与えてはいけません。COPY_ONLY オプションを使用することで、バックアップが "帯域外" で行われ、通常のバックアップ シーケンスには影響を及ぼしません。SQL ライタでは、SQL Server 2005 インスタンスを使って、"コピーのみ" のバックアップがサポートされます。

SQL ライタではバックアップの検出フェーズで IVssCreateWriterMetadata::SetBackupSchema を呼び出し、サポートされているバックアップ スキーマ オプション VSS_BS_COPY を設定することで、コピーのみのバックアップを実行できることを示します。リクエスタでは、IVssBackupComponents::SetBackupState を呼び出して、VSS_BACKUP_TYPE オプションに VSS_BT_COPY を設定することで、バックアップの種類にコピーのみのバックアップを設定できます。

コピーのみのバックアップが選択されている場合は、各ファイルのバックアップ履歴の状態とは無関係にディスク上のファイルが (リクエスタによって) バックアップ メディアにコピーされると想定されます。SQL Server ではバックアップ履歴が更新されません。この種のバックアップは、それ以降の差分バックアップ操作のベース バックアップとして選定されることはありませんし、以前の差分バックアップの履歴に悪影響を与えることもありません。

移動を伴う復元

VSS を使用することにより、バックアップ アプリケーション (リクエスタ) は IVssComponent::SetNewTarget を呼び出して、新しい復元先を指定できます。SQL ライタでは PreRestore() と PostRestore() の両方で、新しい復元先が 1 つでも指定されているかどうかをチェックします。実際のファイルの復元またはコピー時に新しい場所にファイルを物理的にコピーするのはバックアップ アプリケーションの役割です。

バックアップ アプリケーションでは、新しいターゲットの物理パスを指定することだけが許可されます。ファイル指定を変更することはできません。たとえば、c:\data\test.mdf にあるデータベース ファイルの場合、実際のファイル名 test.mdf を変更することはできません。パス c:\data しか変更できません。c:\ftdata\foo にあるフルテキスト カタログ コンテナの場合、VSS でのファイル指定は "*" で、パス指定が c:\ftdata\foo なので、パス全体を変更できます。

データベース名の変更

リクエスタでは、SQL データベースを新しい名前で復元することが必要な場合があります。たとえば、元のデータベースと並列にデータベースを復元する場合などです。リクエスタでは復元操作中に (wszRestoreOptions parameter で) VSS 呼び出し IVssBackupComponents::SetRestoreOptions() を使用して、カスタム復元オプション "New Component Name" = <"新しい名前"> を設定することでこれを指定できます。

SQL ライタでは、"New Component Name" 値の内容全体を取得して、復元するデータベースの新しい名前として使用します。このオプションを指定しないと、データベースは元の名前 (コンポーネント名) で復元されます。

自動復旧スナップショット

VSS フレームワークを使用して取得する SQL Server データベースのスナップショットは、一般的に復旧されていない状態になります。実行中のトランザクションをロールバックし、データベースを一貫性のある状態にする復旧フェーズを経なければ、スナップショット内のデータに安全にアクセスすることはできません。スナップショットは読み取り専用状態なので、データベースをアタッチする通常のプロセスでは復旧できません。

Windows 2003 SP1 で実行されている SQL Server 2005 と VSS フレームワークでは、スナップショット作成プロセスの一環として、スナップショットを自動復旧できます。SQL ライタではライタ メタデータ ドキュメントの一部としてコンポーネント フラグ "VSS_CF_APP_ROLLBACK_RECOVERY" を指定して、バックアップ以外の目的で行ったデータベース バックアップの復旧を行う必要があることを示します。リクエスタではスナップショット セットを作成するときに、そのスナップショットが "app-rollback" スナップショット (アプリケーションで使用する場合にスナップショット内のすべてのデータベース ファイルが一貫性のある状態になっていることを意味します) か、"backup" スナップショット (後でシステム障害が発生した場合に復元するデータをバックアップするためにスナップショットを使用します) かを示すことができます。

リクエスタでは VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY を設定して、バックアップ以外の目的でこのコンポーネントがバックアップされたことを示す必要があります。VSS では、SQL ライタが選択したコンポーネントに指定した VSS_CF_APP_ROLLBACK_RECOVERY とこの VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY との相関関係を調べることにより、自動復旧を行うかどうかを判断します。その結果、スナップショットを書き込み可能にし、自動的に VSS_VOLSNAP_ATTR_AUTORECOVERY ビットを追加します。

SQL Server の場合は、backup スナップショットではなく、app-rollback スナップショットのみに自動復旧が適用されます。app-rollback スナップショットの場合、スナップショット後のイベント中に SQL ライタによって自動復旧プロセスが開始されます。このプロセスでは、(リクエスタによって) 明示的に選択されたスナップショット セット内の SQL Server データベースごとに以下のことが行われます。

• スナップショット データベースを元の SQL Server インスタンス (つまり、元のデータベースをアタッチするインスタンス) にアタッチします。

• データベースを復旧します (これは "アタッチ" 操作の一環として行われます)。

• ログ ファイルを圧縮します。

  これにより、VSS フレームワークが行う必要のある "copy-on-write" の中で不要なコピーの量が削減されます。ログ ファイルの圧縮は既定の動作です。これは、次のレジストリ キーの値を 1 に設定することによって無効にできます。

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLWriter\Settings\DisableLogShrink
  

  これは、オンライン データベースの問題を解決するために、ログの (特定時点の) 特定のページからデータをエクスポートするのにスナップショットを使用するようなシナリオで役に立ちます。

• データベースをデタッチします。

これで、クエリにアタッチできる、一貫性のあるスナップショットに復旧されます。

マルチデータベース トランザクション

場合によっては、スナップショット データベースに実行中のマルチデータベース トランザクションが含まれることがあります。SQL ライタは、復旧操作中に "Presumed Abort" オプションを指定してスナップショットにデータベースをアタッチします。これにより、(コミットの準備が整った状態のトランザクションを含めて) まだコミットされていないマルチデータベース トランザクションがロールバックされます。その結果、スナップショット セット内のデータベース間が一部一貫性のない状態になることがあります。たとえば、A と B という 2 つのデータベースを考えます。これら 2 つのデータベース間に 1 つの分散トランザクションがあります。このトランザクションは、データベース A ではコミット状態で、データベース B ではコミットの準備が整った状態にあるとします。このトランザクションは復旧プロセスの一環として、データベース A ではコミットされ、データベース B ではロールバックされます。この結果、スナップショット セット内のデータベースの状態に一貫性がなくなります。

Longhorn のリリース時期にあわせて VSS フレームワークでリリースされる Microsoft 分散トランザクション コーディネータ (MS DTC) コンポーネントでは、複数の SQL Server インスタンスのデータベースにまたがるトランザクションで一貫性が損なわれる問題を解決する予定です。また、次のバージョンの SQL Server でも、複数の SQL Server インスタンスのデータベースにまたがるトランザクションで一貫性が損なわれる問題を解決する予定です。

自動復旧スナップショットのセキュリティ

VSS スナップショットの場合、自動復旧後にアクセス制御リスト (ACL) を使ってファイルのセキュリティが保護され、本来の SQL Server アカウントと組み込みの Administrators アカウントしかアクセスできなくなります。スナップショットへのデータベース ファイルのアタッチを要求するクライアントは、組み込みの Administrators アカウントまたは SQL Server アカウントのいずれかのメンバである必要があります。

特殊なケース

ここでは、SQL ライタベースのバックアップ操作と復元操作の実行中に遭遇する特殊なケースをいくつか説明します。

データベースの自動終了

非コンポーネントベースのバックアップの場合、欠落状態のチェック時にデータベースの自動終了が行われますが、これによりバックアップ操作中に入出力の停止が明示的に行われることはありません。

このような場合に期待されるシナリオは、閉じられたデータベースが数多く存在する場合に、スナップショットのコストを最小限に抑えることです。一般的に、リソースの少ないロウエンドの構成で閉じられたデータベースが使用されます。

ファイルの一覧

各データベースのファイルの一覧は、バックアップの準備イベントに先立つ列挙手順で決定されます。列挙と固定の間にデータベース ファイルの一覧を変更する場合、アプリケーションでファイル一覧の再チェックを行わないと、データベースが欠落する可能性があります。これが問題になるとは考えていませんが、ベンダではこのことを認識しておく必要があります。

停止中のインスタンス

列挙手順が実行される時点で SQL Server のインスタンスが実行されていない場合、このようなインスタンスのデータベースは選択されません。

列挙とバックアップの準備イベントの間にインスタンスが停止されると、停止されたインスタンスのデータベースはすべて無視されます。

システム データベースとユーザー データベース

SQL Server のシステム データベースには、master、model、msdb の各データベースがあり、SQL Server のインストール時に配置されます。ここでは、これらのデータベースを VSS スナップショット バックアップ プロセスで処理する方法について説明します。

システム データベース

master データベースを復元できるのは、インスタンスを停止し、データベース ファイルを置き換えてから (バックアップアプリケーションによって行われます)、インスタンスを再起動する場合だけです。ロールフォワードを行うことはできません。

SQL ライタでは、model データベースと msdb データベースの両方を、インスタンスをシャットダウンしないでオンラインで復元できます (これは、MSDE ライタにはない強化機能です)。

システム データベースの復旧の詳細については、VDI スナップショットのドキュメントを参照してください。

単純復旧モデルのユーザー データベース

システム データベースが、単純復旧モデルを使用するユーザー データベースと共に復元される場合は、インスタンスをシャットダウンし、単にボリュームをコピーまたはマウントするという、システム データベースと同じ方法でユーザー データベースを復元できます。SQL インスタンスが起動されるときに、すべて復旧されます。

ユーザー データベースのロールフォワード

ユーザー データベースが master データベースの復旧と同時に復旧およびロールフォワードされる場合、インスタンスを起動して、master データベースとユーザー データベースを同時に復旧してはいけません。

この場合は、以下の手順に従ってください。

1. SQL Server のインスタンスが停止していることを確認します。

2. 2 フェーズで復元を実行します。

   1. システム データベースと、VSS のファイル コピーまたはボリューム マウントを使って同時に復旧すべきユーザー データベース (つまり、単純復旧モードのユーザー データベース) を復元します。

      1. ロールフォワードされるユーザー データベースが、システム データベースと同じボリュームに存在しない場合は、この時点でそのボリュームを元の場所に戻してはいけません。このシナリオでは、バックアップに先立つ計画が必要です。

      2. ユーザー データベースがシステム データベースと同じボリュームに存在する場合は、ユーザー データベースを SQL Server から非表示にする必要があります。

      3. -f パラメータを使用して SQL Server のインスタンスを起動します (注 : -f スタートアップ オプションを使用することで、master だけを復元できます)。

      4. ロールフォワードするデータベースごとに ALTER DATABASE <x> SET OFFLINE を実行します (DETACH DATABASE を使用することもできます)。

      5. SQL Server のインスタンスを停止します。

      6. SQL Server のインスタンスを起動します (ロールフォワードするユーザー データベースのファイルは SQL Server には表示されません)。

   2. 「追加のロールフォワードを伴う完全復元」で説明したように、VSS を使用し、WITH NORECOVERY を指定してユーザー データベースを復元します。

付録

ライタ メタデータ ドキュメント : 例

この例では、データベース名を DB1 とします。このデータベースはコンピュータ Server1 の SQL Server インスタンス Instance1 に所属し、以下のデータベース ファイルとログ ファイルを含んでいます。

• c:\db\DB1.mdf に格納された "primary" という名前のデータベース ファイル

• c:\db\DB1.ndf に格納された "secondary" という名前のデータベース ファイル

• c:\db\DB1.ldf に格納された "log" という名前のデータベース ファイル

• ディレクトリ c:\db\ftdata\foo に格納された "foo" という名前のフルテキスト カタログ

• ディレクトリ c:\db\ftdata\bar に格納された "bar" という名前のフルテキスト カタログ

以下にデータベースのライタ メタデータを示します。

データベース レベルのファイル グループ コンポーネント

• ComponentType: VSS_CT_FILEGROUP

• LogicalPath: "Server1\Instance1"

• ComponentName: "DB1"

• Caption: NULL

• pbIcon: NULL

• cbIcon: 0

• bRestoreMetadata: FALSE

• NotifyOnBackupComplete: TRUE

• Selectable: TRUE

• SelectableForRestore: TRUE

• ComponentFlags: VSS_CF_APP_ROLLBACK_RECOVERY

ファイル グループのファイル

• LogicalPath: "Server1\Instance1"

• GroupName: "DB1"

• Path: "C:\db"

• FileSpec: "DB1.mdf"

• Recurisve: FALSE

• AlternatePath: NULL

• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

ファイル グループのファイル

• LogicalPath: "Server1\Instance1"

• GroupName: "DB1"

• Path: "C:\db"

• FileSpec: "DB1.ndf"

• Recursive: FALSE

• AlternatePath: NULL

• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

ファイル グループのファイル

• LogicalPath: "Server1\Instance1"

• GroupName: "DB1"

• Path: "C:\db"

• FileSpec: "DB1.ldf"

• Recursive: FALSE

• AlternatePath: NULL

• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

ファイル グループのファイル

• LogicalPath: "Server1\Instance1"

• GroupName: "DB1"

• Path: "c:\db\ftdata\foo"

• FileSpec: “*”

• Recursive: TRUE

• AlternatePath: NULL

• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

ファイル グループのファイル

• LogicalPath: "Server1\Instance1"

• GroupName: "DB1"

• Path: "c:\db\ftdata\bar"

• FileSpec: “*”

• Recursive: TRUE

• AlternatePath: NULL

• BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

サーバー インスタンスがコンピュータの既定のインスタンスの場合は、論理パスは一部構成の "Server1" になることに注意してください。

関連資料

「Volume Shadow Copy Service」(英語) のドキュメント