QNAP の iSCSI ストレージを使用した SQL Server のスナップショットバックアップについて at SE の雑記

ここ数日、ストレージの機能を使用した SQL Server のデータベースのスナップショットバックアップについて調査を行っていました。

手元で準備できる機材では、QNAP の iSCSI ストレージの機能を使用した場合に SQL Server のデータベースのスナップショットバックアップの検証を行うことができましたので、調査した内容をまとめておきたいと思います。

Contents

1 ドキュメント
2 ツール
3 検証可能なワークロード
4 動作確認時のポイント
- 4.1 データベースアクセスの停止の確認
- 4.2 SQL Server で実行されているバックアップステートメントの確認
5 SQL Server 2022 / 2025 の機能と組み合わせたバックアップ取得

ドキュメント

SQL Server / QNAP のドキュメントとしては次のようなものがあり、スナップショットバックアップを使用する際にはこれらの情報を一読しておくとよいでしょう。

SQL Server

QNAP

以下は、必ず一読する必要はないのですが、検証をする中で使用する可能性のあるツールのドキュメントとなります。

ツール

QNAP と SQL Server (厳密には VSS) を連携させるため、スナップショットの取得を行う SQL Server には次のツールをインストールしておきます。

「NetBak Replicator」については必須ではないのですが「QNAP Snapshot Agent」については、SQL Server に必須でインストールが必要となります。

このツールをインストールすることで、VSS のハードウェアプロバイダーとして「QNAP VSS HW Provider」がインストールされます。アプリケーションとして「QNAP Snapshot Agent Manager」も追加されますので、このアプリを使用して QNAP のストレージとの接続を行うことで、VSS と QNAP を連携させることができるようになります。(QNAP のストレージから、TCP 11169 で Windows に接続が行われますので、F/W でこの通信の許可をする必要があります)

検証可能なワークロード

アプリケーション整合性バックアップとクラッシュ整合性バックアップ

スナップショットバックアップを取得する場合、アプリケーション整合性バックアップと、クラッシュ整合性バックアップの 2 種類があるかと思います。

Snapshot consistency

SQL Server のアプリケーション整合性バックアップは、バックアップ対象のユーザーデータベースの物理ファイルへの I/O を一時的に凍結して、物理ファイルにアクセスが行われない静止点を作り出すことで整合性が担保された状態を作り出します。

そのため、この方法を使用した場合、何らかの方法で SQL Server 上では瞬間的に I/O の停止が発生します。

クラッシュ整合性バックアップについては、サービスや I/O を停止させずに、バックアップを取得する方法となります。

この場合、SQL Server 観点で見た場合、予期せぬサーバーのシャットダウン / サービスのシャットダウンが行われた状態に近いものとなり、I/O の静止点は作成されません。また、SQL Server のリカバリは、サービス起動時のリカバリ処理に任せることになります。

基本動作としては自動復旧処理でリカバリが行われるはずではありますが、バックアップ取得時のデータベースの更新状況によっては、復旧に時間がかかる可能性があります。また、基本的には復旧可能なはずではありますが、サービスが起動し I/O の整合性が担保されていない状態で取得されているものとなりますので、100% 復旧できるものになっているかというと、クラッシュ整合性バックアップではその保証をするのは難しいのではないでしょうか。

検証ができパターン

QNAP の iSCSI ストレージを使用して、SQL Server のスナップショットバックアップを検証する際に、私が確認できたワークロードとしては次の内容となります。

どのバックアップ方法も「SQL Server のユーザーデータベースを格納している iSCSI のドライブを対象」としてバックアップを取得しています。

Windows Server バックアップを使用したアプリケーション整合性バックアップ

このパターンについては QNAP のストレージは関係ないかと

QNAP の管理コンソールを使用したクラッシュ整合性バックアップ
QNAP NetBak Replicator を使用したアプリケーション整合性バックアップ

このパターンについては動作することを確認しています。

検証ができなかったパターン

検証をしたパターンの中には「QNAP の管理コンソールを使用したアプリケーション整合性バックアップ」があるのですが、私が試せた範囲ではこのパターンを正常に動作させることができませんでした。

このパターンの検証をすると、次のエラーが発生しました。

COM セキュリティのアクセス許可に起因したエラー
VSS ライター使用時のエラー (VSS 12293 のエラー)

「1.」については、「dcomcnfg」から COM セキュリティに「NETWORK SERVICE」のアクセス許可を付与することで対応ができたのですが「2.」については、エラーを解決することができませんでした。

エラーの内容としては次のようなエラーとなっています。

ボリュームシャドウコピーサービスエラー: シャドウコピープロバイダー {dda91ecd-e902-47c1-8f9c-111a64e15678} 上でルーチンの呼び出し中にエラーが発生しました。ルーチンの詳細 LocateLuns returned 0x80042320 [hr = 0x80042320, シャドウコピーはすべて正常にインポートされませんでした。
]。

操作:
   ディスクを露出しています
   シャドウコピー LUN を検索しています
   PostSnapshot イベント
   非同期操作を実行しています

コンテキスト:
   実行コンテキスト: Provider
   プロバイダー名: QNAP VSS HW Provider
   プロバイダーバージョン: 1.0.1324
   プロバイダー ID: {dda91ecd-e902-47c1-8f9c-111a64e15678}
   現在の状態: DoSnapshotSet

QNAP の管理コンソールの操作を起点として、接続している Windows の VSS と連動を行おうとする動作までは確認ができているのですが、連動した後の挙動を正常に完了させることができておらず、このパターンは実施できていません。

そのため、アプリケーション整合性バックアップの検証については「QNAP NetBak Replicator を使用したアプリケーション整合性バックアップ」で実施しています。

動作確認時のポイント

前述のパターンの中で今回は「QNAP NetBak Replicator を使用したアプリケーション整合性バックアップ」を使用して検証を実施しています。

このパターンでの挙動は次のようになります。

SQL Server がインストールされている Windows 上で、QNAP NetBak Replicator を使用して、SQL Server のユーザーデータベースを格納している iSCSI のドライブのバックアップを取得
SqlServerWriter (SQL Server の VSS Writer) と連動し、SQL Server としてアプリケーション整合性が担保されたバックアップが取得される

この挙動が行われる場合、次のような確認を行います。

データベースアクセスの停止の確認

データベースアクセスの停止の確認については、SQL Server の ERROR ログか、イベントビューアーのアプリケーションから確認をします。

アプリケーション整合性バックアップとして正常に、I/O の静止点が作成できている場合、次のようなログが出力されています。

2025-09-15 21:11:07.630 spid58 I/O is frozen on database UserDB. No user action is required. However, if I/O is not resumed promptly, you could cancel the backup.
2025-09-15 21:11:08.910 spid58 I/O was resumed on database UserDB. No user action is required.

上記のログであれば、1.3 sec 程度、I/O が停止されており、この期間はユーザーデータベースにアクセスができない状態となっています。

この I/O の停止は、SQL Server の VSS Writer が実行していますので、SQL Server VSS Writer のログからも停止を確認できます。

ログは「C:\Program Files\Microsoft SQL Server\90\Shared\SqlWriterLogger.txt」から確認ができます。(以下のログは「SqlWriterConfig.ini」で「TraceLevel=VERBOSE」を指定していますので、標準の出力とは少し異なります)

[09/15/2025 21:11:07, TID 24f0] CSqlWriter::OnFreeze: Entering SQL Writer OnFreeze.
[09/15/2025 21:11:08, TID 24f0] CSqlWriter::OnThaw: Entering SQL Writer OnThaw.

このようなログを確認することで、データベースアクセスの停止が実行されているか / どの程度発生しているかを確認することができます。

SQL Server で実行されているバックアップステートメントの確認

アプリケーション整合性バックアップが取得される場合、SQL Server に対してバックアップステートメントが実際に実行されます。

この際のアプリケーション名は「Microsoft SQL Server VSS Writer」となるため、このアプリケーションから実行されているクエリをトレースすることでどのようなステートメントが実行されているかを把握することができます。

ポイントとして考慮する必要があるものとして「COPY_ONLY」バックアップが取得されているかは把握する必要があるのではないでしょうか。

-- QNAP NetBak Replicator 
BACKUP DATABASE [UserDB] TO VIRTUAL_DEVICE='{973C74DA-ED89-4BB8-B8B0-3FE2762B2E1E}1' 
WITH SNAPSHOT,BUFFERCOUNT=1,BLOCKSIZE=1024

-- WindowsServer Backup
BACKUP DATABASE [UserDB] TO VIRTUAL_DEVICE='{95CF6B30-9B59-4D16-B19B-6E2BC7AA1D9A}1' 
WITH SNAPSHOT,BUFFERCOUNT=1,BLOCKSIZE=1024,COPY_ONLY

上が QNAP NetBak Replicator / 下が Windows Server バックアップで「VSS コピーバックアップ」を使用して取得したバックアップの実行時に実行されていたステートメントとなります。

QNAP NetBak Replicator は VSS と連動して ISCSI のドライブのバックアップが取得できるのですが、Windows Server バックアップのような「VSS コピーバックアップを使用する」というオプションがありませんでした。

これはバックアップに使用するツールに依存したものとなるため、他のバックアップツールで QNAP VSS Hardware Provider で連携させた場合には、VSS コピーバックアップが取得できる可能性がありますが、QNAP NetBak Replicator ではコピーバックアップの取得は難しそうでした。

通常の運用バックアップとは別にスナップショットを使用したバックアップを取得したい場合、コピーバックアップの利用有無については考慮する必要があるかと。

SQL Server 2022 / 2025 の機能と組み合わせたバックアップ取得

SQL Server 2022 では Transact-SQL スナップショットバックアップを作成するというように、T-SQL でスナップショットバックアップを取得しやすくする機能が新たに追加されました。

従来まで、アプリケーション整合性バックアップを取得しようとした場合、次のような方法を検討する必要がありました。

VSS で SQL Server Writer と連携させる
SQL Server のサービスを停止した状態でバックアップを取得する
バックアップ取得対象の DB をオフライン / オンラインを使用してバックアップを取得する
バックアップ取得対象の DB を DBCC FREEZE_IO / DBCC THAW_IO で I/O を停止してバックアップを取得する

この DBCC は Undocument なものとなります。

T-SQL からアプリケーション整合性を担保できるバックアップを取得しようとすると少し手間がかかっていたのですが、2022 からは、「ALTER DATABASE xxxx SET SUSPEND_FOR_SNAPSHOT_BACKUP = ON;」というようなステートメントがサポートされ、ストレージのスナップショットバックアップを取得できる準備を T-SQL で実施することができるようになりました。

SQL Server で「ALTER DATABASE xxx SET SUSPEND_FOR_SNAPSHOT_BACKUP = ON;」を実行し、アプリケーション整合性バックアップが取得できる状態にする。
ストレージ側でスナップショットバックアップを取得する。

SQL Servre の I/O は停止しているため、ストレージ側ではクラッシュ整合性バックアップを取得すればよい。

「BACKUP DATABASE xxxxx TO DISK = ‘D:\Temp\xxxx.bkm’ WITH METADATA_ONLY, FORMAT;」でメタデータバックアップを取得して、スナップショットバックアップの取得準備状態を解除する。

SQL Server 2022 以降は、このような手順でアプリケーション整合性を持つスナップショットバックアップを取得できるようになりました。

VSS を使用した場合、これらの一連の動作を自動的に実施してくれますが、Linux では VSS が使用できないため実行できない、使用するストレージに応じたハードウェアプロバイダーの導入が必要というような考慮が必要となりました。

2022 以降の方法では、ストレージによって「2.」のコマンド実行方法は変わってきますが、大きな流れは変更せずに様々な実行環境で統一的な作業の流れを実施することができる可能性があります。

コマンドが分散されることで、VSS を使用する場合と比較して I/O が停止している時間が長くなる可能性がある点は注意が必要ですが。

SQL Server 2025 になると SQL Server 2025とPure Storage FlashArrayを使用したスナップショットバックアップカタログの構築 | Data Exposed で紹介されているような方法も検討ができるようになります。

2022 までは、上述の 1～3 について「2.」の対応を T-SQL 観点では実行できず、何らかのスクリプト実行の方法と組み合わせて実装を検討する必要がありました。

SQL Server 2025 では、「sp_invoke_external_rest_endpoint」により、SQL Server から REST API を呼び出すことができるようになりましたので、ストレージ側でスナップショットを取得するための API 実行が REST で提供されているのであれば、それを SQL Server から直接呼び出すことで、T-SQL のみで一連の動作を実行することができるようになります。

SE の雑記