Windows Serverで重複除去ジョブが終わらないときは、いきなり再起動や機能の削除に進むより、まず Get-DedupJob、Get-DedupStatus、イベントログを確認するのが最短です。実際には「完全に固まっている」のではなく、スケジュールの打ち切り、メモリやCPU不足、空き容量不足、設定とワークロードの不一致で進まないケースが多く、ここを外すと何度対処しても再発しやすくなります。 (Microsoft Learn)
Data Deduplication は後処理型で動き、Optimization、Garbage Collection、Integrity Scrubbing を別ジョブとして回します。既定では Optimization は毎時、Garbage Collection は土曜 2:35、Scrubbing は土曜 3:35 に動くため、大容量ボリュームや更新頻度の高いデータでは長時間かかっても不思議ではありません。見るべきなのは経過時間そのものではなく、進捗が動いているか、直近ジョブが成功しているか、同じ条件で毎回中断していないかです。 (Microsoft Learn)
Windows Serverで重複除去ジョブが終わらないときの見方
切り分けでは、まず状態を4つに分けると判断が速くなります。進捗が少しでも動いているなら長時間処理の可能性があり、0%のままや Queued のままならリソース不足や同一ボリューム上の別ジョブを疑います。毎回同じ時間で止まるなら DurationHours や StopWhenSystemBusy、削除しても容量が戻らないなら Garbage Collection 未完了が本命です。クラスタの CSV では、手動ジョブを Owner node 以外で実行しているだけで前に進まないこともあります。 (Microsoft Learn)
最初に確認するPowerShellとイベントログ
確認は管理者権限の PowerShell で行います。Get-DedupJob は現在の実行・待機状態、Get-DedupStatus は直近ジョブの成否と時刻、Get-DedupVolume はボリューム設定、Get-DedupSchedule はスケジュールの打ち切り条件を見るのに向いています。イベントの詳細は \Applications and Services Logs\Windows\Deduplication\Operational に出ます。 (Microsoft Learn)
| 確認対象 | 実行例 | 見るポイント |
|---|---|---|
| 現在のジョブ | Get-DedupJob | Running / Queued、進捗率、同じジョブが繰り返し出ていないか |
| 直近ジョブの成否 | Get-DedupStatus | LastOptimizationResult、LastGarbageCollectionResult、LastScrubbingResult が 0 か |
| ボリューム設定 | Get-DedupVolume | UsageType、MinimumFileAgeDays、OptimizeInUseFiles、OptimizePartialFiles |
| スケジュール条件 | Get-DedupSchedule | DurationHours、StopWhenSystemBusy、優先度、開始時刻 |
| 詳細ログ | イベント ビューアー | Deduplication/Operational に失敗理由や Event ID が出ていないか |
Get-DedupStatus | fl * で Last...Result が 0 以外、または Last...Time が極端に古いのに Get-DedupJob が空なら、ジョブは正常完了していません。いま走っていないだけで、スケジュールや条件のせいで毎回途中で終わっている可能性があります。 (Microsoft Learn)
重複除去ジョブが終わらない主な原因と対処
スケジュールの窓が短く、毎回キャンセルされている
カスタムスケジュールを組んでいる環境で多いのが、ジョブの実行窓が短すぎるケースです。DurationHours は指定時間を超えるとジョブを安全にキャンセルし、0 は完了まで実行を意味します。StopWhenSystemBusy を有効にすると、システムが忙しい間は停止して後で再試行するため、日中のI/Oが強いサーバーでは「毎日少しだけ進んで終わらない」状態になりがちです。 (Microsoft Learn)
Get-DedupSchedule
Set-DedupSchedule -Name <ScheduleName> -DurationHours 0 -StopWhenSystemBusy $falseただし DurationHours 0 や StopWhenSystemBusy $false は、夜間など専用ウィンドウを確保できるときに限って使うのが安全です。日中も業務I/Oが続くサーバーでは、まず開始時刻を後ろへずらし、優先度やメモリ、I/O スロットリングを調整してから再評価した方が事故が少なくなります。 (Microsoft Learn)
CPU・メモリ・I/Oが足りない
ジョブが 0% のまま、または途中で中断するなら、CPU・メモリ・I/O の不足を疑います。Microsoft のトラブルシュートでも、メモリ不足やキャンセル、Event ID 4105 / 4106 / 4140 / 4142 / 4185 などが典型例として挙げられています。Start-DedupJob は、同じボリューム上の別ジョブ実行中やリソース不足のときにキューへ回ることがあります。 (Microsoft Learn)
切り分け目的なら、まず手動ジョブをオフピークに流してみるのが有効です。手動で開始したジョブはスケジュールジョブより優先されるため、これで動くなら「データ破損」より「スケジュールや競合」の可能性が高いと判断しやすくなります。最適化ジョブのメモリは 15〜50% が推奨範囲です。 (Microsoft Learn)
Start-DedupJob -Volume D: -Type Optimization -Memory 25 -Cores 25 -Priority Low -StopWhenSystemBusy業務影響が強く、明らかに滞留しているジョブがあるなら Stop-DedupJob -Volume D: で一度止める選択肢があります。ログと状態を採ったうえでなおジョブオブジェクトが張り付くなら、再起動は公式手順にも入っていますが、先に Get-DedupJob と Get-DedupStatus の結果を保存してからにしてください。 (Microsoft Learn)
空き容量不足とChunk Store肥大化
削除したのに空き容量が戻らない、System Volume Information 配下の Chunk Store が大きい、バックアップやコピーが失敗するという場合は、Garbage Collection が追いついていません。Microsoft は、重複除去ボリュームに少なくとも 10% の空き領域を確保し、Chunk Store の使用率が 80〜90% を超えないよう確認することを勧めています。 (Microsoft Learn)
Start-DedupJob -Volume D: -Type GarbageCollection -Full
Start-DedupJob -Volume D: -Type Scrubbing -Full定期運用では -Full なしの Garbage Collection と Scrubbing を回し、月1回程度 -Full を実行するのが公式の考え方です。ただ、トラブル時は -Full で一度きちんと回し、それでも改善しないならボリューム拡張まで含めて考える方が早いです。 (Microsoft Learn)
空き容量に余裕があるはずなのに最適化だけ失敗するなら、ボリュームルートのハードクォータも確認してください。ボリュームルートのハードクォータは重複除去と相性が悪く、実空き容量とクォータ上の空き容量がずれて最適化ジョブ失敗の原因になります。必要ならソフトクォータへ寄せた方が安全です。 (Microsoft Learn)
ワークロードと設定が合っていない
更新頻度の高い大きなファイルや、長時間開きっぱなしのファイルが多いボリュームでは、設定がワークロードに合っていないと「いつまでも最適化が追いつかない」ように見えます。Get-DedupStatus の OptimizedFilesSavingsRate や SavingsRate が下がり続ける場合、最適化ジョブがチャーンに追いついていない可能性があります。 (Microsoft Learn)
使用法の種類は Default、HyperV、Backup の3つがあり、選んだ種類に応じて低レベル設定が変わります。現在の公式ドキュメントでも、まずワークロードに最も近い種類を選び、そのうえで必要な項目だけ微調整する流れが推奨されています。汎用ファイル共有なのか、差分更新が多い仮想化系なのか、仮想バックアップ用途なのかを見直してください。 (Microsoft Learn)
Get-DedupVolume -Volume D: | Select *
Enable-DedupVolume -Volume D: -UsageType <Default|HyperV|Backup>部分的にだけ頻繁に変わる大容量ファイルなら OptimizePartialFiles が有効か確認します。公式ドキュメントでは、この設定を有効にするとファイル全体ではなくセグメントごとに MinimumFileAge を評価でき、内容の大半が変わらない大きなファイルの最適化に有効とされています。長時間オープンされたままのファイルが多いなら、OptimizeInUseFiles を含めて見直すべきです。 (Microsoft Learn)
Set-DedupVolume -Volume D: -OptimizePartialFiles更新・移行・セキュリティ製品の影響
不具合が Windows Update 後、OS アップグレード後、サーバー移行後、新しいエンドポイントセキュリティやバックアップ製品の導入後に始まったなら、その変更を最優先で疑います。公式のチェックリストでも、最近のアップグレード、移行、セキュリティ製品やバックアップ製品の導入確認が明記されています。 (Microsoft Learn)
アップグレード後に重複除去機能が不活性になっている場合は、FS-Data-Deduplication を再インストールしてボリュームを再有効化する手順が案内されています。セキュリティ製品が絡む場合は、fltmc でアクティブなフィルターを確認し、Deduplication 関連フォルダーをスキャン対象から外し、SAN 側と Windows 側の二重重複除去も避けてください。 (Microsoft Learn)
Install-WindowsFeature -Name FS-Data-Deduplication
Enable-DedupVolume -Volume D:
fltmc移行時は Robocopy を安易に使わない方が安全です。Microsoft は、Robocopy は dedup データの rehydration や Chunk Store 破損の原因になり得るとして推奨しておらず、Windows Server Backup、ディスクの直接接続、イメージベースの移行を推しています。 (Microsoft Learn)
ファイルシステム不整合とクラスタ条件
イベントログに「User data container is corrupt」や Chunk Store 参照エラーが出る、または chkdsk で異常が出る場合は、設定調整ではなく整合性の問題です。まず chkdsk <DriveLetter>: /f /scan を実行し、それでも改善しないなら Windows Server Backup で退避し、新しいボリュームへ復元して重複除去を再構成する方が早いことがあります。 (Microsoft Learn)
クラスタ環境では構成条件も重要です。手動で開始する重複除去ジョブは CSV の Owner node で実行する必要があり、すべてのノードに Data Deduplication 機能が入っていなければなりません。ReFS 上の重複除去は Windows Server 2019 以降でサポートされ、複数ストレージ階層を持つボリュームではサポートされません。設定をいくら調整しても直らないときは、まずサポート構成かどうかを確認してください。 (Microsoft Learn)
業務影響を抑える応急処置と最後の復旧策
いま一番困っているのが「サーバー負荷が高すぎて業務に影響している」ことなら、原因修正の前に火消しをします。Stop-DedupJob で現在のジョブを止められます。さらに、既存の重複除去データへの読み取りを保ったまま今後の重複除去アクティビティだけ止めたい場合は Disable-DedupVolume が使えます。 (Microsoft Learn)
Stop-DedupJob -Volume D:
Disable-DedupVolume -Volume D:完全に元へ戻す最後の手段は Unoptimization です。ただし、公式ドキュメントどおり、非重複除去データを置けるだけの空き領域がないと失敗します。しかも Disable-DedupVolume 後は、そのままではジョブ系コマンドを再実行できません。撤退は簡単ではないので、先にバックアップを取り、空き容量を確認してから判断してください。 (Microsoft Learn)
Start-DedupJob -Type Unoptimization -Volume D:やってはいけない操作
Chunk Store や System Volume Information を手で消す、Robocopy で dedup ボリュームをそのまま移す、空き容量が乏しい状態で Unoptimization を始める。この3つは、復旧を難しくしやすい典型例です。 (Microsoft Learn)
最後にやること
最初の30分でやるべきことは明確です。管理者 PowerShell で状態を採り、スケジュールの打ち切り条件、リソース不足、空き容量、UsageType とボリューム設定を順に確認します。これで収まらないときは、更新後の機能状態、セキュリティ製品、クラスタ所有ノード、ファイルシステム整合性を見ます。最後まで直らない場合は、設定をいじり続けるより、バックアップから新しいボリュームへ戻して重複除去を組み直す方が結果的に早いです。 (Microsoft Learn)
次にやることは、まず Get-DedupJob と Get-DedupStatus | fl * の結果を取り、Last...Result と DurationHours / StopWhenSystemBusy を照合することです。ここが、Windows Server で重複除去ジョブが終わらないときの最短ルートです。 (Microsoft Learn)
コメント