2016 Windows Server Backup Probleme
Hallo,
Meine Windows-Server-Sicherung spinnt. Laut Taskplaner sollte sie jeden Tag um 22:00 starten, jedoch ist davon nichts im WMAdmin.msc zu sehen.
Aus der Ereignisanzeige: Quelle VSS
Quelle SPP
Quelle: Application Error
Starte ich den Task manuell, dann
Quelle CAPI2
Der Server wurde erst vor einer Woche frisch installiert und ausser Updates wurde noch nicht wirklich etwas daran gemacht. Es sind sämtliche Hardwaretreiber installiert.
Mit meinen Suchevorgängen im Internet bin ich noch nicht wirklich weiter gekommen, ausser dass ich den Hyper-V neustarten sollte. Jedoch habe ich mehrfach den kompletten Server schon neu gestartet.
Eins habe ich gefunden, kommt bei vssadmin list writers
Es ist kein Sharepoint im Einsatz, das ist das einzige was ich zu dem Thema im Netz finde.
Hat noch jemand eine Idee, wie ich weiter vorgehen kann um das Problem einzugrenzen bzw. zu beheben ?
Grüße, Henere
Meine Windows-Server-Sicherung spinnt. Laut Taskplaner sollte sie jeden Tag um 22:00 starten, jedoch ist davon nichts im WMAdmin.msc zu sehen.
Aus der Ereignisanzeige: Quelle VSS
Das Ereignis wird nicht richtig angezeigt, da der zugrunde liegende XML-Code nicht wohlgeformt ist. Nachstehend finden Sie den reinen Text des Ereignisses.
8228200x800000000000002110ApplicationS-Grosshirn.meinedomain.localIm Textinhalt wurde ein ungültiges Zeichen gefunden. 0x000001c90x00000020, Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. 0xc00ce508ᙱ쀁얃캱ఁ剗è㹜䖋诠甠菤ࣀ柀僐匐쀷茲᳄ą챦ኀ䶋诘ࣃ䄤訕㨐᩵튄ቴ傊Ā儺甁茎À茂ˁ튄㌀ᬅ菀ꃈ蔁瓀耬耑⇀쀃쁊⇨譓叞೨ৰ澠፵絨ԁ樗譟졅譀诞譏ܪҁ愌ฏѠ䄹儼ꁈ䕲䀅Ь倉䇨ᅤ㩁弄孫䶋ﰀ촳틨䃿썝㹨ఆᥤ䀂憃䀂ಠ綋嗨ু찂䐢䀄譔䔄Ȍ㢉桗⠀屹贀聪倍የ鬒䃿ࠁ桐ꇜʕ勨ख़ᇀࡃⓠ䔹瓀ᐂؠ倐취ヒꄉ잛䁃蔀僶⥴䚋ᗄ䘋琠ៀ嘁秨Ѓ쀗幟촳ᑛ෨ᢅ虈朘㛩レ嫀ڄ쌂궥ꉠᐚ⣩聰棡桢Á棚쁙⌀敋䃺차譕ì痿謌ࡅ큨툀Y烿䫚Ŀಲ⢂썝Ϡ₋똏䃈謄@༄ҷ荈Ǡ崤ꏃ찇븃ࣀꄰ렂鷀晡ꘀ먃ꀟࡉ嘈똏鉁蕦且甌丄耐ቴ똏ň왞</root>2D20436F64653A2020425545584D4C4330303030303832302D2043616C6C3A2020425545584D4C4330303030303737362D205049443A202030303030383732342D205449443A202030303030303234382D20434D443A202022433A5C57696E646F77735C73797374656D33325C7762656E67696E652E657865222020202020202D20557365723A204E616D653A204E542D4155544F524954C4545C53595354454D2C205349443A532D312D352D313820
Quelle SPP
Microsoft Hyper-V VSS Writer
Teilfehler im Generator. Überprüfen Sie den Fehlerstatus auf Komponentenebene, um weitere Informationen zu erhalten. (0x80042336)
Unbekannter Fehler (0x80004005)
01000000B8120000991200000000000042BEB7C511CAC619E59C92030000000000000000
Quelle: Application Error
wbengine.exe
10.0.14393.1198
590282d8
wbengine.exe
10.0.14393.1198
590282d8
c0000005
00000000001043b9
1fc4
01d324ef39d2bb50
C:\Windows\system32\wbengine.exe
C:\Windows\system32\wbengine.exe
6cfbf691-3560-4ad7-abf8-4f0d6d246f7d
***********************
0
APPCRASH
Nicht verfügbar
0
wbengine.exe
10.0.14393.1198
590282d8
wbengine.exe
10.0.14393.1198
590282d8
c0000005
00000000001043b9
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_wbengine.exe_45ad62a5f2886421bffa85f4d21258e3e5eebce_b552eb88_224d8e4c
0
054f0d77-47df-485f-8ab8-efeca0f7c7a9
4
Starte ich den Task manuell, dann
Quelle CAPI2
Details: AddLegacyDriverFiles: Unable to back up image of binary Microsoft-Verbindungsschichterkennungsprotokoll. System Error: Zugriff verweigert
Der Server wurde erst vor einer Woche frisch installiert und ausser Updates wurde noch nicht wirklich etwas daran gemacht. Es sind sämtliche Hardwaretreiber installiert.
Mit meinen Suchevorgängen im Internet bin ich noch nicht wirklich weiter gekommen, ausser dass ich den Hyper-V neustarten sollte. Jedoch habe ich mehrfach den kompletten Server schon neu gestartet.
Eins habe ich gefunden, kommt bei vssadmin list writers
Verfassername: "Microsoft Hyper-V VSS Writer"
Verfasserkennung: {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Verfasserinstanzkennung: {204d89f0-6ae1-4c72-b21e-984b09e894bc}
Status: [5] Warten auf Fertigstellen
Letzter Fehler: Unerwarteter Fehler
Es ist kein Sharepoint im Einsatz, das ist das einzige was ich zu dem Thema im Netz finde.
Hat noch jemand eine Idee, wie ich weiter vorgehen kann um das Problem einzugrenzen bzw. zu beheben ?
Grüße, Henere
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 348082
Url: https://administrator.de/forum/2016-windows-server-backup-probleme-348082.html
Ausgedruckt am: 23.04.2025 um 15:04 Uhr
18 Kommentare
Neuester Kommentar
Zitat von @Henere:
Was kann ich jetzt noch machen ?
Die VM die er nicht sichern will ist ein WSUS auf 2016, dessen 2 VHDX (1xSystem auf physikalisch C:\ und 1x WSUS-Daten auf physikalisch D:\).
Kann es daran liegen, dass die dazugehörigen VHDX auf 2 unterschiedlichen phys HDDs liegen ?`
Was kann ich jetzt noch machen ?
Die VM die er nicht sichern will ist ein WSUS auf 2016, dessen 2 VHDX (1xSystem auf physikalisch C:\ und 1x WSUS-Daten auf physikalisch D:\).
Kann es daran liegen, dass die dazugehörigen VHDX auf 2 unterschiedlichen phys HDDs liegen ?`
Beim Backup deiner VM, muss für jede Partition/Festplatte auf der eine virtuelle Festplatte (VHDX) existiert, eine Schattenkopie angelegt werden. Je nach System, kann es hierbei zu einen Deadlock oder Timeout kommen. Es wird also je eine Schattenkopie von C:\ und D:\ gleichzeitig angelegt.
Den Speicherplatz für die VHDX Dateien würde ich zum Test wieder auf eine Festplatte bzw. Partition verschieben/zusammenführen und natürlich das Systemlaufwerk C:\ vermeiden.
Viel Erfolg...
Zitat von @Henere:
Das Backup läuft als System und System hat NTFS-Vollzugriff auf die Ordner des Hyper-V.
Noch jemand eine Idee ?
Das Backup läuft als System und System hat NTFS-Vollzugriff auf die Ordner des Hyper-V.
Noch jemand eine Idee ?
Vielleicht mal folgenden Link ansehen, vielleicht bringt es dich weiter, denn Du hast ebenfalls einen "Zugriff verweigert-Fehler (0x80070005)". Leider gibt es dafür diverse Ursachen...
http://www.ryadel.com/en/volume-shadow-copy-service-error-unexpected-er ...
MfG
Zitat von @Henere:
Warum kann er C: einwandfrei sichern und D: nicht mehr ? Das Sicherungsziel ist ein QNAP TS-563 mit 5x4TB im RAID5 HDDs als iSCSI-Target.
Die Verbindung dorthin läuft fehler- und paketverlustfrei (Dauerping während des Backups)
Warum kann er C: einwandfrei sichern und D: nicht mehr ? Das Sicherungsziel ist ein QNAP TS-563 mit 5x4TB im RAID5 HDDs als iSCSI-Target.
Die Verbindung dorthin läuft fehler- und paketverlustfrei (Dauerping während des Backups)
Du kannst dein Systemlaufwerk C: sichern, da nur der "VSS Writer" betroffen ist und eine Fehlfunktion meldet:
Name des Writers: "Microsoft Hyper-V VSS Writer"
Status des Writers: "5"
Fehlerergebnis: "80042336"
Anwendungsergebnis: "80004005"
Der Status des Microsoft Hyper-V VSS Writer ist 5 (Waiting for completion) , d.h. es wird noch auf "irgendwas" gewartet und die Meldung "Allgemeiner "Zugriff verweigert"-Fehler (0x80070005)", spricht auch dafür. Das muss nicht zwingend dein QNAP TS-563 sein.
Für das Fehlerergebnis 80042366 gibt es dann auch diverse Lösungsansätz bei Google.
Es wird Dir nichts anderes übrigbleiben, als dich da durch die Lösungsansätze (Google) durchzukämpfen, denn Du kennst das/dein System noch am besten.
MfG
Zitat von @Henere:
Wobei ich immer noch nicht den Zusammenhang verstehe mit einer gelöschten VM und einem jetzt scheinbar wieder funktionierendem Backup. Vielleicht hat da ja noch jemand eine Idee dazu.
Wobei ich immer noch nicht den Zusammenhang verstehe mit einer gelöschten VM und einem jetzt scheinbar wieder funktionierendem Backup. Vielleicht hat da ja noch jemand eine Idee dazu.
Der Hyper-V VSS Writer sorgt u.a. dafür das deine VM in einen konsistenten Zustand ist. Legt ein Dienst (in der VM) ein Veto ein oder benötigt einfach zu lange um zu pausieren, kommt es zu einem Timeout:
Hyper-V VSS Writer ist 5 (Waiting for completion)
Dieser Timeout löst dann oft eine Kettenreaktion aus. In den Fehlerberichten zum Backup wird häufig nur der letzte Fehler angezeigt, der nicht unbedingt die Ursache sein muss.
Kann also sehr gut möglich sein, das eine neue VM mit einen neuen WSUS, den Fehler nach einiger Zeit nochmal produziert
Aber jetzt kennst Du die Lösung….