Windows Server 2016 のファイル共有フェールオーバークラスターで「以前のバージョン（VSS）」を使うと、データ本体とは別ボリュームに保存先を分けたくなることがあります。しかし Failover Cluster Manager からは保存先が選べず、設定手順で迷いがちです。
起きていること：クラスター管理画面だと「ON/OFF」しかできない
フェールオーバー クラスター上のファイル共有で「以前のバージョン（Shadow Copies of Shared Folders）」を有効化すると、ユーザーはエクスプローラーの［以前のバージョン］から、誤って上書きしたファイルや消してしまったファイルを自己復旧できるようになります。運用コストを下げられる一方で、スナップショットの差分データを置くシャドウ ストレージ（diff area）がどこに確保されるかは、容量・性能・可用性に直結します。
ところが、Windows Server 2016 のファイルサーバー クラスターでは、同じボリュームでも操作する入口によって見える設定項目が変わります。
| 操作する場所 | できること（代表例） | 「保存先ボリューム」指定 |
|---|---|---|
| エクスプローラー / ディスクのプロパティ（シャドウ コピー） | 有効化、スケジュール、最大サイズ、保存先（Located on this volume） | 選べる（環境によって選択肢が出ない場合あり） |
| Failover Cluster Manager | クラスターディスクに対するシャドウ コピーの有効/無効（と、関連リソースの管理） | 基本的に選べない |
Microsoft Q&A でも同様の質問が挙がっており、「Failover Cluster Manager では VSS の保存先（シャドウ ストレージの場所）を管理できない。別ディスクに置く設定は vssadmin で個別に行う」という整理になっています。
まず押さえる：用語と仕組み（VSS / 以前のバージョン / diff area）
設定作業に入る前に、何がどこに保存されるのかを整理すると、判断とトラブルシュートが一気に楽になります。
| 用語 | 意味 | 実務でのポイント |
|---|---|---|
| VSS（Volume Shadow Copy Service） | ボリューム単位のスナップショットを作る仕組み | 「以前のバージョン」だけでなくバックアップ製品も利用することがあるため、無闇に無効化しない |
| Shadow Copies of Shared Folders（以前のバージョン） | 共有フォルダー上のファイルを、ユーザーが過去版として参照・復元できる機能 | “簡易復元”には強いが、バックアップの代替ではない（後述） |
| diff area（シャドウ ストレージ） | スナップショット維持のための差分データの置き場 | 場所と上限を誤ると、データ領域や他ワークロードに影響が出る |
| シャドウ ストレージの関連付け | 「どのボリューム（/for）の差分を、どのボリューム（/on）に置くか」というペア | 明示しないと、VSS が空き容量の大きいボリュームを選んでしまうことがある |
Microsoft Learn の VSS 解説でも、diff area は任意のローカル ボリュームに置けるが、NTFS で十分な空き容量が必要で、手動の関連付けがある場合はそれが優先される、と説明されています。
なぜ Failover Cluster Manager では保存先を選べないのか
結論から言うと、Failover Cluster Manager が担当しているのは「クラスターとしてのリソース管理」で、VSS の diff area という“OS のボリューム機能の詳細設定”までは面倒を見ないためです。Microsoft Q&A の回答でも、両者は別機能なので保存先を管理できない、と明言されています。
クラスター環境では、ディスクがどのノードでオンラインか（所有者）によって見えるドライブが変わります。管理者としては「クラスターの画面で全部完結してほしい」と思いがちですが、VSS の保存先指定はボリュームに対する設定であり、結果として FCM 側は「有効/無効」レベルの入口に留まる、というのが現実です。
解決策：保存先の指定は vssadmin で設定する
保存先を別ボリュームにしたい場合は、管理者権限のコマンドプロンプト（または PowerShell）で vssadmin を使い、シャドウ ストレージの関連付けを明示します。vssadmin は Windows Server 2016 を含むサーバー OS で利用できるコマンドとして提供されています。
基本構文（add shadowstorage）
Microsoft Learn のコマンド仕様は次の通りです。
vssadmin add shadowstorage /for=<対象ボリューム> /on=<保存先ボリューム> /maxsize=<上限>| パラメーター | 意味 | 実務メモ |
|---|---|---|
| /for | シャドウ コピーの対象（データ本体のボリューム） | 例：共有データがある F: など |
| /on | 差分（シャドウ ストレージ）を置くボリューム | 例：G: を専用にする |
| /maxsize | 使用上限 | 無指定だと上限なし。事故防止のため上限設定を強く推奨 |
/maxsize を指定する場合、サイズ表記には単位が必要で、また一定以上のサイズが求められます（例：300MB 以上など）。この “下限” は環境やコマンドによって表記が異なることがあるため、実行時のエラー メッセージも併せて確認してください。
例：データ F: のスナップショットを G: に置き、上限 200GB にする
vssadmin add shadowstorage /for=F: /on=G: /maxsize=200GB確認：現在の関連付け（list shadowstorage）
設定後は、関連付けが意図通りになっているかを必ず確認します。
vssadmin list shadowstorage変更：上限だけ調整したい（resize shadowstorage）
運用してみると「上限が小さすぎて過去版がすぐ消える」「逆に大きすぎて別用途の容量を圧迫する」が起きがちです。上限変更は resize を使うと安全です。
vssadmin resize shadowstorage /for=F: /on=G: /maxsize=300GBなお resize は % 指定や UNBOUNDED（無制限）にも対応しますが、クラスター運用では無制限は避け、監視可能な上限を置くほうが再現性があります。
削除：関連付けを作り直す（delete shadowstorage）
構成を整理し直したい場合は、関連付けを削除して作り直す方法もあります。/on を省略すると対象ボリュームに紐づく関連付けをまとめて削除する挙動になるため、実行前に影響範囲を確認してください。
vssadmin delete shadowstorage /for=F: /on=G:クラスターで「別ボリュームに置く」場合の設計ポイント
コマンド自体はシンプルですが、クラスターならではの落とし穴があります。ここを押さえないと「設定したはずなのに、フェールオーバー後に動かない」「勝手に別の場所へ逃げた」「作成に失敗してイベントだけ残る」が起きます。
大原則：/for と /on のボリュームは“同時にオンライン”であること
VSS の diff area は「ローカル ボリューム上に置ける」一方で、当然ながら保存先ボリュームが見えていない状態では作成できません。
フェールオーバー クラスターの場合、ディスクは同時に複数ノードから見えるわけではなく、役割を持つノードでオンラインになります。そのため、次のように設計しておくのが安全です。
- データ ボリューム（/for）と、シャドウ ストレージ用ボリューム（/on）を同じクラスター ロール（同じリソース グループ）に所属させる
- フェールオーバー時に両方が同じノードでオンラインになるようにする
- ボリュームは NTFS で作成し、ドライブレターも分かりやすく固定する（運用手順が単純になる）
古い資料にはなりますが、Microsoft のトラブルシュート記事（KB 838421）でも「ファイル share リソースと同じグループに別ディスクを追加して、そこをシャドウ コピーの保存先にする」ことが推奨され、設定時にはホスト ドライブと保存先ドライブに依存関係が構成される、と説明されています。考え方としては現在のクラスター運用でも参考になります。
ボリューム構成の例
| 用途 | ドライブ | クラスター上の扱い | おすすめ設定 |
|---|---|---|---|
| 共有データ本体 | F: | File Server ロール配下のクラスター ディスク | Shadow Copies 有効、/for=F: |
| シャドウ ストレージ専用 | G: | 同じロール配下のクラスター ディスク（F: と同じ所有者で動く） | /on=G:、十分な空き容量、監視対象 |
| システム領域 | C: | 各ノードのローカル | 基本的に対象外（クラスターデータは置かない） |
マウント ポイント運用は慎重に
ドライブレターが足りない場合、マウント ポイント（例：C:\\ClusterMount\\Data）で運用したくなることがあります。ただし、クラスターでのシャドウ コピー設定では、マウント ポイントは避けるべきという注意や、ドライブレター割り当ての推奨が示されています。運用の単純さ・切り分けの容易さを優先し、可能ならドライブレターで揃えるのが無難です。
設定手順：データとシャドウ ストレージを分離する（実務向け）
ここからは「失敗しにくい順番」に寄せた手順です。すべて管理者権限で実施してください。
- ディスクを用意して NTFS でフォーマット
データ用（例：F:）と、シャドウ ストレージ用（例：G:）を別ボリュームで用意します。G: は“差分置き場専用”にしたほうが監視と容量管理が簡単です。 - 両ボリュームを同じクラスター ロールに入れる
Failover Cluster Manager 上で、F: と G: が同じ役割で同時にフェールオーバーすることを確認します。 - （推奨）フェールオーバー先でも同じドライブレターに見えることを確認
ノード A で F: / G: がオンラインの状態を作り、ノード B に移動しても同じレターで見えることを確認します。ここが揺れると /for や /on の指定ミスが起きます。 - vssadmin で関連付けを作成
例：F: の diff area を G: に割り当て、上限を 200GB にします。vssadmin add shadowstorage /for=F: /on=G: /maxsize=200GB - 設定を確認（list shadowstorage）
vssadmin list shadowstorage - シャドウ コピーを有効化し、スケジュールを設定
GUI でスケジュールを管理したい場合は、対象ボリュームの「シャドウ コピー」設定から有効化し、必要に応じて頻度を調整します。クラスター経由で ON にする場合は、保存先指定ができない点を理解したうえで、関連付け（/for と /on）を vssadmin で固定しておくのがポイントです。 - （任意）初回スナップショットを作成してクライアント表示を確認
最初のスナップショット作成後、共有にアクセスするクライアントから「以前のバージョン」が見えるか確認します。
フェールオーバー後に必ずテストするチェックリスト
「設定できた」よりも大事なのが「フェールオーバー後も同じ動きをする」です。次の観点で必ずテストしてください。
| 観点 | チェック内容 | 確認コマンド/方法 |
|---|---|---|
| 保存先ボリュームの可用性 | フェールオーバー後も /on の G: がオンラインで見える | ディスク管理、FCM、エクスプローラー |
| 関連付けの維持 | 別ノードでも F:→G: の関連付けが残っている | vssadmin list shadowstorage |
| スナップショット作成 | スケジュール/手動作成が失敗しない | GUI で作成、イベントログ（VSS / VolSnap） |
| クライアントの見え方 | 「以前のバージョン」に最新分が出る | クライアントのプロパティ画面 |
| 容量逼迫時の挙動 | 上限到達時に古いものから削除される想定になっている | 空き容量監視、世代数の変化 |
VSS は、空き容量が不足すると古いシャドウ コピーから削除する動きになります。つまり、上限（/maxsize）と監視がそのまま “保持期間” を決めます。
運用の落としどころ：同一ボリュームに置いて /maxsize だけ絞る
「別ボリュームに置くのが理想」と分かっていても、現場では次のような理由で同一ボリューム運用に落ち着くことがあります。
- 保存先用ディスクを増やすと、クラスターの構成・監視対象・障害パターンが増える
- フェールオーバー時の依存関係や同時オンラインの設計が面倒
- “保存先を確実に尊重しているか” の不安が残る
実際に Microsoft Q&A のスレッドでも、最終的に「同一ボリュームに置いてサイズ上限だけ絞った」という落としどころが共有されています。
この方式のポイントはシンプルです。
- シャドウ ストレージを同一ボリュームにする（例：/for=F: /on=F:）
- /maxsize を適切に設定し、監視で維持する
vssadmin add shadowstorage /for=F: /on=F: /maxsize=10%“保存先分離”ほどの分離効果はありませんが、設定が壊れにくく、フェールオーバー後の再現性も高いため、まず安定稼働を優先するなら有力な選択肢です。
容量設計：/maxsize を「なんとなく」で決めない
シャドウ コピーの容量は、データ容量よりも変更率に引っ張られます。たとえば “毎日大量に上書きされる設計図フォルダー” と “ほぼ不変なアーカイブ” では、同じ 1TB でも必要なシャドウ ストレージが変わります。
実務では次のように考えると決めやすいです。
| 項目 | 考え方 | 例 |
|---|---|---|
| 保持したい日数 | 「ユーザーが困る期間」を先に決める | 14日分 |
| 1日あたりの変更率 | 更新頻度が高い共有で測る（ログや運用実感でも可） | 2%/日 |
| 概算必要量 | データ容量 × 変更率 × 保持日数（ざっくり） | 2TB × 0.02 × 14 ≒ 560GB |
| 安全係数 | 繁忙期や一括更新に備えて余裕を持たせる | ×1.2〜1.5 |
上の例なら 560GB に余裕を見て 700〜800GB 程度を上限にする、という決め方ができます。実際の差分はファイル種別（Office / PST / DB / VHDX など）で変動するため、最初は保守的に設定し、vssadmin list shadowstorage の「Used」推移を見て resize で調整するのが現実的です。
よくあるハマりどころとトラブルシュート
クラスター × 以前のバージョンで詰まりやすいポイントを、症状ベースでまとめます。
| 症状 | 原因の候補 | 対処の方向性 |
|---|---|---|
| 保存先ボリュームが選べない（FCM では ON/OFF だけ） | FCM は保存先を管理できない仕様 | vssadmin で /for と /on を明示する |
| 別ボリュームにしたはずなのに、違う場所に diff area が作られる | 関連付けがない、または他の条件で VSS が空き容量の大きいボリュームを選択 | vssadmin で関連付けを作り直し、意図した /on を固定する |
| フェールオーバー後だけ「以前のバージョン」が更新されない | /on のボリュームが同時オンラインになっていない、スケジュールが動いていない | 両ディスクを同一ロールに入れ、イベントログと list shadowstorage を確認 |
| スナップショットがすぐ消える | /maxsize が小さい、変更率が高い | 上限を増やす（resize）、または頻度/保持設計を見直す |
| 過去版を大量に残したのに、クライアントで最新が見えない | VSS の世代数と SMB 側の表示上限が一致していない | MaxShadowCopies を上げすぎない（Windows Server 2012 以降は SMB 側に 500 の上限がある） |
「シャドウ コピーはバックアップの代替ではない」を実務に落とす
VSS 自体はバックアップでも利用されますが、「以前のバージョン」はあくまで共有フォルダーのセルフサービス復元のための仕組みです。Microsoft Learn の VSS 解説でも、シャドウ コピーとバックアップの関係や用途が整理されており、シャドウ コピーは“データを抽出して復元できる材料”にはなる一方、テープや別媒体にコピーしたものがバックアップになる、と説明されています。
クラスター環境でよくある誤解は次の2つです。
- 誤解：「以前のバージョンがあるからバックアップ不要」
現実：災害・ランサムウェア・ストレージ障害・誤操作（大量削除）では同時に影響を受ける可能性があるため、別系統のバックアップが必要 - 誤解：「保持期間はスケジュールで決まる」
現実：保持は容量（/maxsize）で決まり、満杯なら古いものから削除される
まとめ：クラスターの入口と VSS の入口を分けて考える
Windows Server 2016 のフェールオーバー クラスターで「以前のバージョン」を使うとき、Failover Cluster Manager だけで設定を完結させようとすると、保存先ボリューム指定で必ず壁に当たります。これは仕様上の役割分担であり、保存先は vssadmin で明示するのが再現性の高い解決策です。
別ボリューム運用は効果が大きい反面、クラスターでは「両ボリュームが同時にオンライン」「フェールオーバー後も関連付けが維持される」ことを必ずテストしてください。もし運用負荷が重い場合は、同一ボリュームに置いて /maxsize を適切に縛るだけでも、事故は大幅に減らせます。目的（ユーザーの自己復元をどこまで支えるか）と運用体制に合わせて、無理のない設計に落とし込んでいきましょう。
コメント