12
Windows Server Backup - Fehler: Die für die Sicherung erstellte Schattenkopie enthält eine inkonsistente Systemkomponente
Hallo zusammen,
seit ca. einem Monat haben wir bei einem Kunden folgendes Problem:
Die Sicherung per Windows Server Backup Bricht laut wbadmin GUI mit dem Fehler:
„Die für die Sicherung erstellte Schattenkopie enthält eine inkonsistente Systemkomponente“ ab (Logfiles anbei).
Erstmal zum System:
Fujitsu Primergy TX1330 M3 – Xeon E3-1220v6 – 32GB DDR4 2400 ECC
Storage: System: Raid1, 2x 1TB Daten: Raid1, 2x2TB
OS: Windows Server 2016 Essentials (mit allen aktuellen Updates)
Software: Siehe Screenshot anbei
Sicherung auf 4x 4TB USB 3.0 Platten, ca. 4 Monate alt
Einsatz in Produktivumgebung!
Der Server läuft in einer Produktivumgebung, somit bin ich beim testen immer etwas eingeschränkt.
Ich habe schon versucht eines der laut wbadmin funktionsfähigen Backups in einer VM wiederherzustellen, damit ich sozusagen eine Testumgebung hätte, soweit funktionierte das auch, allerdings startet der, in der VM Wiederhergestellt Server dann mit dem Bluescreen 0xc00002e2 - deutet auf ein Problem mit der AD hin.
Da ich jetzt nicht noch eine Baustelle anfangen und dann ggf. noch zusätzliche dadurch entstandene Probleme debuggen möchte, teste ich soweit möglich erst mal am Produktiv-Server weiter.
So nun zum eigentlichen Problem:
Die Schattenkopie ist soweit ich das verstehe inkonsistent, da sich einer oder mehrere VSS-Writer im Fehlerzustand befinden.
Dies kann ich mittels "VSSADMIN list writers" auch auslesen und bestätigen.
Mittels dem Script "VSS ReRegisterALL.bat" (anbei) lässt sich dies beheben, indem ich alle relevanten Dienste stoppe, die entsprechenden DLLs neu registriere und die Dienste dann wieder starte. Allerdings fallen diese nach/während dem Backup immer wieder zurück in den Fehlerzustand.
Auffällig ist, dass der Servern im Vergleich zu anderen Servern mit vergleichbarer Hardware und Datenmenge schon sehr lange für das erstellen der Schattenkopien benötigt (teilweise 15-20 min).
Außerdem ist mir aufgefallen, dass die Ausgabe in der CMD oft „hängt“ heißt, in der CMD steht z.b. noch „eine Schattenkopie wird erstellt“, aber am Festplatten-Monitoring kann ich eindeutig sehen dass, das Backup schon komplett durch ist. Klicke ich dann in die CMD und drücke 2x Enter- oder Leer-Taste, sind die Zeilen auf einmal alle da...
Was wir bisher schon versucht haben:
Test halber habe ich nun alle Schattenkopien von C: und D: per CMD (soweit möglich per "wbadmin", den Rest per "diskshadow") gelöscht. Seit dem ist die Erfolgsquote per CMD jetzt deutlich besser aber immer noch weit entfernt von zuverlässig.
Aktuell erstelle ich Backups nur noch per CMD nach folgenden Schema:
1. "VSS ReRegisterALL.bat" (als Admin) starten,
2. dann im Servermanager alle beendeten Dienste wieder starten.
3. das Backup über die CMD mit folgendem Befehl erstellen: "wbadmin.exe START BACKUP -backupTarget:X: -include:C:,D: -allCritical -vssFull"
Mit dieser Methode lauft das Backup fast immer (~90%) ohne Fehler durch.
Skripte und Logfiles:
https://www.dropbox.com/sh/vq1nv6urdq4tco9/AACcE_dFi51uaRevznEH7n_da?dl= ...
Installierte Software:
seit ca. einem Monat haben wir bei einem Kunden folgendes Problem:
Die Sicherung per Windows Server Backup Bricht laut wbadmin GUI mit dem Fehler:
„Die für die Sicherung erstellte Schattenkopie enthält eine inkonsistente Systemkomponente“ ab (Logfiles anbei).
Erstmal zum System:
Fujitsu Primergy TX1330 M3 – Xeon E3-1220v6 – 32GB DDR4 2400 ECC
Storage: System: Raid1, 2x 1TB Daten: Raid1, 2x2TB
OS: Windows Server 2016 Essentials (mit allen aktuellen Updates)
Software: Siehe Screenshot anbei
Sicherung auf 4x 4TB USB 3.0 Platten, ca. 4 Monate alt
Einsatz in Produktivumgebung!
Der Server läuft in einer Produktivumgebung, somit bin ich beim testen immer etwas eingeschränkt.
Ich habe schon versucht eines der laut wbadmin funktionsfähigen Backups in einer VM wiederherzustellen, damit ich sozusagen eine Testumgebung hätte, soweit funktionierte das auch, allerdings startet der, in der VM Wiederhergestellt Server dann mit dem Bluescreen 0xc00002e2 - deutet auf ein Problem mit der AD hin.
Da ich jetzt nicht noch eine Baustelle anfangen und dann ggf. noch zusätzliche dadurch entstandene Probleme debuggen möchte, teste ich soweit möglich erst mal am Produktiv-Server weiter.
So nun zum eigentlichen Problem:
Die Schattenkopie ist soweit ich das verstehe inkonsistent, da sich einer oder mehrere VSS-Writer im Fehlerzustand befinden.
Dies kann ich mittels "VSSADMIN list writers" auch auslesen und bestätigen.
Mittels dem Script "VSS ReRegisterALL.bat" (anbei) lässt sich dies beheben, indem ich alle relevanten Dienste stoppe, die entsprechenden DLLs neu registriere und die Dienste dann wieder starte. Allerdings fallen diese nach/während dem Backup immer wieder zurück in den Fehlerzustand.
Auffällig ist, dass der Servern im Vergleich zu anderen Servern mit vergleichbarer Hardware und Datenmenge schon sehr lange für das erstellen der Schattenkopien benötigt (teilweise 15-20 min).
Außerdem ist mir aufgefallen, dass die Ausgabe in der CMD oft „hängt“ heißt, in der CMD steht z.b. noch „eine Schattenkopie wird erstellt“, aber am Festplatten-Monitoring kann ich eindeutig sehen dass, das Backup schon komplett durch ist. Klicke ich dann in die CMD und drücke 2x Enter- oder Leer-Taste, sind die Zeilen auf einmal alle da...
Was wir bisher schon versucht haben:
- Reboot – mehrfach, durch das "VSS ReRegisterALL.bat" Skript jetzt allerdings nicht mehr nötig.
- Neustart sämtlicher VSS relevanter Dienste - mehrfach, wird nun durch "VSS ReRegisterALL.bat" übernommen.
- Re-Registrierung der entsprechenden DLLs mittels "VSS ReRegisterALL.bat".
- Vollscan mit G-Data und Windows Defender – alles OK.
- Deaktivieren des G-Data Client auf dem Server – keine Besserung, wieder aktiviert.
- SFC /Scannow – hat die Fehler welche im ersten Durchlauf gefunden wurden korrigiert, seit dem werden keine Fehler mehr gefunden.
- Durchführung einer Einmal-Sicherung per wbadmin GUI – mehrfach mit verschiedenen Parametern z.B nur Systemstate + C: statt ganzer Server → Selber Fehler.
- VSSADMIN list writers → Nach neustart bzw. dem VSS ReRegisterALL.bat immer alles OK, nach Sicherung per GUI meist 2-3 (oft DHCP Jet Writer und DFS Replication) im Fehlerzustand.
- Sicherung auf andere Festplatten / NAS / VHDs – keine Besserung, selber Fehler.
- wbadmin Task komplett neu eingerichtet und die Sicherungsplatten neu formatiert.
- Smart werte der Festplatten geprüft – alles I.O.
- Laufwerk C: Defragmentiert da 23% fragmentiert, das ganze lief ca. 36h …? - Danach war das Laufwerk allerdings immer noch 16% fragmentiert – Nochmal durchlaufen lassen (diesmal über Nacht <12h fertig) laut „Datenträger Eigenschaften → Tools → Optimieren“ aber immer noch 13% fragmentiert - komisch...
- Mainboard inkl. RAID-Controller getauscht - keine Besserung nur sehr viel Aufwand.
- Wbadmin Backup mittels CMD (statt GUI) – selber Fehler aber höhere Erfolgsquote als per GUI (wenn ich vorher das "VSS ReRegisterALL.bat" Skript ausführe.)
Test halber habe ich nun alle Schattenkopien von C: und D: per CMD (soweit möglich per "wbadmin", den Rest per "diskshadow") gelöscht. Seit dem ist die Erfolgsquote per CMD jetzt deutlich besser aber immer noch weit entfernt von zuverlässig.
Aktuell erstelle ich Backups nur noch per CMD nach folgenden Schema:
1. "VSS ReRegisterALL.bat" (als Admin) starten,
2. dann im Servermanager alle beendeten Dienste wieder starten.
3. das Backup über die CMD mit folgendem Befehl erstellen: "wbadmin.exe START BACKUP -backupTarget:X: -include:C:,D: -allCritical -vssFull"
Mit dieser Methode lauft das Backup fast immer (~90%) ohne Fehler durch.
Skripte und Logfiles:
https://www.dropbox.com/sh/vq1nv6urdq4tco9/AACcE_dFi51uaRevznEH7n_da?dl= ...
Installierte Software:
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 588227
Url: https://administrator.de/contentid/588227
Ausgedruckt am: 26.11.2024 um 00:11 Uhr
12 Kommentare
Neuester Kommentar
Ich habe zwar keine Lösung für dein Problem, jedoch, die VM startet vermutlich nicht, weil sie ihre alte Netzwerkkarte nicht mehr findet und damit den AD Dienst nicht mehr starten kann. Mit einer Rücksicherung auf die Hardware müsste es also klappen. Steck dafür am besten eine leere Platte dafür rein, damit deine Originalinstallation nicht zerstört wird und du einen Weg zurück hast.
Hi,
ja, so war auch meine Vermutung.
Allerdings handelt es sich um einen eher kleinen Server der leider nur 4 Schächte für Festplatten hat welche alle belegt sind.
Außerdem lauft der Server im Produktivbetrieb und da möchte ich so wenig wie möglich Ausfallzeit produzieren...
ABER: Du hat mich auf eine andere Idee gebracht:
Ich bin mir fast sicher, das ich bei meiner Virtualisierungsplattform in den Optionen die MAC-Adresse des Netzwerkadapters von Hand anpassen kann, ggf. macht er es wenn ich da die Original MAC-Adressen eintrage
.
ja, so war auch meine Vermutung.
Allerdings handelt es sich um einen eher kleinen Server der leider nur 4 Schächte für Festplatten hat welche alle belegt sind.
Außerdem lauft der Server im Produktivbetrieb und da möchte ich so wenig wie möglich Ausfallzeit produzieren...
ABER: Du hat mich auf eine andere Idee gebracht:
Ich bin mir fast sicher, das ich bei meiner Virtualisierungsplattform in den Optionen die MAC-Adresse des Netzwerkadapters von Hand anpassen kann, ggf. macht er es wenn ich da die Original MAC-Adressen eintrage
.
Du kannst auch vor dem Backup eine neue virtuelle Netzwerkkarte hinzufügen, die nach dem Restore noch im Image existiert, damit sollte der DC hoch kommen und du kannst dann die Hypervisor Netzwerkkarte wieder normal einrichten und die virtuelle Netzwerkkarte danach raus werfen. Um das Backup und den Restore zu umgehen, verwende gleich DISK2VHD mit dem Ziel auf eine Freigabe im Hypervisor, dann sparst du mehr als 50% der Zeit. Vorausgesetzt DISK2VHD stoßt nicht auf den gleichen Fehler :c) Es macht nämlich auch nur ein Snapshot im Betrieb und kopiert es weg - zumindest gleich als lauffähige VHD(X) für den Hypervisor.
Hättest du es dann vor gehabt als VM gleich so zu lassen?
Hättest du es dann vor gehabt als VM gleich so zu lassen?
Zitat von @NordicMike:
Du kannst auch vor dem Backup eine neue virtuelle Netzwerkkarte hinzufügen....
Stimmt, gute Idee!Du kannst auch vor dem Backup eine neue virtuelle Netzwerkkarte hinzufügen....
Werde ich ausprobieren, wenn das mit der MAC-Adresse nicht ausreicht.
Hättest du es dann vor gehabt als VM gleich so zu lassen?
Nein, eigentlich war die VM zur zum Debugging gedacht, da könnte ich dann halt einfacher testen z.b. bei neustarts...
In der VM wird der Fehler weg sein. Auch darf sie nur in einer isolierten Netzwerkumgebung laufen, sonst störst du die produktive Umgebung damit.
Ich denke dir wird nichts übrig bleiben an einem Wochenende die 4 Platten aus zu ziehen, eine Rücksicherung auf 4 neue Platten zu machen und damit wieder hochfahren.
Oder jemand hier im Forum hat wirklich Kenntnisse VSS Fehler in der Laufzeit zu diagnostizieren und zu reparieren.
Ich denke dir wird nichts übrig bleiben an einem Wochenende die 4 Platten aus zu ziehen, eine Rücksicherung auf 4 neue Platten zu machen und damit wieder hochfahren.
Oder jemand hier im Forum hat wirklich Kenntnisse VSS Fehler in der Laufzeit zu diagnostizieren und zu reparieren.
So kleines Update: Habe mich die letzte Woche nun nochmal intensiv mit dem Thema beschäftigt...
Die VM läuft jetzt, Problem war dass bei der Wiederherstellung mittels Win Server Sicherung die NTDS.dit (Active Directory DB) nicht Wiederhergestellt wurde. Warum weiß ich nicht, die Datei war in der Sicherung eigentlich vorhanden.
Ich habe den Server dann im "Verzeichnisdienstwiederherstellung-Modus" gebootet, die VHD aus der Sicherung gemountet und die Datei manuell wiederhergestellt. Dann habe ich diese mittels
überprüft -> alles OK. Also Reboot und siehe da, funktioniert!
Durch die geänderte Netzwerkkarten-Konfiguration funktioniert nun der AD-Zertifikatsdienst nicht. Das wäre jetzt an sich nicht so schlimm, die VM läuft sowieso in einer isolierten Umgebung ohne Internet. Nur leider funktionierte die Sicherung auch nicht.
Das lies sich dann allerdings relativ simpel mittels (Admin CMD) beheben.
Wie schon von @NordicMike vermutete, ist der VSS-Fehler in der VM nun weg. Die VM läuft nun seit 5 tagen fehlerfrei in einer isolierten Umgebung.
Somit hat sich das mit dem Debugging in der VM nun wohl erledigt.
Habe dann am "Original Server" zur Sicherheit auch nochmal die NTDS.dit überprüft -> alles OK.
Dann habe ich wbadmin nochmal komplett bereinigt:
Achtung unbedingt darauf achten, dass man noch weitere Backups hat!!
Dies mache ich mittels: und per alle restlichen Backups und Schattenkopien gelöscht. Dann habe ich mittels den Sicherungs-Katalog gelöscht.
Dann habe ich per wbadmin GUI die Sicherung wieder eingerichtet. Das ganze lief dann für 2 Tage problemlos, dann waren wieder 11 der Writer im Fehlerzustand [9].
LOG: https://www.dropbox.com/s/m44ugusip0xz7bp/WriterErrors.txt?dl=0
Die VM läuft jetzt, Problem war dass bei der Wiederherstellung mittels Win Server Sicherung die NTDS.dit (Active Directory DB) nicht Wiederhergestellt wurde. Warum weiß ich nicht, die Datei war in der Sicherung eigentlich vorhanden.
Ich habe den Server dann im "Verzeichnisdienstwiederherstellung-Modus" gebootet, die VHD aus der Sicherung gemountet und die Datei manuell wiederhergestellt. Dann habe ich diese mittels
NTDSUTIL.exeactivate instance ntdssemantic database analysisgo fixupüberprüft -> alles OK. Also Reboot und siehe da, funktioniert!
Durch die geänderte Netzwerkkarten-Konfiguration funktioniert nun der AD-Zertifikatsdienst nicht. Das wäre jetzt an sich nicht so schlimm, die VM läuft sowieso in einer isolierten Umgebung ohne Internet. Nur leider funktionierte die Sicherung auch nicht.
Das lies sich dann allerdings relativ simpel mittels
wbadmin delete catalogWie schon von @NordicMike vermutete, ist der VSS-Fehler in der VM nun weg. Die VM läuft nun seit 5 tagen fehlerfrei in einer isolierten Umgebung.
Somit hat sich das mit dem Debugging in der VM nun wohl erledigt.
Habe dann am "Original Server" zur Sicherheit auch nochmal die NTDS.dit überprüft -> alles OK.
Dann habe ich wbadmin nochmal komplett bereinigt:
Achtung unbedingt darauf achten, dass man noch weitere Backups hat!!
Dies mache ich mittels:
wbadmin delete backupwbadmin delete systemstatebackupDISKSHADOWwbadmin delete catalogDann habe ich per wbadmin GUI die Sicherung wieder eingerichtet. Das ganze lief dann für 2 Tage problemlos, dann waren wieder 11 der Writer im Fehlerzustand [9].
LOG: https://www.dropbox.com/s/m44ugusip0xz7bp/WriterErrors.txt?dl=0
Hallo,
ich wollte fragen, ob du dein Problem irgendwie lösen konntest?
Ich bin leider mit der gleichen Hardware unter ähnlichen Umständen ebenfalls am Verweifeln.
Der Vor-Vorgänger hat das System angeschafft und aufgebaut.
Im Server sind alle 4 Plätze mit SATA HDDs belegt.
2x Desktop HDDs
2x Server HDDs
Die Desktop HDDs wurden für das Windows verwendet, die Server HDDs für das Windows Backup.
Beide sind im RAID1.
Bei der Installation hat man schon also einen Fehler gemacht und das falsche Array ausgewählt.
Die Performance der Maschine ist aufgrund der Festplatten grottenschlecht, ich habe zuerst den RAM aufgerüstet und wollte nun 2x SSDs im RAID einsetzen.
Bisher ist alles aufgrund der performancebedingten Probleme mit dem VSS gescheitert.
1. P2V Conversion mti dem vCenter Converter auf eine HP ML350 ESXi - bricht schon nach 5-10 Minuten ab, weil die VolumeShadows keinen Status zurück geben - der Schwellenwert für das Timeout lässt sich nicht heben.
2. Backup & Restore mittels Veeam Endpoint Backup - gleiches Problem das Snapshot kann nicht erstellt werden, der Reg-Key, den man für Veeam Backup & Replication setzen kann, greift beim Endpoint Agent nicht.
3. Backup & Restore mttels Windows Backup - scheitert ebenfalls wegen VSS.
4. Acronis startet weder mit der Windows- als auch mit der Linux-Version, weil die Festplatten-Treiber für den RAID-Controller fehlen und kein Storage geladen werden kann.
5. Easus Backupper Server - habe ich extra gekauft - bricht auch nach ca. 10-15 Minuten Klonen ab.
6. Meine letzte Option ist jetzt noch, dass ich mit dem Veeam Endpoint Backup doch noch irgendwann eine Sicherung auf USB schaffe und dann mittels Recovery-Media starten kann und auf die SSDs wiederherstellen kann.
Folgendes noch zu den Diensten und dem VSS.
Nach einem Neustart starten nicht alle Dienste (z.B. Essentials, MSSQL Express).
In den VSS Writers - habe ich erst ein einziges Mal durch Dienste-Neustart geschafft, dass alle Writer ohne Fehlerzustand stabil sind. Meistens ist der NTDS, der letzte Writer der nicht will.
Vor jedem Backup habe ich die Writer-Stände kontrolliert.
Vor jedem Backup habe ich Dienste beendet (z.B. Windows Update etc.)
Das ist alles echt mühsam und ich kann deinen Beitrag verstehen, selbst ein Neustart dauert mind. 45-60 Minuten, weil die Platten einfach falsch eingesetzt wurden.
Das System hat keinen Viren, nützt nur noch den Defender und arbeitet ständig am Limit - mit den SSDs würde es locker für 5 User und PCs mit AD und MSSQL Express reichen - aber ohne Backup komme ich nicht durch.
Mit Knoppix habe ich es heute noch nicht getestet, habe leider kein Medium zum Testen mit - ich denke aber, dass ich auch dort wieder Probleme mit dem Treiber haben werde.
Habt ihr noch eine Idee, wie ich das System auf die SSD bringen kann.
Ich habe das System erst vor Kurzem übernommen, kenne noch nicht alle Software-Pakete und möchte ehrlich gesagt einen Neuaufbau vermeiden.
Wenn also noch irgendjemanden eine Idee dazu bzw. der Verfasser seine Erfahrung aus einem etwaigen Erfolg teilen könnte - wäre ich sehr dankbar - momentan bin ich nach mehr als 8 Stunden echt ratlos und habe alles versucht, was bisher bei harten Nüssen auch noch immer zum Erfolg geführt hat.
Danke
LG
Lukas
ich wollte fragen, ob du dein Problem irgendwie lösen konntest?
Ich bin leider mit der gleichen Hardware unter ähnlichen Umständen ebenfalls am Verweifeln.
Der Vor-Vorgänger hat das System angeschafft und aufgebaut.
Im Server sind alle 4 Plätze mit SATA HDDs belegt.
2x Desktop HDDs
2x Server HDDs
Die Desktop HDDs wurden für das Windows verwendet, die Server HDDs für das Windows Backup.
Beide sind im RAID1.
Bei der Installation hat man schon also einen Fehler gemacht und das falsche Array ausgewählt.
Die Performance der Maschine ist aufgrund der Festplatten grottenschlecht, ich habe zuerst den RAM aufgerüstet und wollte nun 2x SSDs im RAID einsetzen.
Bisher ist alles aufgrund der performancebedingten Probleme mit dem VSS gescheitert.
1. P2V Conversion mti dem vCenter Converter auf eine HP ML350 ESXi - bricht schon nach 5-10 Minuten ab, weil die VolumeShadows keinen Status zurück geben - der Schwellenwert für das Timeout lässt sich nicht heben.
2. Backup & Restore mittels Veeam Endpoint Backup - gleiches Problem das Snapshot kann nicht erstellt werden, der Reg-Key, den man für Veeam Backup & Replication setzen kann, greift beim Endpoint Agent nicht.
3. Backup & Restore mttels Windows Backup - scheitert ebenfalls wegen VSS.
4. Acronis startet weder mit der Windows- als auch mit der Linux-Version, weil die Festplatten-Treiber für den RAID-Controller fehlen und kein Storage geladen werden kann.
5. Easus Backupper Server - habe ich extra gekauft - bricht auch nach ca. 10-15 Minuten Klonen ab.
6. Meine letzte Option ist jetzt noch, dass ich mit dem Veeam Endpoint Backup doch noch irgendwann eine Sicherung auf USB schaffe und dann mittels Recovery-Media starten kann und auf die SSDs wiederherstellen kann.
Folgendes noch zu den Diensten und dem VSS.
Nach einem Neustart starten nicht alle Dienste (z.B. Essentials, MSSQL Express).
In den VSS Writers - habe ich erst ein einziges Mal durch Dienste-Neustart geschafft, dass alle Writer ohne Fehlerzustand stabil sind. Meistens ist der NTDS, der letzte Writer der nicht will.
Vor jedem Backup habe ich die Writer-Stände kontrolliert.
Vor jedem Backup habe ich Dienste beendet (z.B. Windows Update etc.)
Einmal sogar alles, bis aus systemrelevanten, also auch AD usw.
Das ist alles echt mühsam und ich kann deinen Beitrag verstehen, selbst ein Neustart dauert mind. 45-60 Minuten, weil die Platten einfach falsch eingesetzt wurden.
Das System hat keinen Viren, nützt nur noch den Defender und arbeitet ständig am Limit - mit den SSDs würde es locker für 5 User und PCs mit AD und MSSQL Express reichen - aber ohne Backup komme ich nicht durch.
Mit Knoppix habe ich es heute noch nicht getestet, habe leider kein Medium zum Testen mit - ich denke aber, dass ich auch dort wieder Probleme mit dem Treiber haben werde.
Habt ihr noch eine Idee, wie ich das System auf die SSD bringen kann.
Ich habe das System erst vor Kurzem übernommen, kenne noch nicht alle Software-Pakete und möchte ehrlich gesagt einen Neuaufbau vermeiden.
Wenn also noch irgendjemanden eine Idee dazu bzw. der Verfasser seine Erfahrung aus einem etwaigen Erfolg teilen könnte - wäre ich sehr dankbar - momentan bin ich nach mehr als 8 Stunden echt ratlos und habe alles versucht, was bisher bei harten Nüssen auch noch immer zum Erfolg geführt hat.
Danke
LG
Lukas
Snapshots habe ich auch schon deaktiviert, gelöscht - es liest sich dein Beitrag also 1:1 zu meinem und die Gemeinsamkeit ist dieser Fujitsu Server.
Mir ist jetzt noch eine Möglichkeit eingefallen - wäre es theoretisch möglich ein virtuelles RAID 1 0 mittels Windows Software RAID zu bauen und das HDD-Array auf das SSD-Array zu spiegeln?
Man sollte ja dann, wenn ich das HDD-Array deaktiviere vom SSD-Array booten können (2nd Plex oder so heißt die Option) und dann die Spiegelung wieder entfernen können?
Wäre das eine Option?
Bei dir ist noch mehr optimierungsbedürftig (milde ausgedrückt), mach mal einen eigenen Topic auf.
@LKaderavek
Ja wir sind weiter gekommen, aktuell läuft das ganze wieder recht stabil.
Diese Woche werde ich allerdings nicht mehr dazu kommen das ganze zusammen zu fassen.
Ich habe deine Post jetzt nur kurz überflogen, muss aber @NordicMike zustimmen, da ist noch deutlich mehr "optimierungsbedürftig"...
Was mir direkt aufgefallen ist:
- 2x Desktop HDDs
- Die Performance der Maschine ist aufgrund der Festplatten grottenschlecht:
Das ist für das Backup immer schlecht, dadurch wird die Chance auf einen VSS Writer timeout bzw. lockup deutlich erhöht.
Ich werde nächste Woche eine Zusammenfassung unseres Vorgehens welcher wir in zusammenarbeite mit Microsoft erarbeitet bzw. ausgeführt haben zusammenschreiben und posten.
Ja wir sind weiter gekommen, aktuell läuft das ganze wieder recht stabil.
Diese Woche werde ich allerdings nicht mehr dazu kommen das ganze zusammen zu fassen.
Ich habe deine Post jetzt nur kurz überflogen, muss aber @NordicMike zustimmen, da ist noch deutlich mehr "optimierungsbedürftig"...
Was mir direkt aufgefallen ist:
- 2x Desktop HDDs
- Die Performance der Maschine ist aufgrund der Festplatten grottenschlecht:
Das ist für das Backup immer schlecht, dadurch wird die Chance auf einen VSS Writer timeout bzw. lockup deutlich erhöht.
Ich werde nächste Woche eine Zusammenfassung unseres Vorgehens welcher wir in zusammenarbeite mit Microsoft erarbeitet bzw. ausgeführt haben zusammenschreiben und posten.
Hallo,
ich habe das Problem abschließend nun doch lokalisiert und muss echt sagen, manche Leute haben keine Ahnung.
Wie beschrieben wurden die langsamen SATA Desktop HDDs für das OS verwendet, weiter dann die SAS Server HDDs für das Backup - sei wie es ist.
Aber: Das Hauptproblem waren ja die VSS Komponenten und die Performance.
Die Lösung war dann einfach: Im ServerView RAID Manager (localhost:3417) über IE kann man für die Arrays das Cache-Modul aktivieren, das geht im Betrieb und sogar der erste Neustart dauert dann nur noch 10 Minuten, die übrigen jetzt 5 Minuten.
Nachdem durch die VSS nun auch endlich der vSphere Transfer geklappt hat, bekommt der Server jetzt eine ESXi mit SSD-Storage und alles ist Gut.
Also: Cache checken, sollte jemand noch auf diesen Server stoßen und damit die gleichen Probleme feststellen.
LG
Lukas
ich habe das Problem abschließend nun doch lokalisiert und muss echt sagen, manche Leute haben keine Ahnung.
Wie beschrieben wurden die langsamen SATA Desktop HDDs für das OS verwendet, weiter dann die SAS Server HDDs für das Backup - sei wie es ist.
Aber: Das Hauptproblem waren ja die VSS Komponenten und die Performance.
Die Lösung war dann einfach: Im ServerView RAID Manager (localhost:3417) über IE kann man für die Arrays das Cache-Modul aktivieren, das geht im Betrieb und sogar der erste Neustart dauert dann nur noch 10 Minuten, die übrigen jetzt 5 Minuten.
Nachdem durch die VSS nun auch endlich der vSphere Transfer geklappt hat, bekommt der Server jetzt eine ESXi mit SSD-Storage und alles ist Gut.
Also: Cache checken, sollte jemand noch auf diesen Server stoßen und damit die gleichen Probleme feststellen.
LG
Lukas
