SQL Server バックアップ アプリケーション - ボリューム シャドウ コピー サービス (VSS) と SQL ライター

  • [アーティクル]

適用対象: SQL Server

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

VSS のインフラストラクチャ

VSS では、Windows システム上で VSS アプリケーションを実行するためのシステム インフラストラクチャが提供されます。 ほとんどの場合は、ユーザーと開発者のどちらにも透過的ですが、VSS では次のようになります。

  • シャドウ コピーの作成と使用における、プロバイダー、ライター、リクエスターのアクティビティを調整します。
  • 既定のシステム プロバイダーを提供します。
  • 任意のプロバイダーが動作するのに必要な低レベルのドライバー機能を実装します。

VSS サービスは必要に応じて開始されます。そのため、VSS 操作を正常に実行するには、このサービスを有効にする必要があります。

VSS のコンポーネント

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

  • プロバイダーはシャドウ コピー データを所有し、シャドウ コピーをインスタンス化します。
  • ライターは、データを変更し、シャドウ コピーの同期プロセスに参加するアプリケーションです。
  • リクエスターは、シャドウ コピーの作成と破棄を開始します。 この設計では、リクエスターがバックアップ アプリケーションであるシナリオに重点が置かれています。

VSS によって、これらのパーティ間の調整が行われます。

VSS によって、これらのパーティ間の調整がどのように行われるかを示す図。

この図では、一般的な VSS スナップショット アクティビティに参加するすべてのコンポーネントが示されています。 このようなシナリオでは、SQL Server (SQL ライターを含む) は、いずれかのライター ボックスのライターとして機能します。 そのようなライターとしては、他に Exchange Server などがあります。

  • 仮想デバイス インターフェイス: SQL Server には、仮想デバイス インターフェイス (VDI) と呼ばれるアプリケーション プログラミング インターフェイスが用意されています。独立系ソフトウェア ベンダーは、それを使用して、バックアップと復元の操作のサポートを提供することで、SQL Server を独自の製品に統合できます。 これらの API は、最高の信頼性とパフォーマンスを提供するほか、ホット バックアップ機能やスナップショット バックアップ機能など、 SQL Server のあらゆるバックアップおよび復元機能をサポートするように設計されています。 詳しくは、「SQL Server 2005 仮想バックアップ デバイス インターフェイスの仕様」をご覧ください。

  • リクエスター: 元のボリューム (1 つまたは複数) からのスナップショット セット (1 つまたは複数) の取得を要求する (自動または GUI) プロセス。 この記事では、リクエスターを使用して、SQL Server データベースのスナップショットを作成しているバックアップ アプリケーションも示します。

詳しくは、ボリューム シャドウ コピー サービスに関するドキュメントをご覧ください。

SQL ライター

SQL ライターは、SQL Server によって提供される VSS ライターです。 それでは、VSS と SQL Server の相互作用が処理されます。 SQL ライターは、スタンドアロン サービスとして SQL Server に付属しており、SQL Server のインストールの一部としてインストールされます。

VSS スナップショット バックアップ操作での SQL ライターの役割は次のとおりです。

VSS スナップショット

SQL ライターの構成

SQL ライター サービスは、SQL Server のインストールの一部としてシステムにインストールされ、Windows の起動時に自動的に開始するように構成されます。

SQL ライター サービスのアカウント

インストールの間に、SQL ライター アカウントはローカル システム アカウントを使用するようにインストールされます。 SQL ライターは、排他的な VDI API を使用して SQL Server と通信する必要があるため、SQL ライター アカウントには SQL Server と VSS の両方に対する十分なアクセス権が必要です。 サービスをローカル システム アカウントとして構成することで、サービスを正常に実行するための十分な権限が与えられます。

Note

SQL ライター サービスを正しく動作させるには、ローカル システム アカウントが SQL Server インスタンスの "sa" ロールから削除されていないことを確認することが重要です。

SQL ライターの再有効化と開始

SQL ライターは既定で有効で、自動的に開始されます。 この構成を変更した場合に設定を既定に戻すには、次の操作を行います。

SQL ライター サービスは、このサービスを "自動" としてマークすることにより有効にできます。 コントロール パネルからサービスを開くには、[スタート] ボタンをクリックし、[コントロール パネル] をクリックし、[管理ツール] をダブルクリックして、[サービス] をダブルクリックします。 [サービス] ペインで、SQL ライター サービスをダブルクリックし、[スタートアップの種類] プロパティを [自動] に変更します。

その後、前述のサービス プロパティ画面の [サービスの状態] プロパティの [開始] ボタンを選択し、サービスを開始します。

Note

SQL Server Express のインスタンスがインストールされていて、アプリケーションでユーザー インスタンス機能が使用されている場合、SQL Server によって SQL ライターが自動的に開始されることがあります。 これは、VSS のバックアップ操作中に、これらのユーザー インスタンスの列挙を容易にするために行われます。

SQL ライターによってサポートされる機能

  • フルテキスト: SQL ライターでは、ライターのメタデータ ドキュメントのデータベース コンポーネントの下で、再帰的にファイルが指定されたフルテキスト カタログ コンテナーが報告されます。 それらは、データベース コンポーネントが選択されると、バックアップに自動的に組み込まれます
  • 差分バックアップと復元: SQL ライターでは、次の 2 つの VSS 差分メカニズムによって、差分バックアップと復元がサポートされます: 部分ファイルと、最終変更時刻による差分ファイル。
  • 部分ファイル: SQL ライターでは、データベース ファイル内で変更されたバイト範囲をレポートするために、VSS の部分ファイル メカニズムが使用されます。
  • 最終変更時刻による差分ファイル: SQL ライターでは、フルテキスト カタログ内で変更されたファイルをレポートするために、最終変更時刻による VSS の差分ファイル メカニズムが使用されます。
  • 移動を伴う復元: SQL ライターでは、復元の間に VSS の新しいターゲットの指定がサポートされています。 VSS の新しいターゲットの指定を使用すると、復元操作の一部として、データベースとログ ファイルまたはフルテキスト カタログ コンテナーを再配置できます。
  • データベースの名前の変更: リクエスターでは、SQL データベースを新しい名前で復元することが必要な場合があります。特に、データベースを元のデータベースと左右に並べて表示して復元する場合などです。 SQL ライターでは、データベースが元の SQL インスタンス内にある限り、復元操作中にデータベースの名前を変更できます。
  • コピーのみのバックアップ: テストのためにデータベースのコピーを作成する必要がある場合など、特別な目的のバックアップを作成することが必要なことがあります。 このバックアップにより、データベースの全体的なバックアップと復元の手順に影響があってはなりません。 COPY_ONLY オプションを使用すると、バックアップは "帯域外" で実行するように指定され、通常のバックアップ シーケンスには影響しません。 SQL ライターでは、SQL Server インスタンスで "コピーのみ" のバックアップの種類がサポートされています。
  • データベース スナップショットの自動回復: 通常、VSS フレームワークを使用して取得された SQL Server データベースのスナップショットは、復旧されていない状態になります。 復旧フェーズを経てインフライト トランザクションがロールバックされ、データベースが一貫性のある状態になる前は、スナップショット内のデータに安全にアクセスすることはできません。 VSS バックアップ アプリケーションでは、スナップショット作成プロセスの一部として、スナップショットの自動復旧を要求することができます。

これらの新機能とその使用方法の詳細については、このトピックの「バックアップと復元のオプションの詳細」で説明しています。

サポートされていないもの

  • ログ バックアップは、SQL ライターではサポートされていません。
  • ファイルとファイル グループのバックアップはサポートされていません。
  • ページ復元はサポートされていません。
  • データベース スナップショットはサポートされておらず、コンポーネント ベースと非コンポーネント ベースどちらの VSS スナップショットを作成するときも無視されます。
  • AutoClose データベース、またはシャットダウンが有効になっているデータベース。
  • Linux では VSS フレームワークが提供されていないため、Linux では SQL ライターを使用できません

次の表では、SQL Server のすべてのエディションについて、VSS フレームワークを使用する SQL ライターと SQL Server によってサポートされているスナップショット バックアップの種類を示します。

バックアップと復元の操作 コンポーネント ベース 非コンポーネント ベース
完全なデータ バックアップ
(フルテキスト カタログを含む)		 はい はい
完全復元 はい はい
完全復元 (復旧なし) はい いいえ
差分バックアップ はい いいえ
差分復元 はい いいえ
移動を伴う復元 はい いいえ
データベースの名前変更 はい いいえ
[バックアップのみコピーする] はい いいえ
自動復旧されたスナップショット はい いいえ
ログ バックアップ いいえ いいえ
データベース スナップショット いいえ いいえ
AutoClose データベース
シャットダウンされるデータベース		 はい いいえ
可用性グループ データベース はい セカンダリでは、いいえ

バックアップ操作

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

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

バージョンのサポート

SQL ライターは SQL Server の一部として出荷され、SQL Server インスタンスのみをサポートします。 SQL ライターでは、SQL Server Express のインスタンスも列挙されます。 SQL Server Express によって起動されるユーザー インスタンスも、SQL ライターによって列挙されます。

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

非コンポーネント ベースのバックアップでは、スナップショット セット内のボリュームのリストを使用して、データベースが暗黙的に選択されます。 SQL ライターによって破損したデータベースがチェックされ、見つかった場合はエラーになります。 破損したデータベースとは、ファイルのサブセットがボリュームのリストで選択されているデータベースです。

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

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

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

このトピックの残りの部分では、SQL Server の VSS スナップショット作成プロセスの一部として、コンポーネント ベースのバックアップが使用されていることを前提とします。

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

VSS フレームワークによって、SQL Server スナップショットの作成の間に、リクエスター (バックアップ アプリケーション) と SQL ライターのアクティビティが調整されます。 この調整を有効にするため、VSS フレームワークでは、リクエスターとライターのインターフェイスが定義されています。 参加しているリクエスター アプリケーションとライターで、これらのインターフェイスが実装されている必要があります。 SQL ライターでは、必要なライター インターフェイスが実装されています。 スナップショット作成プロセスの一環として、SQL ライターのインターフェイスが、VSS フレームワークによって呼び出されます。 SQL ライターと、システム上の SQL Server インスタンスとの対話により、スナップショットの作成が促進されます。

VSS フレームワークでは、リクエスターつまりバックアップ アプリケーションによって使用される API のセットが定義されています。 バックアップ アプリケーションの開発者は、これらの API 呼び出しパターンに従って、VSS フレームワーク スナップショット作成プロセスを操作する必要があります。 次のセクションでは、SQL ライターの観点からスナップショット作成プロセスについて説明します。 また、リクエスター、VSS フレームワーク、SQL ライター、SQL Server インスタンスの間の内部的なやり取りについても詳しく説明します。 これらの手順および VSS フレームワーク インターフェイスについて詳しくは、ボリューム シャドウ コピー サービスに関するドキュメントをご覧ください。

Note

読者は、一般的な VSS フレームワークとバックアップ作成プロセスに精通しているものとします。 以下のセクションは、SQL ライターが VSS バックアップ作成プロセスに参加する方法に関する補足情報として提供されています。

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

データフロー

図では、コンポーネント ベースのスナップショット作成およびバックアップ操作の間のデータフロー図が示されています。 バックアップの実行に関する基本的なタスクをより深く理解するには、この概要を次のフェーズに分割すると役に立ちます。

  • バックアップの初期化
  • バックアップ検出フェーズ
  • バックアップ前タスク
  • ファイルの実際のバックアップ
  • バックアップの終了

バックアップの初期化

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

VSS フレームワークにより、OnIdentify イベントを使用して、SQL ライターを含む登録されている各ライターに、ライター メタデータが要求されます。 SQL ライターにより、SQL Server インスタンスのクエリが実行されて、各データベースのバックアップ メタデータ情報が取得され、ライター メタデータ ドキュメントが作成されます。 このフェーズは、メタデータの列挙とも呼ばれます。

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

  • アプリケーション ID とフレンドリ名。
  • ファイルとコンポーネントが存在する場所。
  • バックアップに含める必要があるファイルと、バックアップから除外する必要があるファイル。
  • 復元時に使用する必要があるオプション。
  • これは、VSS フレームワークを介してリクエスター元に返されます。

バックアップの検出

このフェーズでは、リクエスターにより、ライター メタデータ ドキュメントが調べられ、バックアップの必要なコンポーネントごとにバックアップ コンポーネント ドキュメントが作成されて設定されます。 また、このドキュメントの一部として、必要なバックアップ オプションとパラメーターが指定されます。 SQL ライターでは、バックアップする必要がある各データベース インスタンスは個別のコンポーネントになります。

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

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

バックアップ前タスク

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

通常、リクエスターは、ライターによってバックアップの準備が行われ、シャドウ コピーが作成されている間、待機しています。 バックアップ操作に参加している SQL ライターでは、ライターのファイルとライター自体を、バックアップとシャドウ コピーを実行できるように構成する必要があります。

バックアップの準備

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

SQL ライターには、バックアップが必要なデータベースの詳細が示されているバックアップ コンポーネント ドキュメントへのアクセス権が付与されています。 すべてのバックアップ ボリュームが、ボリューム スナップショット セットに含まれている必要があります。 SQL ライターによって (スナップショット セットの外部にバックアップ ボリュームがある) 破損したデータベースが検出されると、PostSnapshot イベントの間にバックアップは失敗します。

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

このフェーズでは、リクエスターは必要に応じて、データをバックアップ メディアに移動できます。 このステージでのやり取りは、リクエスターと VSS フレームワークの間で行われます。 SQL ライターは関係していません。

  1. ライターの状態を取得します。 ライターの状態を返します。 リクエスターは、ここでエラーの処理が必要な場合があります。
  2. バックアップを行います。

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

バックアップの完了

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

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

Note

リクエスターでは、このイベント (バックアップ完了イベント) を明示的に送信して、SQL ライターが差分ベースのバックアップをコミットできるようにする必要があります。 このイベントが受信されない場合、作成されるバックアップは、"差分ベース" バックアップの対象になりません。

ライター メタデータの保存

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

バックアップの終了

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

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

これは、ライター (この場合は SQL ライター) により IVssCreateWriterMetadata インターフェイスを使って作成される XML ドキュメントであり、ライターの状態とコンポーネントに関する情報が含まれます。 ライター メタデータ ドキュメントの詳細な構造については、VSS API のドキュメントをご覧ください。 ここでは、SQL ライター メタデータ ドキュメントの詳細の一部について説明します。

  • ライターの識別情報
    • ライター名 - L"SqlServerWriter"
    • ライター クラス ID - 0xa65faa63、0x5ea8、0x4ebc、0x9d、0xbd、0xa0、0xc4、0xdb、0x26、0x91、0x2a
    • ライター インスタンス ID - L"SQL Server:SQLWriter"
    • VSSUsageType - VSS_UT_USERDATA
    • VSSSourceType - 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
    • 名前 - コンポーネントの名前 (データベース名)
    • 論理パス – サーバー インスタンスの論理パス (名前付きインスタンスの場合は "サーバー\インスタンス名" の形式、既定のインスタンスの場合は "サーバー")
    • コンポーネント フラグ
    • VSS_CF_APP_ROLLBACK_RECOVERY – ファイルの整合性を保ち、ファイルをバックアップ以外 (つまり、アプリ ロールバック) のシナリオで使用できるようにするため、SQL Server スナップショットに常に "復旧" フェーズが必要であることを示します。
    • 選択可能 - True
    • 復元用に選択可能 - True
    • サポートされる復元方法 – VSS_RME_RESTORE_IF_CAN_REPLACE

SQL Server におけるコンポーネント セット構造の唯一の拡張は、フルテキスト カタログの導入です。 フルテキスト カタログはコンテナー ディレクトリであり、VSS データベースとログ ファイルに再帰的な指定がない場合、VSS データベースやログ ファイルとして表すことはできません。 そのため、SQL ライターでは、VSS ファイル グループ コンポーネント (VSS_CT_FILEGROUP) を使ってデータベース レベルのコンポーネントが表され、ファイル グループ ファイルを使ってデータベース、ログ、およびフルテキスト カタログ ファイルが表されます。

このドキュメントの最後には、ライター メタデータ ドキュメントの例が記載されています。

スナップショットの開始 リクエスターにより、VSS フレームワーク インターフェイスの DoSnapshotSet が呼び出されて、スナップショット プロセスが開始されます。

スナップショットの作成 このフェーズには、VSS フレームワークと SQL ライターの間の一連のやり取りが含まれます。

  1. "スナップショットの準備"。 SQL ライターにより SQL Server が呼び出されて、スナップショット作成の準備が行われます。
  2. 凍結。 SQL ライターにより SQL Server が呼び出されて、スナップショットでバックアップされる各データベースのすべてのデータベース I/O が凍結されます。 凍結イベントから VSS フレームワークに戻った後、VSS によってスナップショットが作成されます。
  3. "解凍"。 このイベントでは、SQL ライターによって SQL Server インスタンスが呼び出されて、通常の I/O 操作が "解凍" つまり再開されます。

データベースへのすべての書き込みがブロックされるのを防ぐため、スナップショット作成フェーズは高速 (60 秒未満) です。

スナップショット後 スナップショットの自動復旧が必要な場合は、スナップショットに含めるように選択されているデータベースごとに、SQL ライターによって自動復旧が実行されます。 詳しくは、「自動復旧されたスナップショット」をご覧ください。

復元プロセス

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

復元操作のワークフロー

次の図は、VSS の復元操作中のデータフロー図です。 復元の実行に関する基本的なタスクをより深く理解するには、この概要を次のトピックに分割すると役に立ちます。

  • 復元の初期化
  • 復元の準備
  • ファイルの実際の復元
  • 復元のクリーンアップと終了

復元プロセスの流れ

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

  • 復元前: SQL ライターにより、検証、ファイル ハンドルの終了などが処理されます。
  • 復元後: SQL ライターにより、データベースがアタッチされ、必要に応じてクラッシュ回復が行われます。

これら 2 つのフェーズの間に、バックアップ アプリケーションでは、SQL の下にある関連データを移動する必要があります。

復元の初期化

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

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

復元の準備

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

バックアップ アプリケーションで、現在の復元操作の上に差分バックアップまたはログ バックアップを適用する場合は (つまり、"NORECOVERY を使用して復元" が必要な場合)、復元する各データベースのコンポーネント作成の一環として、次のオプションを設定する必要があります。

IVssBackupComponents::SetAdditionalRestores(true)

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

SQL ライターでは、指定されたバックアップ コンポーネント ドキュメントが調べられ、適切なデータベースが特定されて、バックアップ時以降に作成されたその他のファイルが削除されます。 また、ディスク領域がチェックされ、開かれているデータベース ファイル ハンドルが閉じられて、復元フェーズの間にリクエスターが要求されたデータをコピーできるようにされます。 このフェーズでは、リクエスターでファイルのコピーが実際に行われる前に、早期エラー状態を検出することができます。 また、SQL Server によりデータベースが復元状態にされます。 この時点以降、復元が成功するまで、データベースを起動することはできません。

ファイルを復元する

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

クリーンアップと終了

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

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

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

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

DB ファイルのバックアップ ボリュームがボリューム スナップショット セットに追加されているため、SQL ライターを (バックアップと復元のコンテキスト外で) ボリューム シャドウ コピー作成プロセスに含めることができます。 この場合、SQL ライターが参加するのは、メタデータの列挙、凍結、解凍、PostSnapshot の調整だけです (詳しくは、データフロー図を参照してください)。

完全なバックアップと復元

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

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

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

バックアップ

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

復元

リクエスターにより、非コンポーネント ベース モードでバックアップされたデータベースが復元されます。 そのような復元の後で、ログ復元や差分復元などのロールフォワード復元を行うことはできません。

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

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

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

バックアップ

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

ロールフォワードなしの完全復元

データベース バックアップの完全復元は、追加のロールフォワードを行わずに実現されることがあります。 これは、ロールフォワードを容易にするためのメタデータが存在しないこと、または場合によってはロールフォワードが必要ないことが原因である可能性があります。 このセクションでは、これらの 2 つの状況について簡単に説明します。

メタデータもロールフォワードもない

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

メタデータはあるが、追加のロールフォワードは必要ない

リクエスターにより、コンポーネント ベース モードでバックアップされたデータベースが復元されますが、ロールフォワードは要求されません。 この場合、SQL Server により、復元の一環としてデータベースのクラッシュ復旧が実行されます。

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

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

これは、バックアップの間にライター メタデータが保存され、復元時に SQL ライターでそれを使用できる場合にのみ可能です。 リクエスターが VSS に復元アクティビティの実行を指示する前に、SQL Server サービスが実行されている必要があります。

SQL ライターでは、次のシーケンスが想定されます。

  1. 各データベースの復元の準備。 このアクティビティでは、リクエスター アプリケーションでデータベース ファイルをコピーまたはマウントできるように、すべてのファイル ハンドルを閉じる必要があります。
  2. ファイルは、リクエスター アプリケーションによってコピーおよびマウントされます。
  3. 復元の最終処理を行います (NORECOVERY で)。 データベースはオンラインになりますが、"復元中" 状態になります。

従来の SQL バックアップ (差分またはログ) を使用して、VDI/T-SQL により、または VSS フレームワークを使用して差分復元を適用することにより、データベースをロールフォワードすることができます。

フルテキストのサポート

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

差分バックアップおよび復元

差分バックアップ操作では、最後の完全バックアップ以降に変更されたデータのみがバックアップされます。 差分バックアップには、変更されたデータベース ファイルの部分のみが含まれます。 そのようなバックアップを行うには、ファイルの適切なセクションをバックアップできるように、バックアップ アプリケーションつまりリクエスターが、データベース ファイル内の変更箇所に関する情報を持っている必要があります。 差分バックアップ操作の間に、SQL ライターによって、"VSS 部分ファイル情報" で指定されている形式でこの情報が提供されます。この情報はデータベース ファイルの変更された部分のみをバックアップするのに使用されます。

バックアップ

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

バックアップ前タスク フェーズの間に、SQL ライターでは、選択された各データベースに 1 つの差分ベースが存在することを確認します。

PostSnapshot イベントの間に、SQL ライターでは、SQL Server から部分ファイル情報が取得され、IVssComponent::AddPartialFile の呼び出しを使ってバックアップ コンポーネント ドキュメントに追加されます。

Note

SQL ライターでは、差分バックアップに対して 1 つの差分ベースラインのみがサポートされています。 複数のベースラインはサポートされていません。

部分ファイル情報の形式

差分バックアップの間にバックアップされるデータベースごとに、SQL ライターによって、各データベース ファイルの部分ファイル情報が格納されます。 この情報は、ファイルの実際のバックアップの間に、ファイルの関連部分のみをバックアップ メディアにコピーするため、リクエスターつまりバックアップ アプリケーションによって使用されます。 この部分ファイル情報の形式について詳しくは、ボリューム シャドウ コピー サービスのドキュメントをご覧ください。

リクエスターは、これらのファイルを IVssComponent::GetPartialFileCount または IVssComponent::GetPartialFile を呼び出して確認できます。 IVssComponent::GetPartialFile では、ファイルを指すパスとファイル名、およびファイル内でバックアップが必要な部分を示す範囲文字列が返されます。

部分ファイル情報の取得について詳しくは、VSS のドキュメントをご覧ください。

ファイルのバックアップ

このフェーズの間に、バックアップ アプリケーションでは、バックアップ コンポーネント ドキュメントに格納されているライター メタデータを調べて、ファイルの関連部分のみをバックアップする必要があります。 (フルテキスト カタログ ファイルの場合、このバックアップは、ファイルのタイムスタンプに基づいて行われる必要があります。これについては、このドキュメントで後ほど説明します)。

差分バックアップは、常に、データベースに存在する最新のベース バックアップに対して行われます。 復元時には、SQL Server によって、ベース バックアップと差分バックアップの不一致が検出されます。 そのため、バックアップ アプリケーションまたはシステム管理者は、差分が予想される完全バックアップに対するものであることを確認する必要があります。 帯域外の手順によって別の完全バックアップが行われた場合、バックアップ アプリケーションでは、ベース バックアップを "所有" していないため、差分を復元できない可能性があります。

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

トラブルシューティング

ファイルの追加、削除、圧縮、拡張、論理名の変更、物理名の変更では、バックアップで興味深いケースが発生します。

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

SQL データベース ファイルのすべてのヘッダーが部分指定に含まれている必要があるため、これらのファイルは部分指定に含まれます。 ヘッダー ページだけでなく、すべての割り当て済みページが部分指定に含まれる必要があります。

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

ベースが取得された後、データ ファイルが削除される可能性があります。 そのようなファイルは、差分バックアップの間にライター メタデータ ドキュメントに含まれません。 さらに、削除されたファイルには部分情報が関連付けられていません。

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

サーバーでファイルの圧縮が無効になるまで、部分情報はファイルから収集されません。 これにより、データ ファイルの圧縮領域に対応する部分情報が含まれないことが保証されます。

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

部分情報が収集される前に拡張が行われた場合、部分情報には、拡張された領域の割り当て済みページが含まれるはずです。 部分情報が収集された後で拡張が行われた場合、部分情報には、拡張された領域での変更は含まれません。 次のセクションでは、そのような変更がログのロールフォワードによって復元されることを見ます。

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

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

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

データベース ファイルの物理名の変更は、データベースが再起動されるまで有効になりません。 そのため、部分情報バッファー内のデータベース構成情報またはファイル パス情報は、古い物理パスにまだ基づいており、これだけがスナップショット上でのそれらのデータベース ファイルへの有効なパスです。

復元

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

復元前フェーズ

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

ファイルを復元する

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

復元時にも、データベース ファイルの追加、削除、拡張、圧縮、論理名の変更、物理名の変更に関して興味深いケースが発生します。

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

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

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

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

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

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

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

SQL Server では、メタデータに従ってファイルを必要なサイズに切り捨てる必要があります。 これは、準備ステップとして復元の前に行われます。

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

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

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

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

復元後

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

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

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

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

OnIdentify

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

ベース タイムスタンプの設定

ベース タイムスタンプは、完全バックアップの間に設定されます。 OnPostSnapshot() では、ライターによって IVssComponent::SetBackupStamp() が呼び出されて、タイムスタンプとコンポーネントがバックアップ ドキュメントに格納されます。

差分バックアップ

バックアップ アプリケーションによって、このタイムスタンプがベース完全バックアップから取得され、IVssComponent::GetBackupStamp() が呼び出されて前のベース バックアップからベース スタンプが取得されることで、ライターでこのタイムスタンプを使用できるようになります。 その後、IVssBackupComponent::SetPreviousBackupStamp() を呼び出してライターが使用できるようにします。 ライターは次に、IVssComponent::GetPreviousBackupStamp() を呼び出してスタンプを取得し、それをIVssComponent::AddDifferencedFilesByLastModifyTime() で使用するタイムスタンプに変換します。

差分バックアップの間のバックアップ アプリケーションの役割 差分バックアップの間に、バックアップ アプリケーションでは次のことを行う必要があります。

  • コンポーネントでファイルに対して設定された "最終変更時刻" で指定されているタイムスタンプより後の最終変更タイムスタンプを持つすべてのファイル (ファイル全体) をバックアップします。
  • 削除されたファイルを追跡して検出します。

差分復元の間のバックアップ アプリケーションの役割 差分復元の間に、バックアップ アプリケーションでは次のことを行う必要があります。

  • バックアップされているすべてのファイルを、まだ存在しない場合は新しいファイルを作成し、既に存在する場合は既存ファイルを上書きすることにより、復元します。
  • 復元するファイルが既存のファイルより大きい場合は、内容を配置する前にファイルを拡張します。
  • 復元するファイルが既存のファイルより小さい場合は、復元するファイルと同じサイズにファイルを切り捨てます。
  • 削除する必要があるすべてのファイルを削除します。つまり、差分バックアップの時点で存在していてはならないファイルです。

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

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

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

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

移動を伴う復元

VSS では、バックアップ アプリケーション (リクエスター) で IVssComponent::SetNewTarget を呼び出して新しい復元ターゲットを指定できます。 PreRestore() と PostRestore() の両方で、少なくとも 1 つの新しいターゲットが指定されているかどうかが SQL ライターによって確認されます。 バックアップ アプリケーションでは、ファイルを実際に復元またはコピーするときに、ファイルを新しい場所に物理的にコピーする必要があります。

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

データベースの名前変更

リクエスターでは、SQL データベースを新しい名前で復元することが必要な場合があります。特に、元のデータベースとサイドバイサイドでデータベースを復元する場合などです。 このオプションは、VSS の呼び出し IVssBackupComponents::SetRestoreOptions() (wszRestoreOptions パラメーター内) を使用して、カスタム復元オプションを "新しいコンポーネント名" = < "新しい名前" > として設定することにより、復元操作中にリクエスターによって指定できます。

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

Note

現在、SQL ライターでは、データベースを新しいインスタンスに移動するための "インスタンス間での名前の変更" はサポートされていません。

自動復旧されたスナップショット

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

スナップショット作成プロセスの一部として、スナップショットを自動復旧することはできます。 ライター メタデータ ドキュメントの一部として、SQL ライターによりコンポーネント フラグ VSS_CF_APP_ROLLBACK_RECOVERY が指定されて、スナップショット セットを指定するときにデータベースにアクセスする前に、スナップショット上のデータベースに対して復旧を実行する必要があることが示されます。リクエスターでは、スナップショットがアプリ ロールバック スナップショット (つまり、スナップショット内のすべてのデータベース ファイルは、アプリケーションの使用に関して一貫性のある状態であることが想定されます) またはバックアップ スナップショット (後でシステム エラーの場合に復元されるデータをバックアップするために使用されるスナップショット) である必要があることを示すことができます。

リクエスターでは、VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY を設定して、このコンポーネントがバックアップ以外の目的でバックアップされていることを示す必要があります。 その後、VSS により、選択されたコンポーネントに対して SQL ライターによって指定された VSS_CF_APP_ROLLBACK_RECOVERY と VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY が関連付けられて、自動復旧が行われていることが確認されます。 VSS により、一定の期間だけスナップショットが書き込み可能にされ、スナップショット コンテキストに VSS_VOLSNAP_ATTR_AUTORECOVERY ビットが自動的に追加されます。

SQL Server の場合、自動復旧はアプリ ロールバック スナップショットのみに適用し、バックアップ スナップショットには適用しないようにする必要があります。 アプリ ロールバック スナップショットの場合、PostSnapShotevent の間に SQL ライターによって自動復旧プロセスが開始されます。 このプロセスでは、スナップショット セット内で (リクエスターによって) 明示的に選択された各 SQL Server データベースに対して、次の処理が行われます。

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

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

  • ログ ファイルが圧縮されます。

    これにより、VSS プロバイダーが "ソフトウェア プロバイダー" である場合に、VSS フレームワークによって行われる必要がある不要な "書き込み時コピー" の量を減らすことができます。 ログ ファイルの圧縮は既定の動作です。 これは、次のレジストリ キーの値を 1 に設定することで無効にできます。

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

    これは、オンライン データベースの問題を修正するために、スナップショットを使用して、ログの (特定時点の) 特定ページからデータをエクスポートする場合に便利です。

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

これで、クエリのためにアタッチできる、一貫性のある復旧済みのスナップショットになりました。

複数データベースのトランザクション

場合によっては、スナップショット データベースに実行中のマルチデータベース トランザクションがいくつか含まれていることがあります。 復旧操作の間に、SQL ライターによって、想定されるアボート オプションを使用して、スナップショットのデータベースがアタッチされます。 これにより、まだコミットされていないマルチデータベース トランザクションがロールバックされます (コミット準備完了状態のトランザクションも含まれます)。 これにより、スナップショット セット内のデータベース間に不整合が発生する可能性があります。 たとえば、A と B の 2 つのデータベースについて考えます。これら 2 つのデータベースの間には分散トランザクションがあり、このトランザクションはデータベース A ではコミット済み状態に、データベース B ではコミット準備済み状態になっています。自動復旧プロセスの一環として、このトランザクションがデータベース A ではコミットされ、データベース B ではロールバックされます。これにより、スナップショット セットにいくつかの不整合が生じる可能性があります。

VSS フレームワークによって Longhorn 期間中にリリースされる Microsoft 分散トランザクション コーディネーター (MS DTC) コンポーネントでは、複数の SQL Server インスタンスにまたがるデータベースが含まれるトランザクションに関するこの不整合の問題が修正されます。 次のバージョンの SQL Server では、1 つの SQL Server インスタンス内の複数のデータベースにまたがるトランザクションでの、このような不整合が修正されます。

自動復旧されたスナップショットでのセキュリティへの影響

VSS スナップショットの場合、自動復旧の後、ファイルはアクセス制御リスト (ACL) を使用して、SQL Server アカウントが属している特殊な組み込みグループにのみアクセスを許可することで保護されます。 これは、コンピューター管理者またはその特殊なグループのメンバーが、データベースをアタッチできることを意味します。 スナップショット上のデータベース ファイルのアタッチを要求するクライアントは、組み込みの Administrators のメンバーであるか、または SQL Server アカウントである必要があります。

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

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

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

master データベースの復旧と共に、ユーザー データベースを復旧してロールフォワードする場合は、インスタンスで master データベースとユーザー データベースを一緒に起動して復旧することはできません。

手順は次のとおりです。

  1. SQL Server インスタンスが確実に停止されているようにします。
  2. 2 つのフェーズで復元を実行します。
    1. VSS でファイルのコピーとボリュームのマウントにより、同時に復旧する必要があるシステム データベースとユーザー データベース (つまり、単純復旧モデルのユーザー データベース) を復元します。
      1. ロールフォワード対象のユーザー データベースがシステム データベースと同じボリューム上にない場合は、この時点でそのボリュームを復元することはできません。 このシナリオでは、バックアップの前に計画を立てる必要があります。
      2. ユーザー データベースがシステム データベースと同じボリューム上にある場合は、ユーザー データベースを SQL Server から隠ぺいする必要があります。
    2. -f パラメーターを使用して、SQL Server インスタンスを開始します。 (-f スタートアップ オプションを使用すると、master データベースだけを復元できます。)
      1. ロールフォワードする各データベースに対し、ALTER DATABASE <x> SET OFFLINE を発行します。 (または、データベースをデタッチします)
      2. SQL Server のインスタンスを停止します。
      3. SQL Server のインスタンスを起動します (ロールフォワードするユーザー データベースのファイルは SQL Server から認識されません)。

「ロールフォワードによる完全復元」で説明されているように、VSS を使用し、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"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file
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

フルテキスト ファイル log:

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

フルテキストファイル foo:

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

フルテキスト ファイル bar:

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" の 1 つの部分になります。

特殊なケース

ここでは、SQL ライター ベースのバックアップおよび復元操作の間に発生する特殊なケースの一部について説明します。

AutoClose データベース

非コンポーネント ベースのバックアップでは、破損状態をチェックするときにデータベースの自動終了が行われますが、自動終了されたデータベースは、バックアップ操作の間に明示的に凍結されません。

ここで想定されるシナリオは、終了されたデータベースが多数存在し、スナップショットのコストを最小限に抑える必要があることです。 自動終了されたデータベースは、通常、リソースが不足しているローエンド構成で使用されます。

ファイル一覧

各データベースのファイルの一覧は、バックアップ準備イベントより前の列挙ステップの間に決定されます。 列挙と凍結の間でデータベース ファイルの一覧が変更された場合、アプリケーションでファイルの一覧を再チェックしない限り、データベースが破損する可能性があります。 Microsoft ではこれが問題になるとは想定していませんが、ベンダーは知っておく必要があります。

停止したインスタンス

列挙ステップが発生したときに SQL Server のインスタンスが実行されていない場合、それらのインスタンスのデータベースは選択できません。

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

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

SQL Server のシステム データベースには、SQL Server の一部として出荷およびインストールされる master、model、msdb の各データベースが含まれています。 ここでは、VSS スナップショット バックアップ プロセスでのこれらのデータベースの処理方法について説明します。

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

SQL ライターでは、インスタンスをシャットダウンせずに、model データベースと msdb データベースの両方をオンラインで復元できます。

参照

SQL Server バックアップ アプリケーション - SQL ライター ログ
BACKUP (Transact-SQL)
RESTORE (Transact-SQL)
SQL Server データベースのバックアップと復元
コピーのみのバックアップ (SQL Server)
トランザクション ログのバックアップ (SQL Server)
トランザクション ログ バックアップの適用 (SQL Server)
SQL Server トランザクション ログのアーキテクチャと管理ガイド