Windows ServerのVSSシャドウコピー保存場所はどこ？保存パスの考え方とvssadmin確認手順・専用ボリューム集約まで解説

Windows Serverで「シャドウコピー（VSS）」を設定したのに、どこに保存されているのか分からず不安になることがあります。結論から言うと、シャドウコピーは“特定フォルダーにファイルが作られる”仕組みではなく、ボリューム全体のスナップショットとしてVSSが管理します。保存先は「diff area（保存領域）」としてボリューム単位で確保され、通常はエクスプローラーで辿れる“分かりやすいパス”はありません。本記事では、保存場所の考え方、確認コマンド、どうしてもパスで参照したい場合の方法、そして複数ボリュームの保存領域を専用ボリュームへ集約する設計と注意点まで、運用目線で整理します。

シャドウコピー（VSS）の「保存場所」が分かりづらい理由

Windowsのシャドウコピーは、Volume Shadow Copy Service（VSS）が作成する“ボリューム単位のスナップショット”です。一般的な「バックアップ＝どこかのフォルダーにファイルが増える」というイメージと違い、VSSはボリュームの変更点を追跡し、必要なときに“その時点の状態を再現できるようにする”仕組みです。

このとき使われるのが、diff area（差分領域／保存領域／shadow copy storage）です。ファイルが書き換わる際に、変更前のブロック（または差分情報）を退避しておき、過去の状態へ戻せるようにします。つまり「シャドウコピーそのものが1つのファイルとして保存される」わけではありません。

よくある誤解

• 誤解：シャドウコピーは C:\shadowcopy\ のような場所に作られる
• 実際：対象はボリュームで、内部的に保護領域へ差分を保持する

「VSSスナップショット」と一言で言っても2種類ある

「どこに保存されるの？」という疑問が大きくなる原因として、VSSが同じでも用途が違うスナップショットがある点が挙げられます。

種類	代表例	見え方	保存の考え方
ファイルサーバー機能としてのシャドウコピー	共有フォルダーの「以前のバージョン」	ユーザーがエクスプローラーで参照可能	diff areaを使い、世代を保持（保持期間は容量と変更率で決まる）
バックアップ用途のVSSスナップショット	Windows Server Backup、バックアップソフト	基本的にユーザーには見えない（実行後に削除されることが多い）	バックアップ処理のための一時的なスナップショットが作られる場合がある

「スナップショットが見当たらない」「以前のバージョンに出てこない」という場合、そもそもバックアップ用の一時スナップショットを探しているケースがあります。この場合、作成直後に削除されることがあるため、一覧に残らないのは正常な挙動です。

まず押さえる用語：/for と /on の違い

「作成場所・保存場所」を理解するには、VSSの用語をボリューム単位で捉えるのが近道です。

用語	意味	ポイント
対象ボリューム（/for=）	シャドウコピーを取る“元”のボリューム	例：F:（データ用）
保存領域（/on=）	差分（diff area）を置く“先”のボリューム	同一ボリュームでも別ボリュームでも可。集約も可能
最大サイズ（maxsize）	保存領域に割り当てる上限	上限に達すると古い世代から削除されやすい

多くの環境では、保存領域はOSが保護している System Volume Information 配下に保持されます。ただしここは“人が見に行くための場所”ではなく、OSが安全に管理するための領域です。アクセス権を変更して覗きに行く運用はおすすめしません（トラブル時の復旧難易度が上がります）。

確認方法：シャドウコピーの“保存先”を可視化する

「エクスプローラーでの保存パス」ではなく、どのボリュームにどれだけ確保しているかを確認するのが現実的です。ここでは、現場で使う頻度が高い順に紹介します。

保存領域（diff area）の場所と割り当てを確認する

最初に見るべきは、保存領域の設定です。管理者のコマンドプロンプトで次を実行します。

vssadmin list shadowstorage

出力の読み方は次の通りです。

• For volume: … 対象ボリューム（/for=）
• On volume: … 保存領域の置き場所（/on=）
• Used Shadow Copy Storage space: … 現在の使用量
• Allocated Shadow Copy Storage space: … 確保済み（割り当て済み）
• Maximum Shadow Copy Storage space: … 上限（maxsize）

ここで、例えば「F: のシャドウコピーの保存領域が V: に割り当てられている」と分かれば、いわゆる“保存場所”の答えは V:（の保護領域） になります。フォルダーパスではなく、ボリュームで答えるのが正解です。

シャドウコピー（スナップショット）そのものを一覧表示する

今ある世代（スナップショット）を確認したい場合は、次を使います。

vssadmin list shadows

ここでは、スナップショットIDや作成日時に加えて、参照用のデバイスパス（例：\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\）が表示されることがあります。これが後述する「どうしてもパスで参照したい」場合の入口になります。

GUIで確認したい場合（リモートデスクトップで設定する場合）

Windows ServerのGUI環境なら、次の手順でも同じ情報にたどり着けます。

• エクスプローラーで対象ドライブを右クリック →「プロパティ」
• 「シャドウコピー」タブ（または関連UI）を開く
• 対象ボリュームの有効/無効、スケジュール、設定（保存領域の配置と上限）を確認

コマンドに慣れていないチームでも運用しやすい一方で、設定変更がGUI経由で入ると差分が追いづらくなるため、手順を決めておくとトラブルが減ります。

PowerShellで確認したい場合（棚卸し・定期点検向け）

コマンドを標準化したい場合は、WMI/CIMから拾う方法も便利です。

# 保存領域（ShadowStorage）
Get-CimInstance -ClassName Win32_ShadowStorage |
  Select-Object Volume, DiffVolume, MaxSpace, AllocatedSpace, UsedSpace

# シャドウコピー一覧
Get-CimInstance -ClassName Win32_ShadowCopy |
  Select-Object ID, VolumeName, InstallDate, DeviceObject

サーバー台数が多い場合は、PowerShell Remotingで一覧取得して、台帳化すると運用が安定します。

失敗原因の切り分けで役立つVSS Writer確認

バックアップやスナップショット作成が頻繁に失敗する場合、Writerがエラー状態のままになっているケースがあります。状況確認には次が定番です。

vssadmin list writers

Writerが不安定だと、保存領域が十分でも失敗することがあります。原因がアプリ側（DBやバックアップエージェント）にある場合も多いので、保存領域の確認と併せて見るのが効率的です。

「保存パスが欲しい」場合の現実解：以前のバージョン or デバイスパス

利用シーンによって、“パス”の意味が変わります。目的別に整理すると迷いが減ります。

一般ユーザーに見せたい：共有フォルダーの「以前のバージョン」

ファイルサーバー用途なら、ユーザーはエクスプローラーの「以前のバージョン」（Previous Versions）から復元・コピーするのが最も安全です。管理者がデバイスパスを渡す運用は、誤操作のリスクが高くおすすめできません。

また、シャドウコピーはあくまで“過去に戻れるようにする仕組み”であり、サーバー障害やランサムウェアに対する本格的なバックアップの代替ではありません。復元要件が厳しい場合は、別系統のバックアップ（世代管理・オフライン保管・イミュータブル等）を必ず用意してください。

管理者が検証・調査したい：デバイスパスを一時的に参照する（上級者向け）

どうしてもファイルを“パスとして”確認したい場合、VSSが提示するデバイスパスを使います。

例：

\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\

ただし、このままだと扱いづらいので、読み取り専用のつもりで一時的にディレクトリリンクを作ることがあります。

mkdir C:\VSS_Mount
mklink /d C:\VSS_Mount \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12\

• スナップショットは運用状況により削除されるため、リンクが突然無効になることがあります。
• System Volume Information 配下を直接削除・編集する行為は、復元不能やVSS破損の原因になります。
• 監査や検証が目的なら、可能な限り「バックアップからの復元」や「検証用の複製環境」で行うのが安全です。

複数ボリュームの保存領域を1つの専用ボリュームに集約できる？

Azure VMやオンプレでも、ディスク数や管理コストの都合で「F/G/H/I の保存領域を、専用のV:にまとめたい」という要件はよくあります。結論としては、技術的には可能です。VSSの保存領域は、同一ボリュームにも別ボリュームにも配置でき、複数の対象（/for=）が同じ保存先（/on=）を共有する構成も成立します。

構成イメージ

対象ボリューム（/for=）	保存領域（/on=）	狙い
F:	V:	保存領域を専用ディスクに集約し、データボリュームの空き容量変動の影響を減らす
G:
H:
I:

設定例（vssadmin）

例として、F/G/H/I の保存領域を V: に割り当て、上限を個別に設けます。

vssadmin add shadowstorage /for=F: /on=V: /maxsize=200GB
vssadmin add shadowstorage /for=G: /on=V: /maxsize=200GB
vssadmin add shadowstorage /for=H: /on=V: /maxsize=200GB
vssadmin add shadowstorage /for=I: /on=V: /maxsize=200GB

すでに設定済みの場合は、resize を使って上限を調整します。

vssadmin resize shadowstorage /for=F: /on=V: /maxsize=300GB

ポイントは「まとめる＝自動的に賢く均等配分される」ではないことです。対象ボリュームごとに上限を設計し、V:の総容量と整合させる必要があります。

集約構成の落とし穴：性能と枯渇のリスクをどう読むか

保存領域を1つにまとめると、メリットと同じくらいデメリットも分かりやすくなります。ここは“定数解”がなく、ワークロード次第です。

なぜ性能が落ちやすいのか

VSSは変更が発生するたびに、変更前ブロックの退避などの書き込みを保存領域へ行います。複数ボリュームの変更が同じ保存先に集まると、V:へ書き込みが集中し、結果として次のような症状が出やすくなります。

• IO待ちが増え、アプリやファイルアクセスが重くなる
• スナップショット作成に時間がかかる／失敗する
• 保存領域の消費が速く、保持期間が極端に短くなる

集約して良いケース／避けたいケース

観点	集約が向く	集約を避けたい
変更率	静的なデータ（週次で少し更新）	ログ、DB、キャッシュなど高頻度更新
保存先ディスク	高速で余裕がある（IOPS/帯域が十分）	遅い／他用途と競合する
運用目的	ユーザーの“うっかり削除”対策が中心	バックアップ代替として長期保持したい

集約先ディスク選定の実務ポイント

• 性能：データ更新が集中する時間帯（業務開始直後、バッチ時間）に耐えられる性能を確保する
• 空き容量：maxsizeの合計がディスク容量を食い尽くさないようにし、OS/監視/ログ用途の余白も残す
• 用途分離：バックアップ先やログ出力先と同居させると、ピーク時間に競合しやすい
• 可用性：一時領域や“消える可能性がある領域”に置かない（環境により再起動で初期化される場合がある）

「64世代」だけで保持期間を決めてはいけない理由

シャドウコピー（以前のバージョン）の文脈では、1ボリュームあたりの世代数上限として「64」がよく引用されます。ただし、運用で効いてくるのはむしろ保存領域（maxsize）と変更率です。64に達する前に、保存領域がいっぱいになって古い世代が削除されることは珍しくありません。

スケジュールから“理論上の最大保持日数”を出す

まずは分かりやすい目安として、世代数上限だけで計算すると次のようになります。

作成間隔	1日あたり世代数	64世代での目安	注意点
4時間ごと（24時間運用）	6	約10〜11日	変更が多いともっと短くなる
4時間ごと（12時間のみ）	3	約21日	夜間に作らない分、粒度は粗くなる
1日1回	1	約64日	復元ポイントが粗いので運用要件と要相談

現実の保持期間は「1日あたりの変更量」で決まる

運用で効くのは、次のざっくり式です。

• 保持日数の目安 ≒ 保存領域のmaxsize ÷ 1日あたりの変更量（退避が必要なデータ量）

たとえば、F: の保存領域を 300GB にしていて、1日あたり 20GB 相当の変更（上書き・削除・追記）があるなら、理論上は 15日程度で保存領域が回り始めます。実際にはメタデータの更新や断片化もあるため、余裕を見て設計します。

保存領域（maxsize）の決め方：小さすぎると“消える”、大きすぎると“圧迫する”

シャドウコピーが「いつの間にか消えた」「保持できない」原因の多くは、保存領域の不足です。逆に大きく取りすぎると、保存先ボリュームの空き容量を圧迫し、別の問題を呼びます。ここでは現場で使える考え方をまとめます。

ざっくりの目安（運用設計の出発点）

データの性質	変更率のイメージ	maxsizeの考え方	コメント
静的な共有（設計書・PDF中心）	低い	データ容量の10〜20%から開始	保持期間が伸びやすい
Officeファイル中心（更新頻度あり）	中	20〜40%を検討	世代数より保存領域で決まることが多い
ログ・一時ファイル・DB	高い	シャドウコピー対象から外す/別設計	保持が難しく性能影響が大きい

運用で困りがちな“微調整”のコツ

• 保持期間が短い：maxsizeの増量、またはスナップショット頻度を下げる（要件と相談）
• 消費が急増する：大量更新（移行、バッチ、アーカイブ、ログ出力先変更）が起きていないか確認
• 保存先が逼迫する：対象ボリュームごとにmaxsizeを見直し、変更率が低いボリュームから削る

「何GBが正解」というより、変更率と目的（何日前まで戻したいか）を先に決め、必要なmaxsizeを逆算する方が失敗しません。導入初期はやや大きめに確保し、1〜2週間運用して消費スピードを見ながら調整するのが現実的です。

よくあるトラブルと切り分けポイント

シャドウコピーが突然すべて消えた

• 保存先ボリュームの空き容量が逼迫した
• maxsizeが小さく、頻繁に世代が回転している
• VSS関連のエラーでクリーンアップが走った

まずは vssadmin list shadowstorage で割り当てと上限を確認し、イベントログ（アプリケーション／システム）でVSS関連イベントが出ていないかを合わせて見ます。

スナップショットの作成が失敗する

• 保存領域の不足（最も多い）
• ファイルシステムの問題（NTFSの整合性、ディスクエラー）
• バックアップソフトのVSS Writer/Provider競合

まずは保存領域の増量（maxsizeの調整）を試し、それでも改善しない場合は、VSS Writer状態の確認や、バックアップの実行タイミングの重複がないかを疑います。検証では一時的にバックアップジョブをずらすだけで改善するケースもあります。

「以前のバージョン」に目的の世代が出てこない

• そもそも対象ボリュームで「共有フォルダーのシャドウコピー」を有効化していない
• スケジュール頻度が粗く、期待した時間帯のスナップショットが存在しない
• 保存領域不足で古い世代が削除されている
• バックアップ用の一時スナップショットを探している（作成後に削除されるため残らない）

現場で使える運用チェックリスト

• 対象ボリュームごとに、保存領域（/on=）とmaxsizeを台帳化している
• 作成スケジュール（頻度）と、戻したい期間（要件）が一致している
• 保存先ボリュームに十分な空き容量と性能がある（集約時は特に重要）
• 変更率が高い用途（ログ/DB/キャッシュ）は、シャドウコピーに頼らず別のバックアップ設計をしている
• 「シャドウコピー＝バックアップ」ではないことを関係者に周知している

まとめ：保存“パス”を探すより、保存“ボリューム”を管理する

Windows ServerのVSSシャドウコピーは、フォルダーの中にファイルとして保存される仕組みではありません。答えるべきは「どのボリュームのdiff areaとして確保しているか」であり、確認も vssadmin list shadowstorage と vssadmin list shadows が基本です。どうしてもパスで参照したい場合はデバイスパスを使えますが、誤操作リスクがあるため、目的が復元なら「以前のバージョン」やバックアップ復元を優先しましょう。

複数ボリュームの保存領域を専用ボリュームへ集約する構成も可能ですが、変更率が高いほど集約先にIOが集中しやすく、保持期間や安定性に直結します。世代数上限だけで安心せず、maxsizeと変更率から保持期間を見積もり、運用しながら調整するのが“消えないシャドウコピー”への近道です。