Avamar：VSSプラグイン バックアップの実行が遅い場合のトラブルシューティング ガイドライン

VSSプラグイン バックアップが低速または両方のVSSプラグイン バックアップを実行し、Diskshadowを使用してこれらの重要なボリュームのスナップショットを作成すると、パフォーマンスが低下していました。 

最初のシナリオでは、VSSプラグインのバックアップ パフォーマンスの低下が、重要なC:\ドライブ内のサブフォルダーの内容まで追跡され、全体的なバックアップ効率に影響を与えていました。

ケース#1：  Windows Update履歴のフォルダー コンテンツに従うと、Avamar VSS操作が遅くなっていました。

c:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.3328.1.7
c:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.3207.1.6

展開イメージのサービスと管理(DISM)とディスク クリーンアップ ユーティリティーを使用して、ガイドラインに従ってフォルダーのクリーンアップを開始します。

https://learn.microsoft.com/en-us/answers/questions/2191628/winsxs-occupying-more-space [learn.microsoft.com( 外部リンク) 
 

フォルダーのクリーンアップと除外の後、以前は2時間30分近くかかっていたVSSバックアップが35分から40分で完了します。

ケース#2: 「c:\Windows\System32\spool\PRINTERS\*」のフォルダー コンテンツが原因で、VSSバックアップの実行速度が低下していました。 

解決策は、次のフォルダー エントリーに対してデータセットの除外を追加することでした。 

--exclude=c:\Windows\System32\spool\PRINTERS\
--exclude=c:\Windows\System32\spool\PRINTERS*.tmp

ケース#3: 「C:\users*\appdata\*」のフォルダー コンテンツが原因で、Avamar VSSバックアップの速度が低下しています。 

Exclude "AppData\Local", "AppData\LocalLow" and " AppData\Roaming" directories from VSS backups. 

上記のフォルダーを除外しても、次の場所にあるMicrosoftガイドラインに従って、VSSバックアップの整合性には影響しません。

https://learn.microsoft.com/en-us/windows/apps/design/app-settings/store-and-retrieve-app-data(外部リンク)  

ケース#4: この場合、Avamar VSSバックアップまたはDiskshadowユーティリティーを使用して重要なボリュームのスナップショットを作成すると低速でした。根本原因を切り分けるには、次のコマンドを使用してVSSパフォーマンス トレースを有効にします(DOS adminコマンド プロンプトを使用)。

i) logman create trace vss_trace -ow -o %temp%\%computername%_vss_trace.etl -p {9138500E-3648-4EDB-AA4C-859E9F7B7C38} 0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode Circular -f bincirc -max 4096 –ets
ii) logman create counter PerfLog-1s -o "%temp%\%computername%_PerfLog-1.blg" -f bincirc -v mmddhhmm -max 300 -c "\LogicalDisk(*)\*" "\Memory\*" "\.NET CLR Memory(*)\*" "\Cache\*" "\Network Interface(*)\*" "\Netlogon(*)\*" "\Paging File(*)\*" "\PhysicalDisk(*)\*" "\Processor(*)\*" "\Processor Information(*)\*" "\Process(*)\*" "\Redirector\*" "\Server\*" "\System\*" "\Server Work Queues(*)\*" "\Terminal Services\*" -si 00:00:01
iii) logman start Perflog-1s

iv) Now START THE VSS backup USING DISKSHADOW or Avamar VSS Plugin

v) stop the trace once backup completed with the following elevated commands:
 
logman stop vss_trace -ets
logman stop Perflog-1s
logman delete Perflog-1s

キャプチャされたトレース ログは、"GetRootAndLogicalPrefixPaths" 関数がほぼループで継続的に実行されていることを示しています。

また、トレースでは、すべてのドライバーで有効になっているドライバー検証ツールが犯人であり、操作が遅くなっていることが示されています。Driver Verifier の影響の詳細については、
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/driver-verifier(外部リンク) を参照してください。

ケース#1：c:\Windows\servicing\LCUフォルダー内の小さなWindowsアップデート ファイルが原因で根本原因が特定されました。

c:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.3328.1.7
c:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.3207.1.6

解決策 は、DISM/ディスク クリーンアップ ユーティリティーを起動して冗長なエントリーを削除し、それでも問題が解決しない場合です。
データセット内のこれらのサブフォルダーの明示的な除外を追加します。

ケース#2：「c:\Windows\System32\spool\PRINTERS*.tmp」内の.tmpファイルが原因で根本原因が特定されました
解決策は、データセットに除外を追加することによってVSSバックアップからこれらのファイルを除外することです。

--exclude=c:\Windows\System32\spool\PRINTERS*.tmp

ケース#3: 「C:\users*\appdata\*」の3つのサブフォルダー エントリーが原因で根本原因が特定されました。サブフォルダー内のファイルには、ベア メタル リカバリー(BMR)リカバリーに必要でないと判断されたユーザー固有のアプリケーション データが格納されます。この問題を解決するには このフォルダーと3つのサブフォルダーのグローバル レベルでデータセットに除外を追加します。

"C:\users*\appdata\*"

ケース#4: 解決策は 、ドライバー検証ツールの実行を無効にし、VSSバックアップを10時間以上かかる時間ではなく15分で完了することでした。また、Diskshadow スナップショットは、変更前に 25 分以上かかっていたのが、わずか数秒で完了しました。