Windows Serverで不定期に発生していたvolsnap 25エラーがなおった！

今回は、Windows Serverで不定期に発生していたvolsnap 25エラーが、とある設定変更により発生しなくなったので、その設定方法をご紹介します！

volsnap 25イベント(エラー)に困っていました！

Windows Serverを運用している方であれば、以下のエラーを見たことがある、という方もいらっしゃるのではないかと。

ログの名前：システム
ソース：volsnap
イベント ID：25
レベル：エラー
タスクの カテゴリ：なし
内容：
シャドウ コピーの記憶域を時間内に拡張できなかったためにボリューム (GUID) のシャドウ コピーは削除されました。
システムの IO 負荷を減らすか、またはシャドウ コピーされていないシャドウ コピーの記憶域ボリュームを選んでください。

(Windows Server 2012 R2 イベントビューアのログより引用)

ご紹介したエラーの内容は、Windows Server 2012 R2でのもの。
そのためServer OSのバージョンによって異なります。
ただエラー内容の大筋は、同じようなことを言っています。

そしてこのエラー、はるるはWindows Server 2003 R2のころからの付き合いでして。
しかもWindows Server 2008 R2(x64)、Windows Server 2012 R2(x64)でも発生を確認しており、かなり長い付き合いなんです。

ただこれはイベントログに記録されるだけで、エラーが発生した際に、エラーメッセージが画面上に表示されるわけではありません。
また後述するVSSの技術を使用するWindows Serverの機能を利用していなければ、発生しないエラーらしく。

そのためまったく見たことがないエラーだ！
という方も多いかもしれません。

ですがこの問題、一度起こると影響がかなり大きいので、困っていたんです。

その影響とは…。

過去のバックアップ履歴がすべて削除される！

実際にサーバーを運用されている方であれば、この『過去のバックアップ履歴がすべて削除される』という現象が、どれほど恐ろしいものなのか、容易に想像できるのではないかと。

この消えるバックアップにはたとえば、Windows Server 2003 R2であれば、以前のバージョンの復元に使用するシャドウコピーのバックアップ。
Windows Server 2008 R2やWindows Server 2012 R2であれば、それに加えてWindows Server バックアップで取得したすべてのバックアップなどが挙げられます。(シャドウコピーは簡易的なバックアップのように振る舞いますが、厳密にはバックアップとは異なります。ですが本エントリーでは、便宜上両者をひとくくりにしてバックアップと表現します。)

これらはいずれもボリュームシャドーコピーサービス(Volume Shadow Copy Service)、いわゆるVSSの技術を使用して取得されるバックアップ。

そしてこのVSSの機能を利用したバックアップを取得した際に技術的な問題が発生し、それまでに取得していたすべてのバックアップ履歴が削除される、というのがこのvolsnap 25エラーの概要です。

そのためVSSが提供する機能を利用したバックアップを取得設定していない場合は、このエラーが起こることはおそらくはないはず。

ちなみにこのエラー、ネットで検索してみると、同様の事例で悩んでいる方が結構多いことがうかがえます。

そしてそのバックアップを削除する凶悪さと、イベントログに記録されるソースとIDから、volsnap(ボルスナップ) 25エラーと呼ばれています。

尚、環境によっては全部ではなく、一部のバックアップ履歴が削除されるだけで済むこともあるそう。
ですがはるるがこれまでに遭遇したvolsnap 25エラーでは、毎回すべてのバックアップが削除されていました。

volsnap 25エラーが起こるメカニズム

これを詳細に理解、説明しようとすると、非常に長い話になってしまうようなので、概要だけ。

VSSの機能を利用したバックアップでは、バックアップの履歴を管理するために、Diff Areaという特殊な領域にデータを書き込んでいます。
そしてこのDiff Areaに格納されたデータにより、VSSの技術を利用したバックアップで、任意の時点のバックアップの復元を実現しています。

だからDiff Areaに格納されたデータは、バックアップの履歴を管理する上でとても大切、というわけ。

Diff Areaは拡張される！

VSSの技術を利用したバックアップを実行時、データの変更点が多い場合は、Diff Areaが初期サイズでは足りなくなることがあります。
この時Windows Serverは、自動でDiff Areaを拡張(領域の拡大)しようと試みます。

ところがDiff Areaの拡張が何らかの理由で失敗した場合、変更点を格納しきれず、バックアップが失敗します。
この状況下では、Diff Area内のデータは不正な状況となっており、破損しています。
つまり正常にバックアップが取得できておらず、このバックアップを復元することもできない、ということです。

そしてその世代(直近)のバックアップが復元できないだけならば、被害が限定的なのでまだ良いのですが…。
この破損時には、それ以前の世代のバックアップに関する情報も破損するため、すべてのバックアップ履歴が削除される、というわけ。

これらを簡潔に説明しているのが、冒頭にご紹介したvolsnap 25エラーのイベントログの内容中、『シャドウ コピーの記憶域を時間内に拡張できなかったためにボリューム (GUID) のシャドウ コピーは削除されました。』という部分。

Server OSのメジャーアップデートで頻度は減るも、ゼロにはならず

volsnap 25エラーは先に書いたとおり、古くはWindows Server 2003 R2のころからの付き合い。
そしてWindows Server 2008 R2(x64)、Windows Server 2012 R2(x64)と、メジャーバージョンアップされたサーバーOSを使う度に、その発生頻度は減っている、というのがはるるの印象。

ですが2015年11月現在の最新のサーバーOSである、Windows Server 2012 R2(x64)においても、volsnap 25エラーは発生しており、完全に解決しているわけではない様子。

volsnap 25エラーの解決方法

volsnap 25エラーの解決方法として、Microsoftさんが推奨している対策はいくつかあります。
その中でもネット上で特によく見かけるのが、以下の2つの対策。

I/O負荷を減らす！

VSSによるバックアップ処理を実行中に、当該ボリュームのディスクI/O負荷が高いと、Diff Areaへの書き込みに対して、Diff Areaの拡張が間に合わず、拡張が失敗してしまうことがあるそう。
そのため当該ボリュームのディスクI/O負荷を下げれば、それが間に合うようになり拡張が成功する、という対策ですね。

ただアクセス頻度の高いファイルサーバーでは、このI/O負荷を減らすのは、なかなか難しいかもしれません。

そこでMicrosoftさんが提示している解決策が、イベントログのメッセージの後半の『システムの IO 負荷を減らすか、またはシャドウ コピーされていないシャドウ コピーの記憶域ボリュームを選んでください。』という部分。

初期設定では、シャドーコピーの記憶域はシャドーコピーの対象ボリューム上に作成するようになっています。
これをシャドーコピーの設定画面で変更し、シャドーコピーの対象になっていない、別のディスク上のボリュームを選択することで、シャドーコピーの対象ボリュームのI/O負荷が下がる。
その結果、volsnap 25エラーが起こりにくくなる、ということみたい。

これについてはMicrosoftさんが、共有フォルダーのシャドウ コピーに関する作業の際のベスト プラクティスとして紹介しています。

ディスク上の記憶域のうちシャドウ コピーされていない領域を選択します。
別のディスク上にある個別のボリュームを使用することで、I/O 負荷の上昇が原因でシャドウ コピーが削除される可能性がなくなり、パフォーマンスが向上します。
使用頻度の激しいファイル サーバーではこの構成をお勧めします。

(Microsoft – TechNetより引用)

この解決策はかなり有効らしく、volsnap 25エラーの多くのケースでは、この対策を実行することで改善されるとか。

ただ内蔵しているディスクや外部ストレージのディスクを簡単に増やせない場合、この対策は利用できないことも。

ちなみにはるるの場合、Windows Server 2003 R2とWindows Server 2008 R2(x64)では、ディスクを用意できず、この対策を試せていません。
ですがWindows Server 2012 R2(x64)では、この対策を実行していたにも関わらず、volsnap 25エラーが発生しました。

そのため絶対に改善する対策というわけではないのです。

Diff Areaの初期サイズを大きくする

volsnap 25エラーは高いI/O負荷により、Diff Areaの拡張に失敗する現象。

だから処理の途中で拡張しなくて済むように、最初から大きくしておけば良いよね！
というのが、もう一つの対策。

具体的にはレジストリエディターを起動し、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VolSnapに、MinDiffAreaFileSizeというDWORD(32ビット)値を追加。
そして値のデータに3000(0xbb8)と設定します。

この設定を行うことで、Diff Areaの初期サイズを最初から最大の3GBで作成するようになり、処理途中でのDiff Areaの拡張が起こらなくなるとのこと。

ちなみにこれはWindows Server 2003 R2時代から存在する設定で、2008 R2、2012 R2でも有効なキーのようなので、はるるももちろんそれぞれに設定していました。
ですがこれで改善した試しはなく…。

ところが少し前に行ったとある設定変更を境に、これまでさんざん困っていたvolsnap 25エラーが、まったく発生しなくなったんです！

重複除去のフルGCを停止したら、volsnap 25エラーが発生しなくなった！

Windows Server 2012 R2では、記憶域の容量を削減するための機能として、データ重複除去という機能が利用可能です。
これはデータを細分化し、重複しているデータはオリジナルのみを保存(重複を除去)することにより、ファイルサーバーの記憶域のリソースを節約するスゴイ機能。

これはとても素晴らしい機能なので、当然はるるも利用しておりました。

そしてこの機能を有効化すると、定期的にフルGC(Full GarbageCollection = フルガベージコレクション)と呼ばれるメンテナンス作業が実行されるようになります。
これがどうやら激重な作業らしく。

フルGC実行時には、対象としているディスクに対して、かなりのディスクI/O負荷が発生するそう。
そのため、これとVSSを利用したバックアップが同時に稼働すると、過大なI/O負荷により、volsnap 25エラーが発生することがある、ということを知りました。

その情報源がこちら、MicrosoftさんのKB3066175。
一応機械翻訳版の日本語バージョンも公開されていますが、ところどころおかしなところがあるので、今回は英語版のKBでご紹介します。

そしてこれによると、フルGCの実行に際し、以下の問題点と副作用があるとのこと。

Deletion of Volume Shadow Copy Service (VSS) shadow copies

(Microsoft – KB3066175より引用)

ふむふむ、なるほど。

ボリューム シャドウ コピー サービス (VSS) のシャドウ コピーの削除

ですって。

…はっきり書いてありますね。

そして回避策も明言されています。

Configure deduplication not to run Full GC but to run garbage collection only in regular mode.

中略

To prevent Full GC, configure the following registry key:

HKLM\System\CurrentControlSet\Services\ddpsvc\Settings /v DeepGCInterval /t REG_DWORD /d 0xffffffff

(Microsoft – KB3066175より引用)

フルGCを実行せず、通常モードでのみ動作するように重複除去を構成する

中略

フルGCの実行が行われないように構成するには、以下のようにレジストリキーを構成する

HKLM\System\CurrentControlSet\Services\ddpsvc\Settings /v DeepGCInterval /t REG_DWORD /d 0xffffffff

というわけで、レジストリキーを追加することで、重複除去をフルGCではなく、通常モードでしか動作しないように構成することにより、現象が回避されるそうです。

そしてこの設定を行ってからというもの、一度もWindows Server 2012 R2でvolsnap 25エラーが発生していません。

そのためはるるが運用しているWindows Server 2012 R2においては、どうもこの重複除去のフルGCによるI/O負荷が原因だったようです。

ただWindows Server 2003 R2とWindows Server 2008 R2(x64)では、重複除去を使用できないので、これが原因ではありません。

そしておそらくは、多くの報告があったシャドーコピーの記憶域をシャドーコピーの対象ボリューム上に作成していたことによる、I/O負荷が原因だったんじゃないかと。
といっても現在は、その環境が手元にないため、確認はできず。
そのため推測に過ぎませんが…。

ちなみに先のレジストリへの設定は、手動で行うと間違えてしまう可能性があるので、コマンド・プロンプトで、以下のコマンドを実行すると良いでしょう。

ですがこの設定を行うにあたって、事前にはるるが気になったのがこちらの点。

重複除去のフルGCは、停止しても問題ないの？

重複除去のGCは、不要になったデータ領域をクリーンアップし、再使用できるようにするための機能です。
そして通常のGCがある閾値を超えた領域のみを対象にするのに対し、フルGCでは可能なかぎりすべての領域をクリーンアップしようとします。

これがI/O負荷の原因なわけですが、なんと通常のGCでクリーンアップできず、フルGCでないとクリーンアップできない領域はかなり少ないそう。
そのためフルGCの実行を停止しても、大きな影響はないらしい。

定期的に手動実行しておいた方が良いかも！

先の設定を行うと、フルGCは一切行われなくなります。
そしてこれに伴い、クリーンアップされない領域が発生してしまいます。

そこでこの領域をクリーンアップするために、負荷が少ない時間を見計らって、PowerShellで手動でフルGCを行うか、タスクスケジューラーに登録しておき、スケジュール実行させるのが良いのではないかと。

以下はDドライブに対して、重複除去のフルGCを行うPowerShellコマンドの例です。

尚、このコマンドはすぐには実行されず、まずはキューに入れられます。
そして実行に必要なリソースが十分にあり、他のジョブが実行されていないタイミングで自動的に実行される仕組み。
そのため条件が整っていれば、直ちに実行されることも。

ちなみにキューに入れられたジョブ及び現在実行中のジョブの進捗状況は、以下のPowerShellコマンドを実行することで確認可能です。

重複除去のフルGCを再開させたい場合は？

先ほどレジストリの編集により停止させた、重複除去のフルGC。
これを再開させたい場合は、以下のコマンドをコマンド・プロンプトで実行することで再開されます。

このように簡単に設定を反映、そして元に戻すことが可能なので、重複除去を設定したボリューム上でvolsnap 25エラーが発生している場合は、一度この設定に変更して経過観察をしてみると良いかもしれません。