Windows Server BackupでVSS Writerエラーが出たら、最初にやるべきことは1つです。vssadmin list writers で どの writer が failed なのか、そもそも writer が列挙されるのか を確認し、同時刻のイベントログを突き合わせてください。VSS はバックアップ要求元、writer、provider が連携してスナップショットを作る仕組みなので、どれか1つが崩れるだけで Windows Server Backup 全体が失敗します。 (Microsoft Learn)
実際の原因は1つではありません。System Writer の権限不整合、SQL Writer などアプリ側の障害、Hyper-V の条件不足、VSS コンポーネント登録の破損、swprv や shadow storage の設定不整合など、見るべき場所がかなり変わります。この記事では、Windows Server Backup の VSS Writer エラーを 症状別に切り分ける順番 と、現場でそのまま使える判断基準を整理します。 (Microsoft Learn)
Windows Server BackupのVSS Writerエラーは、症状で当たりを付けると早い
まずは、出ている症状を次のどれに近いかで分けます。ここで外すと、関係ないサービス再起動やレジストリ変更に時間を使いがちです。
- 特定の writer が
Failed
writer 名に対応する役割やアプリを追います。VSS はスナップショット作成時に関連 writer を呼び、1つでもエラーになるとバックアップ全体が失敗し得ます。SQL 系なら SQL、IIS 系なら IIS、NTDS なら Active Directory、Hyper-V 系なら仮想化基盤側を優先して見ます。 (Microsoft Learn) System writer is not found in the backupが出る
システム状態バックアップで多いパターンです。Event 517、CAPI2 の Event 513、WinSxS 配下の権限、Cryptographic Services、VssAccessControlを先に確認します。 (Microsoft Learn)vssadmin list writersで何も出ない
VSS Event 22 / 8193、0x80042302とセットなら、Eventcls.dll の登録不整合を疑います。writer 個別障害ではなく、VSS 側の登録状態を見る場面です。 (Microsoft Learn)- 保存先側で shadow copy を作れない、
0x8004230fや VSS Event 12292 / 11 が出るswprvのServiceDll登録、provider 構成、shadow storage 側の確認が先です。 (Microsoft Learn) - Event 12289 が単発で出る
これは古い writer session state のクリーンアップで出る既知ケースがあります。単発なら過剰反応しなくてよく、繰り返すならバックアップ製品側のセッションクリーンアップ不備まで見ます。 (Microsoft Learn)
役割依存 writer は、別サーバーにあるものがこのサーバーにないからといって、すぐ異常とは限りません。IIS、FSRM、NTDS、Hyper-V などの writer は、役割やサービスが入っていて必要なときに現れます。一方、システム状態バックアップで System Writer が見えない のは要対応です。 (Microsoft Learn)
まず確認する3つのコマンド
最初の切り分けは、管理者権限のコマンドプロンプトで次の3つを見れば十分です。
vssadmin list writers
vssadmin list providers
vssadmin list shadowstoragelist writers は writer の有無と状態、list providers は登録済み provider、list shadowstorage は shadow copy storage association の確認に使います。list providers の出力には provider 名・種類・ID・バージョンが表示され、Windows 標準の provider も確認できます。 (Microsoft Learn)
ここで見るポイントは3つです。failed の writer 名、writer がゼロ件かどうか、Microsoft 標準以外の provider が入っているかです。なお、Last error: No error でも State: [9] Failed になっているケースがあるので、Last error だけで正常判定しない のが実務上かなり重要です。 (Microsoft Learn)
原因別の対処
特定の writer が Failed のとき
VSS Writer エラーで最も多いのは、このパターンです。writer 名はそのまま調査範囲のヒントになります。SQL Writer なら SQL Server、IIS Config Writer なら IIS、NTDS ならドメインコントローラー、Hyper-V Writer なら Hyper-V 側を優先します。無関係なサービスをまとめて再起動するより、writer 名に対応した役割やアプリを狙い撃ち したほうが早いです。 (Microsoft Learn)
SQL Serverが絡むとき
SQL Writer サービスは、VSS 経由で SQL Server のバックアップ整合性を支える別サービスです。VSS バックアップ時には起動している必要があり、SQL Server のデータファイルに排他ロックがある状態でも、Windows 系バックアップ製品が整合性を保ってコピーできるようにします。 (Microsoft Learn)
Windows Server Backup 側では VSS Writer エラーに見えても、実際の根因が SQL 側にあることは珍しくありません。Microsoft の KB では、最初の SQLVDI エラーから 問題の SQL インスタンス名 を拾い、同時刻の SQLWRITER イベントで 問題のデータベース名 まで追う流れが案内されています。切り分けとして、問題の SQL インスタンスだけを停止してテストバックアップし、通るかどうかを見る方法も紹介されています。 (Microsoft Learn)
更新の影響も見落とせません。SQL Writer は SQL Server エンジンとは別サービスで、SQL の新規インストールやアップグレード時に service file が置き換わることがあります。SQL の更新直後から VSS Writer エラーが出始めた なら、SQL Writer サービスの状態、バージョン、直近 CU の適用状況まで見たほうが安全です。 (Microsoft Learn)
Hyper-Vが絡むとき
Hyper-V のバックアップは VSS を使います。アプリ整合性を期待する「子 VM スナップショット」側の方式では、ゲスト OS 側で Backup (volume snapshot) integration service が実行中であること、VM が稼働中であること、ゲストの全ボリュームがベーシックディスクであること、スナップショット対応ファイルシステムを使っていることなどが条件です。条件を満たしていないと、writer の状態だけ見ても原因を誤認します。 (Microsoft Learn)
一方で例外もあります。Windows Server 2003 / 2008 系の古いゲストを Hyper-V ホスト側からバックアップする場合、ゲスト内の VSS writer が Failed と表示されても、ホスト側の Hyper-V writer が成功していれば想定内とされるケースがあります。古いゲスト OS を抱える環境では、ゲストの writer 状態だけで失敗と決めつけない ことが大切です。 (Microsoft Learn)
System writer is not found in the backup のとき
システム状態バックアップでこのエラーが出るなら、最優先は System Writer です。Microsoft の公開情報では、Windows Server Backup の Event 517 と、CAPI2 の Event 513 が同時に出て、Access is denied を伴うケースが紹介されています。原因として示されているのは、%windir%\winsxs\filemaps または %windir%\winsxs\temp\PendingRenames の権限不整合です。System Writer 自体も Cryptographic Services の一部として動作します。 (Microsoft Learn)
見るべきポイントは次の3つです。
- WinSxS 配下の ACL
filemapsとPendingRenamesの権限不整合がないかを確認します。Microsoft の KB では、SYSTEM に読み取り、TrustedInstaller にフルコントロール、Users に読み取りを付け直す方向で復旧しています。 (Microsoft Learn) - Cryptographic Services の再初期化
ACL 修正後は Cryptographic Services を再起動し、vssadmin list writersでSystem Writerが戻るかを確認します。System Writer が戻っていないまま再試行しても、Windows Server Backup 側だけでは直りません。 (Microsoft Learn) - Event 8213 と
VssAccessControl
Application ログに Event 8213 が出ている場合、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControlを確認します。Microsoft はNT AUTHORITY\NETWORK SERVICEの DWORD を1にし、必要に応じてイベントに出た他のサービス ID も確認するよう案内しています。 (Microsoft Learn)
このパターンは、Windows Server Backup の不具合というより System Writer を初期化できない OS 側の状態不整合 と見ると外しにくいです。wbadmin の再設定や再インストールより、先に System Writer を正常化してください。 (Microsoft Learn)
vssadmin list writers で何も出ないとき
vssadmin list writers が空で、Application ログに VSS Event 22 / 8193、Windows Server Backup 管理画面で 0x80042302 が出る場合は、writer 個別障害ではなく VSS コンポーネント登録の既知問題 を疑います。Microsoft の KB では、Eventcls.dll のレジストリパスが誤っていることが原因とされています。 (Microsoft Learn)
対処の要点は、EventSystem 配下の VSSEvent 用 TypeLib が %systemroot%\system32\EVENTCLS.DLL を指しているか確認し、必要なら修正したうえで COM+ Event System と Volume Shadow Copy を再起動し、vssadmin list writers を再実行することです。writer が1件も見えないときに、SQL や IIS の調査から入るのは遠回りになりやすいです。 (Microsoft Learn)
レジストリ変更を本番機で行うなら、変更前のキーをエクスポートしておくと切り戻しや監査に困りません。ここは「とりあえず再起動」で済ませず、登録値を証拠として残してから直す のが安全です。
保存先側で shadow copy が作れないとき
VSS Event 12292 / 11 や 0x8004230f が出て、保存先側の shadow copy 作成で失敗しているなら、swprv 側を先に見ます。Microsoft の KB では、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\swprv\Parameters の ServiceDll が欠落または誤りだと、この症状が起きるとされています。正しい値は %Systemroot%\System32\swprv.dll です。 (Microsoft Learn)
あわせて vssadmin list providers を確認します。VSS には software provider と hardware provider があり、Windows には copy-on-write の system provider が含まれます。list providers にベンダー製 provider が見えているなら、Windows Server Backup だけでなく、ストレージベンダーの provider、ドライバ、ファームウェア、MPIO まで調査範囲に入れるべきです。SAN 環境では、ハードウェア provider の有無が切り分けを左右します。 (Microsoft Learn)
shadow storage も見落としやすいポイントです。vssadmin list shadowstorage で関連付けを確認し、必要なら vssadmin resize shadowstorage で最大容量を変更できます。ただし Microsoft は、resize によって既存シャドウコピーが消える可能性がある と明記しています。今ある復元ポイントを残したいサーバーで、状態確認なしにサイズ変更をかけるのは危険です。 (Microsoft Learn)
なお、Windows の system provider は copy-on-write 方式で動き、shadow storage area は NTFS ボリューム上に必要です。検証用に保存先ボリュームを切り替えた後にだけ失敗し始めたなら、容量だけでなく ファイルシステムと配置 も見直してください。 (Microsoft Learn)
高負荷・タイムアウト・残骸セッションのとき
VSS は、writer 側のアプリ書き込み停止を 60 秒以内、provider の shadow copy commit を 10 秒以内 に収める前提で動きます。高 I/O、遅いストレージ、バックアップの多重実行が重なる時間帯では、この制限に引っかかって中断することがあります。毎回同じ時間帯だけ失敗するなら、設定ミスよりも負荷の偏りを疑ったほうが当たりやすいです。 (Microsoft Learn)
Event 12289 の「古い writer session state を削除した」系エラーは、残骸セッションのガベージコレクションで出る既知ケースです。Microsoft は、単発の発生は無視してよい とし、再現性が高い場合はバックアップ アプリが VSS セッションのクリーンアップガイドラインを守れているか確認するよう案内しています。Windows Server Backup 以外のエージェントを同居させているなら、その製品も疑ってください。 (Microsoft Learn)
実務で見落としやすいポイント
Last error: No errorでも安心しないStateがFailedなら要調査です。Hyper-V 関連の公式例でも、この組み合わせは実際に出ています。 (Microsoft Learn)- 別サーバーの writer 一覧を正常値にしない
writer は役割依存です。IIS や NTDS がないサーバーで、それらの writer が見えなくても異常とは限りません。 (Microsoft Learn) - System Writer の不在は軽く見ない
システム状態バックアップでは、System Writer の不在はそのまま失敗要因です。Windows Server Backup の再設定より先に、System Writer の初期化条件を直すべきです。 (Microsoft Learn) - Hyper-V の古いゲストは例外がある
ゲスト writer が failed 表示でも、ホスト側の Hyper-V writer 成功が正とされることがあります。 (Microsoft Learn) - shadowstorage の変更は“最後の手”
resize shadowstorageは便利ですが、副作用として既存 shadow copy を失う可能性があります。まず現状を記録してから実施してください。 (Microsoft Learn)
復旧後に必ずやる検証
VSS Writer エラーは、「その場で1回通った」だけでは不十分です。修正後は 手動バックアップで再現しないこと と、バックアップが実際に認識・復旧できること まで確認して初めて完了です。wbadmin は Backup Operators または Administrators 権限と、管理者特権のコマンドプロンプトが前提です。 (Microsoft Learn)
まずは次の流れで確認します。
wbadmin start systemstatebackup -backupTarget:F:
wbadmin get versionsシステム状態を検証したいなら wbadmin start systemstatebackup -backupTarget:F:、取得結果の確認は wbadmin get versions が基本です。get versions では、バックアップ時刻、保存先、version identifier、実行できる回復種類を確認できます。少なくとも 最新バックアップが一覧に見えること までは確認しておきたいところです。 (Microsoft Learn)
本番の差分運用に影響させたくない検証なら、wbadmin start backup の -vsscopy を使った 1 回限りバックアップも選択肢です。Microsoft のコマンド解説でも、-vsscopy を使った例が示されています。 (Microsoft Learn)
復元テストまでやるなら、ファイル・フォルダー・ボリュームは wbadmin start recovery、システム状態は wbadmin start systemstaterecovery を使います。バックアップデータがあるのに一覧に出ない、または catalog 側が壊れている疑いがあるなら、wbadmin restore catalog の出番です。障害時に慌てないためにも、「取れる」だけでなく「戻せる」まで確認 してください。 (Microsoft Learn)
まとめ
Windows Server Backup の VSS Writer エラーは、「VSS が壊れた」と大きく見るより、どの writer / provider / 権限が失敗したか に分解すると早く直せます。最初の一手は vssadmin list writers、次にイベントログ、その後に list providers と list shadowstorage です。 (Microsoft Learn)
System Writer なら WinSxS 配下の権限と VssAccessControl、SQL なら SQLVDI / SQLWRITER、writer がゼロなら Eventcls.dll、保存先側なら swprv と provider を優先確認してください。原因に合った場所から見るだけで、Windows Server Backup の VSS Writer エラーはかなり短時間で切り分けられます。 (Microsoft Learn)
最後は、修正したこと自体より、手動バックアップが通ること、wbadmin get versions に見えること、必要な復元手順が踏めること を確認して締めてください。そこまでやって初めて、次回の障害対応が楽になります。 (Microsoft Learn)
コメント