VolSnap 33 が大量に出てしまう問題について
こんにちは。
Windows テクノロジー サポートの新川です。
今回は、システム イベントで以下のように、「VolSnap 33 が大量に記録され 、 最終的に VolSnap 24 や 35 も発生し、 VSS の以前のバージョンが全て消えてしまった」という問題について、Windows Server 2003 での VSS の動作を含めて説明します。
**************************************************
イベントの種類: 情報
イベント ソース: VolSnap
イベント カテゴリ: なし
イベント ID: 33
説明:
ボリューム X: の最も古いシャドウコピーは、ボリューム X: のシャドウ コピーの使用ディスク領域をユーザーが定義した制限より小さく保つために削除されました。
**************************************************
・
・
**************************************************
イベントの種類: 警告
イベント ソース: VolSnap
イベント カテゴリ: なし
イベント ID: 24
説明:
X: のシャドウ コピーのシャドウ コピーの記憶域を拡大するためのディスク領域がボリューム X:に十分ありませんでした。
このエラーの結果、ボリューム X: のシャドウコピーすべてが削除される危険があります。
**************************************************
イベントの種類: エラー
イベント ソース: VolSnap
イベント カテゴリ: なし
イベント ID: 35
説明:
シャドウ コピーの記憶域を拡張できなかったためにボリューム X: のシャドウ コピーが中止しました。
**************************************************
何が問題か？
VSS において、各ボリュームの以前のバージョンは 64 世代が最大です。
65 世代目のスナップショットを作成したり、差分データを拡張する時などに、HDD の容量が足りなかったり、VSS の記憶域として設定した容量を超えてしまいそうな場合に、VolSnap 33 が出て必要な分だけ削除されてしまう事自体は正常な動作であり、これは仕方がありません。
しかしながら、ご利用いただいている方からすると非常に困るのは、「ディスクにまだ空きはあるのに、大量に VolSnap 33 が出てしまって、ほとんど全ての世代の差分データが消えてしまった」という場合ではないでしょうか？
その場合、上記のような VolSnap 33、24、35 や、処理状況によって、VolSnap 39 が合わせて記録されているはずです。
これは、Windows Server 2003 上で VSS の保護対象と記憶域が同一ボリュームである環境で発生しうる問題です。
これには VSS の動作が関係しており、根本的な回避を行うには保護対象と記憶域を別ボリュームにしていただく必要があります。
その内容について、VSS を理解する上でいくつか重要なキーワードと併せて説明します。
----------------
DiffArea と差分データ
はじめに、VSS の基本動作についてです。
VSS ではスナップショットを作成し、元々データが存在していたブロックが更新される際、「DiffArea」という領域に退避させておきます。
以前のバージョンとして参照する際は、DiffArea の中にあるブロックから古いデータを取り出す事で可能にします。
DiffArea は Windows Server 2003 SP1 以降の環境では、既定で 300MB の領域です。
予め 300MB 確保しておいて、変更量が多くて退避されたデータが 300MB に達しかけた時点で、DiffArea を拡張する事になります。
また、更にもう 1 世代追加でスナップショットが実行された場合、DiffArea 内に退避されたデータはその世代の「差分データ」として切り離します。
そして、改めて DiffArea が作成しなおされ、それ以降の変更情報がまた DiffArea に保存されていく事になります。
したがって、以前のバージョンの機能を使って数世代前のデータを取り出すには、「DiffArea 内の差分データ」~「自分の世代までの差分データ」で、遡りながら必要なブロックを参照する事で可能となります。
ビットマップと Copy-On-Write
時々、「VSS ではスナップショットを撮った後の変更データを保存しているんでしょ？」という風に理解をされている方がいらっしゃいますが、そうではありません。
VSS ドライバは、スナップショットが実行された時点で、保護対象のボリュームを 16KB 単位で分割し、元々データが存在していたか、変更が発生したか否かを「ビットマップ」で監視しています。
ビットマップ上で、データが存在していると認識されているブロックに対して変更を行う場合に、変更前のデータを DiffArea に退避します。
つまり、Write 処理が発生した時に初めてコピーされる事になりますので、VSS では「Copy-On-Write」処理を用いているという事になります。
万が一、拡張処理に失敗するなどで DiffArea 内に十分な領域がないと VSS は Copy-On-Write 処理が行えず、差分情報をトレースする事ができなくなってしまうため、VSS はリセットされる事になります。
リセットされた場合は、以前のバージョンは全て削除される事になります。
何故 VolSnap 33 は記録されるのか？
繰り返しになりますが、VolSnap 33 は、DiffArea を新規作成、もしくは拡張する際に容量が足りない場合、空き領域を確保するために発生します。
容量が足りないために一番古い世代の差分データを消す事で、ディスクの空き領域を確保しようとするわけですが、一番古い差分データを消しても十分な空き容量が確保できない場合、更にその時点で一番古い世代を消します。
この動きそのものは正常ですが、消しても消してもある理由から必要な領域が確保できないために、ほとんどの世代 (差分データ) が削除されてしまい、最終的に全部削除にまで至る場合があります。
領域とはディスク上の領域を指しますが、ディスク容量に十分に空き領域があるように見えても、足りない状況が発生する事があります。
空き領域とは？
DiffArea をディスク上に配置する際、以下を満たしている必要があります。
1. ボリューム上の空き容量が十分にある
2. 記憶域の最大値に対する空き容量が十分にある
3. VSS 上で利用可能と認識されているブロックが十分にある
1. は、ファイルシステムから見たボリューム上の空き領域です。2. も VSS の記憶域に上限値をつけた場合に適用される容量ですが、基本的にはファイルシステム上での容量です。
これらは、ボリュームのプロパティなどで見てもすぐに確認ができますが、目にも見えず問題となってくるのが、3. の「VSS 上で利用可能と認識されているブロック」です。
1. や 2. の領域は、差分データを削除する事で確保する事が可能ですが、3. の領域は保護対象と記憶域が同一ボリュームになっている場合、ほとんど増やす事ができません。
理由は、差分データも保護が必要な一つのファイルとして認識されているからです。
保護対象となっているファイルは、スナップショット実行後に削除された場合でも、ビットマップ上ではデータが存在していたブロックとして認識されているため、そのブロックに書き込みを行う際は、DiffArea への Copy-On-Write が必要となります。
全ての差分データが消えてしまう
上記は言い換えると、Copy-On-Write を行わないと空けたはずのブロックに書き込みができないわけですが、そもそも DiffArea が足りなくて拡張処理を行っているので、Copy-On-Write はできない状況です。
そうなると、VSS では空き領域を確保するために、更に一番古い世代の差分データを削除します。
しかし、差分データの中でもデータが配置されていたブロックは Copy-On-Write を行わない限り書き込み可能とならない状況は続いているため、一番古い世代の差分データを削除しても 3. のブロックは増えず、更に次々と再帰的に削除されてしまう事になります。
差分データの削除により、途中で運よく利用可能になったブロックが十分に見つかればよいのですが、DiffArea ではある程度まとまった連続領域も必要であるため、空き領域として認識されるには、非常にシビアな状態です。
大量に削除される事で VolSnap 24 が発生しますが、全部消えてしまっても空きブロックが見つからない場合、DiffAreaの拡張処理が失敗し、最終的に VSS が一旦リセットされてVolSnap 35 が記録される事になります。スナップショット実行時であれば、VolSnap 39 が記録されて失敗する事となります。(この場合、残っている DiffArea にまだ書き込み可能であれば、以前のバージョン全てが消えない事もあります)
対処するには？
Windows Server 2003 環境での対処方法としては、冒頭に申し上げた通り、保護対象ボリュームと VSS 記憶域のボリュームを別々にする事になります。
記憶域が保護対象ボリューム上にない事で、削除した差分データが存在していた領域がすぐに利用できる事となります。
なお、Windows Server 2008 ではこの点について大きなデザイン変更が実施されており、VolSnap 33 が発生した際にビットマップを再計算して 3. のブロックを新たに設定しなおす事で改善されています。
しかし、誠に残念ながら非常に大きな変更であるため、Windows Server 2003 適用する事ができていません。
暫定対処は？
もし、Windows Server 2003 の環境において、どうしても記憶域ボリュームを別にする事ができない場合には、VSS の世代数を制限することで、各ブロックが参照されている確率を抑える事ができるため、この問題に対してある程度の抑制はできると考えられます。
下記に記載しますレジストリで、VSS の世代数は制限可能ですので、ご検討ください。
- 手順例（5 世代までの保存とする場合）
1. [ スタート ] - [ ファイル名を指定して実行 ] をクリックして [ regedit ] と入力し、Enter キーを押します。
2. 次のレジストリ サブキーを見つけて右クリックします。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings
3. [ 新規 ] をポイントして [ DWORD 値 ] をクリックします。
4. MaxShadowCopies と、入力し Enter を押します。
5. MaxShadowCopies をダブルクリックし、 値のデータボックスに 5 を入力して [ OK ] をクリックします。
6. レジストリ エディタを終了します。
7. コンピュータを再起動します。
-参考資料
Article ID: 945058
When you use the Volume Shadow Copy Service on Windows Server 2003-based computers that run many I/O operations, disk volumes take longer to go online