ボリュームシャドウコピー(VSS)の仕組みと実務 ── 使用中ファイルのバックアップがなぜ取れるのか

「他のアプリが開いているファイルをコピーしようとしたら『プロセスはファイルにアクセスできません』と怒られた」「基幹システムを止めずにデータフォルダーのバックアップを取ってほしいと言われた」「バックアップソフトはなぜ、使用中のデータベースファイルを平気でコピーできるのか」── 業務アプリの開発でも、ファイルサーバーの運用でも、遅かれ早かれぶつかる問いです。

答えの中心にいるのがボリュームシャドウコピーサービス(VSS: Volume Shadow Copy Service)です。Windowsに20年以上前から組み込まれている仕組みで、Windows Server Backupも、システムの復元も、市販のバックアップソフトのほぼすべても、この土台の上に乗っています。¹

この記事では、「使用中ファイルのコピー機能」を求められる業務アプリ開発者と、ファイルサーバー・業務PCのバックアップを運用する情シス担当者を対象に、VSSの登場人物と仕組み、vssadminでの運用実務、そして「開発者はどこまでVSSに関わるべきか」の判断を、2026年8月時点の一次情報にもとづいて整理します。「Windows I/Oの深層」連載でキャッシュマネージャーとNTFSの内部を見てきましたが、本記事はその続編として、ボリュームのすぐ上に割り込む「スナップショット」の層を扱います。

1. まず結論

• VSSは「アプリが書き込み続けているボリュームのバックアップ」を可能にするためのCOMインターフェイス群と調整サービスです。Windows XP以降に組み込まれています。²
• 登場人物は3役+調整役です。シャドウコピーを要求するリクエスター(バックアップソフト)、アプリ側でデータの整合性を保証するライター(SQL Server等)、実際にスナップショットを作るプロバイダーを、VSSサービスが仲介します。¹
• Windows標準のシステムプロバイダーはコピーオンライト方式です。ボリューム全体を複製するのではなく、スナップショット後に書き換えられるブロックだけを書き換え前に差分領域(diff area)へ退避します。差分領域はNTFSボリューム上に必要です。¹
• 静止点は「ライターのフリーズ(最大60秒)→スナップショット作成(10秒以内)→解凍」で作られます。制限時間を超えると作成は中止され、リクエスターがやり直します。¹
• ライターの協力があるかどうかで、コピーの品質が変わります。協力なしのスナップショットは「電源断の瞬間のディスク」と同等(クラッシュ整合)、協力ありはログのロールやキャッシュフラッシュを済ませ、アプリ自身が回復可能と保証する一貫状態(アプリケーション整合)です。³¹
• 運用の確認は vssadmin です。list shadows / list writers / list shadowstorage で現状を確認し、resize shadowstorage で差分領域の上限を調整します。差分領域が尽きると古いシャドウコピーから黙って削除されます。⁴⁵¹
• 自作アプリにVSSリクエスターを組み込むのは大仕事です。COMベースのネイティブAPIで、.NET向けの公式ラッパーはありません。多くの場合、再試行・共有モードの調整・短時間の停止で足り、本当にVSSが必要ならDiskShadowのスクリプト化が現実解です(Windows Server限定)。⁶⁷
• シャドウコピーはバックアップそのものではありません。コピーオンライトの差分は元ボリュームの無傷のブロックに依存するため、ディスク故障や盗難のように元ボリュームごと失う障害には無力です。ランサムウェアに対しても、シャドウコピー自体の削除(7.3)や大量書き換えによる差分領域の枯渇(7.4)で当てにできません。別媒体へのバックアップと組み合わせて初めて意味を持ちます。¹

2. 問題設定 ── 使用中ファイルはなぜ普通にコピーできないのか

出発点は、Windowsのファイル共有モードです。Windowsではファイルを開くとき(CreateFile)に、「自分が開いている間、他のプロセスに何を許すか」を共有モード(dwShareMode)として宣言します。読み取り共有を許さない開き方をしているプロセスがいる間、後から読み取りで開こうとしたプロセスは共有違反(ERROR_SHARING_VIOLATION、エラー32)で失敗します。⁸ .NETなら IOException(「別のプロセスで使用されているため、プロセスはファイルにアクセスできません」)として現れる、おなじみのエラーです。

重要なのは、これがバグではなく、データを守るための正しい仕組みだという点です。書き込み中のファイルを途中で読まれれば、読んだ側は「書きかけの中途半端な状態」を手にすることになります。排他制御の設計は「ファイル連携の排他制御の基礎知識」で詳しく扱ったとおり、アプリ間連携の土台です。

しかし、この正しい仕組みがバックアップとは根本的に衝突します。

• 共有違反の壁: データベースや業務アプリが開きっぱなしのファイルは、そもそもコピー元として開けないことがあります。
• 整合性の壁: 仮に開けても(読み取り共有が許されていても)、コピーには時間がかかります。コピー中もアプリは書き込み続けるので、ファイルの前半と後半で別の時点の内容になったり、複数ファイル(データ本体とログなど)の間で辻褄が合わなくなったりします。さらに「キャッシュマネージャー」の回で見たとおり、書き込みはまずメモリ上のキャッシュに載るため、ディスク上のファイルだけを見ても最新とは限りません。
• 運用の壁: 「ならアプリを止めてコピーすればよい」は正論ですが、24時間動く業務システムやファイルサーバーでは受け入れられません。

つまり要求は「アプリを止めずに、ある一瞬の整合した状態のコピーが欲しい」です。個々のアプリが自力で解決するには荷が重く、OSレベルの仕組みとして用意されたのがVSSです。VSSは、アプリがボリュームへ書き込み続けている最中でもボリュームのバックアップを可能にするための、COMインターフェイスによるフレームワークとして提供されています。²

3. VSSの登場人物 ── リクエスター・ライター・プロバイダー

VSSの構成は、3つの役割とそれを仲介するサービスに整理されています。¹

役割分担の妙は、お互いを知らない製品同士が協調できることにあります。バックアップソフト(リクエスター)はSQL Serverの内部構造を知りませんが、SQL Serverのライターが「バックアップすべきファイル群(コンポーネント)」をメタデータとして申告し、静止点作成の前後で自分のデータを整えるので、リクエスターはそれに従うだけで整合したバックアップを取れます。¹⁹ Windows上で動くサードパーティ製バックアップソフトのほぼすべてがVSSリクエスターです。¹

情シスの実務でこの3役を意識する場面が、トラブルシューティングです。バックアップソフトの失敗がリクエスター(ソフト側)の問題なのか、特定ライター(アプリ側)の問題なのか、プロバイダー・差分領域(基盤側)の問題なのかで、調べる場所がまったく変わります(5章・7章)。

4. スナップショットの仕組み ── コピーオンライトと「静止点」

4.1. コピーオンライト ── ボリュームを複製せずに「その瞬間」を保存する

「スナップショット」と聞くとボリューム全体の複製を想像しますが、Windows標準のシステムプロバイダーが使うのはコピーオンライト(copy-on-write)方式です。スナップショット作成の時点では、ほとんど何もコピーしません。その後、元のボリュームのブロックが書き換えられるとき、書き換えが完了する前に、書き換え前のブロックを差分領域(diff area、シャドウコピー記憶域)へ退避してから書き込みを通します。¹ 退避が必要なのは各ブロックの最初の書き換え時だけで、退避済みのブロックへの上書きでは差分領域は増えません。

「その瞬間のボリューム」を読みたいときは、変わっていないブロックは元のボリュームから、変わったブロックは差分領域から読んで合成します。変更された分しかコピーしないので作成は一瞬で、消費する容量も差分だけです。裏を返すと、書き込みが多いボリュームほど差分領域の消費が速く(7章の伏線です)、差分領域は元データと同じマシンのNTFSボリューム上に置かれます。¹ この仕組みを支えているのが、システムプロバイダーの構成ファイルである swprv.dll と、ボリュームのI/Oに割り込むドライバー volsnap.sys です。¹ I/Oスタックへの「割り込み方」に興味があれば「フィルタードライバーとミニフィルター」もどうぞ。

なお、方式には他に、ミラーを切り離す完全コピー、変更を別ボリュームへ書くリダイレクトオンライトがあり、ハードウェアプロバイダーはストレージ装置側で最適な方式を使います。¹

4.2. 静止点を作る流れ ── フリーズ60秒・作成10秒の協調

コピーオンライトが「どう保存するか」だとすれば、VSSの本領は「いつの状態を保存するか」、つまり静止点の作り方です。シャドウコピー作成は次の流れで進みます。¹

flowchart TB
    R["リクエスターが作成を要求<br/>ライターを列挙しメタデータを収集"] --> M["各ライターがバックアップ対象<br/>(コンポーネント)をXMLで申告"]
    M --> P["各ライターがデータを準備<br/>ログのロール・キャッシュのフラッシュなど<br/>回復可能な一貫状態へ整える"]
    P --> F["ライターの書き込みI/Oをフリーズ<br/>(読み取りは可能。最大60秒まで)"]
    F --> FS["VSSがファイルシステムバッファをフラッシュし<br/>ファイルシステムを凍結"]
    FS --> C["プロバイダーがシャドウコピーを作成<br/>(10秒以内。この間、書き込みI/Oは凍結)"]
    C --> T["ファイルシステム解放 → ライターを解凍(thaw)<br/>アプリは書き込みを再開"]
    T --> B["リクエスターはシャドウコピーから<br/>時間をかけてバックアップを実行"]

図1: シャドウコピー作成の流れ。止まるのは数秒〜数十秒だけで、バックアップ本体はスナップショットに対して行う

ポイントは3つあります。

1. アプリが止まるのは静止点を作る一瞬だけです。フリーズは60秒以内、プロバイダーによる作成(コミット)は10秒以内と決められており、超えると作成は中止されてリクエスターがやり直します。¹ 何時間もかかるバックアップ本体は、できあがった読み取り専用のシャドウコピーに対して、アプリを動かしたまま実行されます。
2. フリーズ中も読み取りは可能です。止まるのは書き込みI/Oだけです。¹
3. ファイルシステムも凍結されます。VSSがファイルシステムバッファをフラッシュしてから凍結するため、キャッシュに載っていた書き込みやファイルシステムのメタデータが、一貫した順序でスナップショットに反映されます。¹

4.3. クラッシュ整合とアプリケーション整合

ここで、バックアップの品質を分ける重要な区別が出てきます。

ライターの協力なしに作ったシャドウコピーは、Microsoftの用語で言うクラッシュ整合(crash consistent)状態です。公式の定義では「システムを突然シャットダウンさせる破滅的な障害の後に見つかる状態と等価なディスクの状態」であり、そこからの復元は「突然のシャットダウン後の再起動と等価」とされています。³ ファイルシステムとしては壊れていませんが、アプリから見れば「書き込み中に電源を引き抜かれた瞬間」です。トランザクションログからの回復機構を持つデータベースなら回復できることが多い一方、回復処理が前提になります。

ライターの協力ありなら、静止点の直前に各ライターがトランザクションログをロールし、キャッシュをフラッシュして、アプリ自身が「ここから正しく回復できる」と保証する一貫した状態に整えます。¹ これがアプリケーション整合で、ライターという仕組みの存在理由です。注意したいのは、ライターが保証するのは「アプリとして一貫した回復可能な状態」であって、実行中のトランザクションを勝手にコミットして完了させるわけではないことです。未コミットの作業は復元時にロールバックされます(データベースの通常の回復と同じ挙動です)。ライターはこの品質保証を、アプリを止めずに、数十秒のフリーズだけで実現します。

バックアップソフトの設定に「VSSを使用する」「アプリケーションの整合性を保証する」といった項目があるのは、この区別の現れです。ファイルサーバー上のただのファイル群ならクラッシュ整合でもほぼ問題になりませんが、データベースやメールストアを抱えるサーバーでは、対応するライターが正常であることがバックアップの品質そのものになります。

5. 運用コマンドの実務 ── vssadmin と「以前のバージョン」

情シスの実務でVSSの状態を確認する道具が vssadmin です(管理者権限のコマンドプロンプトで実行)。現行のコマンドリファレンスでは、list shadows / list writers / delete shadows / resize shadowstorage がクライアント・サーバー両方で利用できると整理されています。⁴ Windows Server系のリファレンスにはこれに加えて create shadow / list shadowstorage / list providers などが記載されています。⁵ なお、vssadminが管理できるのはシステムプロバイダーが作ったシャドウコピーだけです。¹

list writers の結果でライターがエラー状態なら、疑うべきはVSS本体ではなくそのライターを提供しているアプリ側です。担当アプリのサービス状態と、アプリケーション/システムイベントログを確認します(7章)。

resize shadowstorage の /maxsize には KB/MB/GB などの単位付きで上限を指定でき、指定しなければ無制限になります。注意すべきは、記憶域の上限変更(特に縮小)自体がシャドウコピーの消失を引き起こしうると明記されていることです。¹⁰ 世代を残したいボリュームの上限を気軽に縮めてはいけません。

5.1. 「以前のバージョン」との関係

ファイルサーバーで「共有フォルダーのシャドウコピー(Shadow Copies of Shared Folders)」を有効にすると、共有上のファイルのある時点のコピーが定期的に保持され、利用者は削除・上書きしてしまったファイルを管理者の手を借りずに「以前のバージョン」から復元できます。¹ ヘルプデスク工数を確実に減らせる、VSSの最も身近な応用です。

ただし上限があります。システムプロバイダーのシャドウコピーはボリュームあたり最大512個まで、そのうち共有フォルダーのシャドウコピー機能が既定で維持するのは64個までです(レジストリの MaxShadowCopies で変更可能)。¹ そして次章以降で述べるとおり、差分領域が不足すれば古い世代から自動削除されます。「何世代残るか」は設定した世代数ではなく、書き込み量と差分領域のサイズで決まると理解しておくのが安全です。

6. 開発者としての関わり方 ── 自作アプリにVSSは必要か

ここからは開発者の視点です。「使用中ファイルもコピーできるバックアップ機能を付けてほしい」と言われたとき、VSSとどう関わるべきでしょうか。

6.1. リクエスターを自作するのは大仕事

VSSのAPIは、リクエスター・ライターともCOMおよびC++のインターフェイスとして提供されています(リクエスターの中心は IVssBackupComponents です)。⁶ .NET向けの公式ラッパーは提供されておらず、ライターのメタデータ収集からスナップショットセットの管理、エラー時の後始末までを正しく実装する必要があるため、業務アプリの1機能として気軽に組み込めるものではありません。私たちも受託開発の見積もりでは「VSSリクエスターの自作」は独立した開発項目として扱います。

現実解は2つあります。第一に、既存のVSS対応バックアップソフトに任せること。第二に、Windows ServerであればDiskShadowをスクリプトから使うことです。DiskShadowはOS同梱のVSSリクエスターで、対話モードのほかスクリプトモード(diskshadow /s script.txt)を持ち、シャドウコピーの作成、ドライブ文字への公開(expose)、コピー処理を行うバッチの実行(exec)、後片付けまでを1本のスクリプトで記述できます。⁷¹ 「シャドウコピーを作る → そこから自作のコピー処理でファイルを吸い出す → 削除する」という流れを、COMを1行も書かずに組めます。ただしDiskShadowはWindows Server専用で、クライアントOSには含まれません。¹ クライアントPCも対象にする要件なら、この時点で既存バックアップソフトの採用に傾きます。

6.2. そもそもVSSが必要か ── 判断表

経験上、「使用中ファイルのコピー」の相談の大半は、VSSなしで解決できます。要求のレベルを見極めてから道具を選んでください。

6.3. 自作アプリはライター登録すべきか

逆方向の問い、「自作の業務アプリはVSSライターを提供すべきか」も整理しておきます。ライターを書けば、顧客がどのバックアップソフトを使っていても、自アプリのデータをアプリケーション整合で取ってもらえます。なお、通常のライターより簡易なエクスプレスライター(IVssExpressWriter)という仕組みもありますが、これは「どのファイルを対象/除外にするか」というメタデータの宣言を登録するだけのものです。⁶ フリーズ/解凍などの通知は受け取らないため、スナップショット作成に合わせてアプリの書き込みを静止させることはできません。エクスプレスライターを使ってよいのは、書き込み途中に取られても壊れない(クラッシュ整合で足りる)保存設計とセットのときだけで、静止点での協調が必要なら通常のライター実装が必要です。

とはいえ、判断の目安はシンプルです。

• データをSQL Server等のDBに置いているなら不要です。DB側のライターが整合性を保証します。¹
• 単純なファイル保存なら、まず保存処理側の設計で解決します。一時ファイルに書き切ってからリネームで置き換える原子的な保存にしておけば、クラッシュ整合のスナップショットでも「壊れた保存ファイル」は残りません。
• ライター登録を検討する価値があるのは、複数ファイルにまたがる独自データストアを持ち、静止点で相互の整合が必要なアプリに限られます。その規模のデータを自前フォーマットで抱えること自体を見直すのが先かもしれません。

7. 落とし穴 ── 運用で本当に効いてくる4つ

7.1. VSSはバックアップそのものではない

最重要の落とし穴です。システムプロバイダーのシャドウコピーは、元データと同じマシンのディスク上にある差分です。差分領域が失われれば合成できなくなるのですから、ディスク故障・マシンの盗難紛失・ボリューム全体の暗号化に対しては何の保護にもなりません。Microsoftのドキュメントも「シャドウコピーからテープ等の媒体にコピーされた内容がバックアップであり、コピー後はシャドウコピーを削除してよい」と、シャドウコピーとバックアップを明確に区別しています。¹ シャドウコピーは静止点であり、誤操作からの素早い復元手段であって、別媒体・別拠点へのバックアップの代替ではありません。

7.2. ライターのエラーはアプリ側の問題

バックアップソフトが「VSSエラー」で失敗する場合、まず vssadmin list writers でどのライターが失敗しているかを特定します。ライターの実体はアプリケーション(またはWindows構成要素)側の部品なので¹、原因調査の主戦場は担当アプリのサービス状態とイベントログです。「バックアップソフトのエラー」という見た目に引きずられてバックアップソフト側だけを調べ続けると遠回りになります。切り分けの一般的な進め方は「ソースも資料もないシステムの保守」でも扱った、「観測できる事実から容疑者を絞る」の型のとおりです。

7.3. ランサムウェアはシャドウコピーを消しに来る

防御側の注意として知っておくべき事実です。「以前のバージョン」で戻せるなら、ランサムウェアに暗号化されても戻せるのでは──と期待したくなりますが、多くのランサムウェアは暗号化の前後にシャドウコピーを削除し、この復元経路を潰しに来ることが広く知られています。シャドウコピーの削除は管理者権限があれば正規のコマンドで実行できてしまうため、侵入後の攻撃者を止める最後の砦にはなりません。したがって対策の軸は、(1)シャドウコピーを「復旧計画の一部」ではなく「あれば早い」程度に位置づけること、(2)攻撃者が到達できないオフライン・別拠点のバックアップを別途持つこと、(3)日常運用のアカウントに管理者権限を与えないことです。バックアップと暗号化・廃棄まで含めたPCライフサイクルの防御は「BitLocker実務ガイド」「PC廃棄チェックリスト」もあわせてどうぞ。

7.4. 差分領域が尽きると、古い世代から黙って消える

4章で見たとおり、コピーオンライトが差分領域を消費するのは、スナップショット取得後に各ブロックが最初に書き換えられるときです。退避済みのブロックを何度上書きしても消費は増えないので、消費量は「書き込みの回数」ではなく「保持中のスナップショット以降に書き換えられたブロックの範囲の広さ」で決まります。そして差分領域が上限に達すると、そのボリュームのシャドウコピーは古いものから順に削除されます。¹ 対話ユーザーには何も通知されないため、「先週の版に戻せるはず」が戻せなくなって初めて発覚しがちです。ただし完全に無音ではなく、Systemログにはvolsnapソースのイベントが記録されます(差分領域を確保できず削除されたときの25、拡張の失敗や上限到達で中止されたときの35/36など)。定期確認に加えて、このvolsnapイベントを監視・アラートの対象に含めておくと消失にすぐ気づけます。大量のファイル更新・一括変換・デフラグのような「ボリュームを広くなでる」処理が差分領域を一気に食い潰すのは、この「書き換えた範囲で決まる」性質のためです。保持世代が業務要件(「誤削除に気づくのは最長で何日後か」)を満たしているか、vssadmin list shadowstorage の使用量を定期的に確認し、必要なら上限を広げてください。⁵¹⁰

8. まとめ

• 使用中ファイルが普通にコピーできないのは共有違反と整合性の問題であり、それはデータを守る正しい仕組みです。「止めずに整合したコピーが欲しい」に対するOSレベルの答えがVSSです。
• VSSはリクエスター(要求)・ライター(整合性保証)・プロバイダー(作成)の3役をVSSサービスが仲介する枠組みで、互いを知らないバックアップソフトと業務アプリが協調できます。
• システムプロバイダーはコピーオンライト方式で、静止点は「ライターのフリーズ(最大60秒)→作成(10秒以内)→解凍」で作られます。ライター協力なしはクラッシュ整合、ありはアプリケーション整合です。
• 運用確認は vssadmin(list shadows / list writers / list shadowstorage)。ライターのエラーはアプリ側を疑い、差分領域の使用量は定期的に見ます。
• 開発者は、まず再試行・共有モード・停止時間・連携設計で解決できないかを判断表で確かめ、本当に必要なときだけVSSへ。自前実装よりDiskShadowスクリプト(Server限定)や既存ソフトが現実解です。
• シャドウコピーはバックアップではありません。元ボリュームの無傷のブロックに依存する差分にすぎず、ディスク故障のような元ボリュームの喪失には無力で、ランサムウェアに対してもシャドウコピーの削除や差分領域の枯渇で当てにできません。オフライン・別拠点のバックアップと組み合わせてください。

関連記事

• ファイル連携の排他制御の基礎知識 - ファイルロックと原子的 claim のベストプラクティス
• Windows I/Oの深層(第4回) ── キャッシュマネージャー:あなたのWriteFileはいつディスクに届くのか
• Windows I/Oの深層(第5回) ── NTFSの内部構造:MFTから理解するファイルシステム
• ソースコードも仕様書もないシステムを引き継いだら ── 止めずに運用・保守するための実務手順
• BitLocker実務ガイド ── 回復キーの管理から始めるドライブ暗号化
• Windows PCを廃棄する前にやっておきたいこと ── データ消去・アカウント解除・バックアップの実務チェックリスト

関連する相談領域

合同会社小村ソフトでは、「使用中ファイルのコピー・バックアップ機能」を含む業務アプリの設計・開発、ファイル連携まわりの共有違反やバックアップ失敗(VSSライターエラー)の原因調査、ファイルサーバーのバックアップ・世代管理の運用整理を扱っています。「そもそもVSSが必要な要件なのか」の切り分けからで構いません。

• Windowsアプリ開発
• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

シャドウコピーがあればバックアップは不要ですか？

不要にはなりません。Windows標準のシステムプロバイダーが作るシャドウコピーはコピーオンライト方式の差分で、「その時点の完全な複製」を別に持っているわけではなく、元ボリューム上の書き換えられていないブロックに依存しています。差分領域(diff area)を別ボリュームに置く構成にしたとしても、元ボリュームが失われれば復元できないことに変わりはなく、ディスク故障・PCの盗難紛失のように元ボリュームごと失う事態には無力です。ランサムウェアについても、暗号化の書き込み自体は書き換え前のブロックを差分領域へ退避させますが、実際の攻撃ではシャドウコピーの削除や大量書き換えによる差分領域の枯渇で失われるため、当てにできません。Microsoftのドキュメントも、シャドウコピーからテープ等の媒体へデータをコピーしたものがバックアップであり、コピー後はシャドウコピー自体を削除してよい、と両者を区別しています。シャドウコピーは「バックアップを取るための静止点」と「軽微な誤操作からの素早い復元手段」であって、別媒体・別拠点へのバックアップの代わりではありません。

自作の業務アプリで使用中ファイルをコピーしたいのですが、VSSを使うべきですか？

まず使わずに済む道を探すのが現実的です。VSSのリクエスターはCOMベースのネイティブAPI(IVssBackupComponents等)で書く必要があり、.NET向けの公式ラッパーは提供されていないため、自作アプリへの組み込みは相応の大仕事になります。要求が「他プロセスが書き込み中のファイルをいつか読めればよい」なら再試行で、「読み取り共有が許されている」なら共有モードを合わせて開くことで足ります。アプリを短時間止められるなら業務の切れ目にコピーするのが最も確実です。「止められないアプリのデータ一式を整合した状態で複製する」要求だけがVSSの出番で、その場合も自前実装よりVSS対応のバックアップソフトかDiskShadowのスクリプト化を先に検討してください。

vssadmin list writers でライターがエラー状態になっています。どうすればよいですか？

そのライターを担当するアプリケーション側の問題として調査するのが基本です。vssadmin list writers は登録されているライターの一覧を状態付きで表示するので、まずどのライターが失敗しているかを特定します。ライターはSQL ServerなどのアプリケーションやWindowsの構成要素(レジストリ等)が提供しているため、エラーの原因はVSS本体よりも担当アプリのサービス状態や、アプリケーション/システムイベントログに記録されたエラーにあることがほとんどです。該当サービスの再起動や再現条件の切り分けを行い、解消しない場合はそのアプリのサポート情報を確認します。バックアップソフトがVSSエラーで失敗する場合の一次切り分けとしても、この手順は同じです。

シャドウコピーが知らないうちに消えていました。なぜですか？

差分領域(シャドウコピー記憶域)の容量不足が代表的な原因です。コピーオンライト方式では、スナップショット取得後に各ブロックが最初に書き換えられるときに書き換え前の内容が差分領域へ退避されるため、書き換えられた範囲が広いほど差分領域を消費します。割り当てた上限に達すると、Windowsは古いシャドウコピーから順に削除して領域を確保します。対話ユーザーには通知されず黙って消えるため、「以前のバージョンで先週の版に戻せると思っていたら無かった」という形で発覚しがちです(Systemログにはvolsnapソースのイベント25などが記録されるので、監視対象にしておくと気づけます)。vssadmin list shadowstorage で使用量と上限を確認し、必要なら vssadmin resize shadowstorage で上限を広げます。ただし上限の変更(縮小)自体がシャドウコピーの消失を招くことがある点にも注意してください。

エクスプローラーの「以前のバージョン」とVSSはどういう関係ですか？

「以前のバージョン」は、VSSが作ったシャドウコピー内の過去のファイルを取り出すための入り口のひとつです。ファイルサーバーでは「共有フォルダーのシャドウコピー」(Shadow Copies of Shared Folders)を有効にすると定期的にシャドウコピーが作られ、利用者は共有フォルダー上のファイルを右クリックして以前のバージョンから自分で復元できます。管理者の手を借りずに削除・上書きミスを直せるのが利点です。ただし実体はシャドウコピーなので、保持できる世代数には上限があり、差分領域が不足すれば古い世代から消えます。「以前のバージョンがあるからバックアップは不要」とはならない点は本文で述べたとおりです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。