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

適用対象:SQL Server - Windows のみ

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

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

VSS では、Windows システム上で 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 ライターの役割は次のとおりです。

SQL ライターを構成する

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

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

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

SQL ライターを再度有効にして起動する

既定では、SQL ライター サービスは有効になり、自動的に開始されます。 この構成が変更された場合は、次の手順を実行して既定の設定に戻す必要があります。

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

その後、前に説明したサービス プロパティ画面の [サービスの状態] プロパティの下にある [開始] ボタンを選択して、サービスを開始する必要があります。

SQL ライターでサポートされる機能

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

• 差分バックアップと復元: SQL ライターは、次の 2 つの VSS 差分メカニズムを使用した差分バックアップと復元をサポートします。

  • 部分ファイル: SQL ライターは、VSS 部分ファイル メカニズムを使用して、データベース ファイル内の変更されたバイト範囲を報告します。

  • 最終変更時刻によるファイルの相違: SQL ライターは、フルテキスト カタログ内の変更されたファイルをレポートするために、VSS の差分ファイルと最終変更時刻のメカニズムを使用します。

• 移動による復元: SQL ライターは、復元中に VSS の新しいターゲット仕様をサポートします。 新しいターゲット仕様では、データベース/ログ ファイルまたはフルテキスト カタログ コンテナーを復元操作の一部として再配置できます。

• データベース名の変更: リクエスタは、特にデータベースを元のデータベースと並行して復元する場合に、新しい名前で SQL Server データベースを復元する必要がある場合があります。 SQL ライターでは、データベースが元の SQL インスタンス内にある限り、復元操作中にデータベースの名前を変更できます。

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

• データベース スナップショットの自動回復: 通常、VSS フレームワークを使用して取得された SQL Server データベースのスナップショットは、復旧されていない状態です。 スナップショット内のデータは、復旧フェーズを経て、インフライト トランザクションをロールバックし、データベースを一貫した状態にする前に安全にアクセスすることはできません。 VSS バックアップ アプリケーションは、スナップショット作成プロセスの一環として、スナップショットの自動回復を要求できます。

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

サポートされていないこと

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

次の表に、WINDOWS 上のすべてのエディションの SQL Server の VSS フレームワークを操作する SQL ライター/SQL Server でサポートされるスナップショット バックアップの種類を示します。

バックアップ操作

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

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

バージョンのサポート

SQL ライターは SQL Server の一部として出荷され、SQL Server インスタンスのみをサポートします。 SQL ライターは、SQL Server Express エディションによって起動されたユーザー インスタンスを含め、SQL Server Express インスタンスも列挙します。

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

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

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

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

アプリケーション (VSS バックアップ アプリケーション) は SQL ライターから返されるメタデータからデータベースを明示的に選択するため、コンポーネント ベースのバックアップは 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 フレームワーク インターフェイスの詳細については、「 ボリューム シャドウ コピー サービス (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 ライターでバックアップを差分ベースとしてコミットできます。

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

リクエスタは、バックアップ コンポーネント ドキュメントと各コンポーネント バックアップ メタデータを、スナップショットからバックアップされたデータと共に保存する必要があります。 これらのライター メタデータは、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
  • 名前 - コンポーネントの名前 (データベース名)
  • 論理パス – サーバー インスタンスの (名前付きインスタンスの場合は "server\instance-name"、既定のインスタンスの場合は "server" の形式)。
  • コンポーネント フラグ
  • 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 ライターは、復元プロセスの最初でこのデータへのアクセス権を取得します。

復元の準備

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

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

IVssBackupComponents::SetAdditionalRestores(true)

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

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

ファイルを復元する

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

クリーンアップと終了

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

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

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

リクエスターでボリュームのシャドウ コピーを作成

データベース ファイルのバッキング ボリュームがボリューム スナップショット セットに追加されているため、(バックアップと復元のコンテキスト外で) ボリューム シャドウ コピー作成プロセスに SQL ライターが関与する可能性があります。 この場合、SQL ライターはメタデータ列挙、 Freeze、 Thaw、 PrepareForSnapshot、および 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 Server バックアップ、差分バックアップ、またはログを使用して、VDI または Transact-SQL を介してデータベースをロールフォワードしたり、VSS フレームワークを使用して差分復元を適用したりできます。

フルテキスト サポート

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

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

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

バックアップ

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

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

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

部分ファイル情報の形式

差分バックアップ中にバックアップされるデータベースごとに、SQL ライターは各データベース ファイルの部分的なファイル情報を格納します。 この情報は、ファイルの実際のバックアップの間に、ファイルの関連部分のみをバックアップ メディアにコピーするため、リクエスターつまりバックアップ アプリケーションによって使用されます。

この部分ファイル情報の形式の詳細については、「 ボリューム シャドウ コピー サービス (VSS)」を参照してください。

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

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

ファイルのバックアップ

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

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

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

トラブルシューティング

ファイルの追加/ドロップ/圧縮/増加/論理名の変更/物理名の変更は、バックアップのトラブルシューティングで興味深いケースになります。

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

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

ベースの取得後にドロップされたファイル

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

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

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

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

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

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

ファイルの論理名はライター メタデータ ドキュメントまたはバックアップ コンポーネント ドキュメント内のどこにも参照されないため、ファイルの論理的な名前変更はバックアップまたは復元には影響しません。

詳細については、「 ライター メタデータ ドキュメント: この記事の後半の例」を参照してください。

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

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

復元

差分復元の間に、リクエスターによって 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 フルテキスト カタログ バックアップの場合、これはすべてのフルテキスト カタログ コンテナーに対して、差分バックアップがシングル タイムスタンプ ベースであることを意味します。ネイティブ SQL Server 差分バックアップの場合とは異なり、フルテキスト カタログ コンテナーごとにタイムスタンプ ベースが 1 つ存在します。

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設定することで、コピーのみのバックアップを実行する機能を示します。 リクエスタは、VSS_BACKUP_TYPE オプションを呼び出しIVssBackupComponents::SetBackupStateでVSS_BT_COPYに設定することで、バックアップの種類をコピーのみのバックアップとして設定できます。

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

移動を伴う復元

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

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

データベース名の変更

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

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

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

通常、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 Server では、スナップショット データベースに一部のインフライト マルチデータベース トランザクションが含まれている場合があります。 復旧操作中、SQL ライターは、推定中止オプションを使用してスナップショットにデータベースをアタッチします。 これにより、まだコミットされていないマルチデータベース トランザクション (準備完了コミット状態のトランザクションを含む) がロールバックされます。 これにより、スナップショット セット内のデータベース間にいくつかの不整合が発生する可能性があります。

たとえば、2 つのデータベース A と B を考えてみましょう。これら 2 つのデータベース間には分散トランザクションがあり、このトランザクションはデータベース A のコミット済み状態であり、データベース B のコミット準備済み状態です。自動回復プロセスの一環として、このトランザクションはデータベース A でコミットされ、データベース B にロールバックされます。これにより、スナップショット セットに一部の不整合が発生する可能性があります。

新しいバージョンの Windows には、SQL Server インスタンス間のデータベースにまたがるトランザクションに関するこの不整合の問題を修正する、Microsoft 分散トランザクション コーディネーター (MS DTC) コンポーネントが強化されています。 新しいバージョンの SQL Server では、SQL Server インスタンス内のデータベースにまたがるトランザクションに対するこれらの不整合が修正されます。

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

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

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

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

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

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

手順は次のとおりです。

1. SQL Server インスタンスが確実に停止されているようにします。

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

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

      • ロールフォワードするユーザー データベースがシステム データベースと同じボリューム上にない場合は、この時点でそのボリュームを取り戻すべきではありません。 このシナリオでは、バックアップの前に計画が必要です。

      • ユーザー データベースがシステム データベースと同じボリューム上にある場合は、ユーザー データベースを SQL Server から隠ぺいする必要があります。

   2. -f パラメーターを使用して SQL Server インスタンスを起動します。 ( -f スタートアップ オプションを使用する場合は、 master データベースのみを復元できます)。

      1. ロールフォワードするデータベースごとに ALTER DATABASE <database> SET OFFLINE を発行 (またはデータベースをデタッチ) します。

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

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

VSS を使用して、追加のロールフォワードによる完全復元の説明に従って、ユーザー データベースWITH NORECOVERYを復元します。

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

マシン Server1上の SQL Server インスタンス Instance1に属する DB1 という名前のデータベースには、次のデータベース/ログ ファイルが含まれています。

• c:\db\DB1.mdf に格納されている "primary" という名前のデータベース ファイル
• c:\db\DB1.ndf に格納されている "secondary" という名前のデータベース ファイル
• に格納されている "log" という名前のデータベース ログ ファイル c:\db\DB1.ldf
• ディレクトリの下に格納されている "foo" という名前のフルテキスト カタログ c:\db\ftdata\foo
• ディレクトリの下に格納されている "bar" という名前のフルテキスト カタログ c:\db\ftdata\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

フルテキスト ファイル ログ:

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

フルテキスト ファイル バー:

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

サーバー インスタンスがコンピューター上の既定のインスタンスである場合、論理パスは 1 つの部分 ( Server1) になります。

特殊なケース

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

AutoClose データベース

コンポーネントベース以外のバックアップでは、破損した状態をチェックするときにデータベースの自動クロースが行われますが、自動閉じ込めされたデータベースはバックアップ操作中に明示的に固定されません。

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

ファイル一覧

各データベースのファイルの一覧は、バックアップの準備イベントの前に列挙手順中に決定されます。 列挙と凍結の間でデータベース ファイルの一覧が変更された場合、アプリケーションでファイルの一覧を再チェックしない限り、データベースが破損する可能性があります。 このシナリオはほとんどありませんが、ベンダーが認識する必要があります。

停止されたインスタンス

列挙手順の実行時に SQL Server のインスタンスが実行されていない場合は、それらのインスタンスのデータベースを選択できません。

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

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

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

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

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

関連コンテンツ

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