Avamar: VSS-Plug-in-Backups laufen langsam Troubleshooting-Richtlinien

VSS-Plug-in-Backups wurden langsam ausgeführt oder beide VSS-Plug-in-Backups und das Erstellen eines Snapshots dieser kritischen Volumes mit Diskshadow zeigten eine schlechte Performance. 

Im ersten Szenario wurde eine schlechte VSS-Plug-in-Backupperformance auf den Inhalt von Unterordnern auf dem kritischen Laufwerk C:\ zurückgeführt, was sich auf die Gesamteffizienz des Backups auswirkte.

Fall 1:  Die folgenden Ordnerinhalte für den Windows-Updateverlauf verlangsamten die Avamar VSS-Vorgänge.

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

Verwenden Sie die Abbildverwaltung für die Bereitstellung (DISM) und das Dienstprogramm für die Datenträgerbereinigung, um die Ordnerbereinigung gemäß den Richtlinien zu initiieren.

https://learn.microsoft.com/en-us/answers/questions/2191628/winsxs-occupying-more-space [learn.microsoft.com(externer Link) 
 

Nach der Ordnerbereinigung und dem Ausschluss sind VSS-Backups, die zuvor fast 2 Stunden und 30 Minuten in Anspruch nahmen, jetzt in 35 bis 40 Minuten abgeschlossen.

Fall #2: Der Ordnerinhalt "c:\Windows\System32\spool\PRINTERS\*" führte dazu, dass VSS-Backups langsam ausgeführt wurden. 

Die Lösung bestand darin, einen Datensatzausschluss für diese Ordnereinträge hinzuzufügen: 

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

Fall #3: Der Ordnerinhalt "C:\users*\appdata\*" verlangsamt Avamar VSS-Backups. 

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

Der Ausschluss der oben genannten Ordner hat keine Auswirkungen auf die Integrität von VSS-Backups gemäß den Microsoft-Richtlinien unter:

https://learn.microsoft.com/en-us/windows/apps/design/app-settings/store-and-retrieve-app-data (externer Link)  

Fall #4: In diesem Fall war die Verwendung von Avamar VSS-Backups oder des Diskshadow-Dienstprogramms zum Erstellen von Snapshots der kritischen Volumes langsam. Um die Grundursache zu isolieren, aktivieren Sie den VSS-Performance-Trace mit den folgenden Befehlen (verwenden Sie die DOS-Administratoreingabeaufforderung):

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

Die erfassten Ablaufverfolgungsprotokolle weisen auf eine kontinuierliche Ausführung der Funktion "GetRootAndLogicalPrefixPaths" hin, die fast in einer Schleife ausgeführt wird.

Außerdem wird in der Ablaufverfolgung eine Treiberüberprüfung angezeigt, die für alle Treiber aktiviert wurde, die der Übeltäter sind und die Vorgänge verlangsamen. Weitere Details zur Auswirkung der Treiberprüfung finden Sie unter:
https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/driver-verifier(externer Link)

Fall 1: Die Ursache wurde aufgrund winziger Windows-Updatedateien im Ordner c:\Windows\servicing\LCU identifiziert.

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

Die Lösung besteht darin, ein DISM/"disk cleanup utility" zu initiieren, um redundante Einträge zu entfernen, wenn dies nicht hilft. 
Fügen Sie den expliziten Ausschluss dieser Unterordner im Dataset hinzu.

Fall 2: Ursache identifiziert aufgrund .tmp Dateien in "c:\Windows\System32\spool\PRINTERS*.tmp"
Die Lösung besteht darin, diese Dateien aus dem VSS-Backup auszuschließen, indem ein Ausschluss im Dataset hinzugefügt wird:

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

Fall #3: Die Ursache wurde aufgrund von drei Unterordnereinträgen in "C:\users*\appdata\*" identifiziert. In den Dateien in den Unterordnern werden nutzerspezifische Anwendungsdaten gespeichert, die für die BMR-Recovery (Bare Metal Recovery) nicht als erforderlich erachtet werden. Um dieses Problem zu beheben,  fügen Sie einen Ausschluss im Dataset auf globaler Ebene für diesen Ordner und die drei Unterordner hinzu:

"C:\users*\appdata\*"

Fall #4: Die Lösung bestand darin, die Ausführung der Treiberprüfung zu deaktivieren und VSS-Backups in 15 Minuten statt mehr als 10 Stunden abzuschließen. Außerdem dauerte der Diskshadow-Snapshot vor der Änderung nur wenige Sekunden statt mehr als 25 Minuten.