VMware-Forum

Hallo zusammen,

ich habe am Freitagabend die Datenpartition vom virtuellen File-Server von 1,8 auf 2,1 TB im ausgeschalteten Zustand vergrößert. Die Anpassung in der Datenträgerverwaltung hat ebenfalls wie gewohnt ohne Probleme funktioniert. Bis jetzt wurden in 2 von etwa 15 Replikations- oder Backupjobs in Veeam folgende Fehler gemeldet: Unfreeze error: [Backup job failed. Cannot create a shadow copy of the volumes containing writer's data. VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x80042306].]. Der neue Versuch sowie alle restlichen Jobs wurden erfolgreich durchgeführt.

Daraufhin habe ich die Ereignisanzeige am File-Server untersucht und es wurden bei 8 von 15 Veeam-Jobs Ntfs ID 55 Fehler geloggt und zwar auf Volume "??", Volume "System-reserviert" sowie Volume "System". Die vergrößerte Datenpartition sowie die dazugehörige Shadowcopy-Partition melden keine Fehler. Hier werden windowsintern unabhängig von den Veeam-Jobs Schattenkopien der Datenpartition erstellt.

Hier sind einige Beispiele der Fehlermeldungen:

In der Dateisystemstruktur auf Volume "??" wurde eine Beschädigung erkannt.
Die Masterdateitabelle (MFT) beinhaltet einen beschädigten Dateidatensatz. Die Dateireferenznummer ist 0x1000000000001. Der Name der Datei ist "<Dateiname kann nicht bestimmt werden>".

In der Dateisystemstruktur auf Volume "??" wurde eine Beschädigung erkannt.
Die genaue Art der Beschädigung ist unbekannt. Die Dateisystemstrukturen müssen online überprüft werden.

In der Dateisystemstruktur auf Volume "System-reserviert" wurde eine Beschädigung erkannt.
In einer Indexstruktur des Dateisystems wurde eine Beschädigung gefunden. Die Dateireferenznummer ist 0x5000000000005. Der Name der Datei ist "<Dateiname kann nicht bestimmt werden>". Das Attribut des beschädigten Indexes ist ":$I30:$INDEX_ALLOCATION".

In der Dateisystemstruktur auf Volume "System" wurde eine Beschädigung erkannt.
In einer Indexstruktur des Dateisystems wurde eine Beschädigung gefunden. Die Dateireferenznummer ist 0x5000000000005. Der Name der Datei ist "<Dateiname kann nicht bestimmt werden>". Das Attribut des beschädigten Indexes ist ":$I30:$INDEX_ALLOCATION".

Und nur gestern früh beim allerersten Replikationsjob nachdem davor die Partitionen ohne CBT die ganze Nacht neu repliziert wurden. Seitdem gab es keine weiteren Fehlermeldungen mehr mit Dateipfaden:

In der Dateisystemstruktur auf Volume "System" wurde eine Beschädigung erkannt.
In einer Indexstruktur des Dateisystems wurde eine Beschädigung gefunden. Die Dateireferenznummer ist 0x100000000011f. Der Name der Datei ist "\Users\Default\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch". Das Attribut des beschädigten Indexes ist ":$I30:$INDEX_ALLOCATION".

In der Dateisystemstruktur auf Volume "System" wurde eine Beschädigung erkannt.
In einer Indexstruktur des Dateisystems wurde eine Beschädigung gefunden. Die Dateireferenznummer ist 0x2000000006166. Der Name der Datei ist "\Users\Administrator.XXXX\AppData\Local\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\LocalState\Indexed\Settings\de-DE". Das Attribut des beschädigten Indexes ist ":$I30:$INDEX_ALLOCATION".

In der Dateisystemstruktur auf Volume "System" wurde eine Beschädigung erkannt.
In einer Indexstruktur des Dateisystems wurde eine Beschädigung gefunden. Die Dateireferenznummer ist 0x100000000218dd. Der Name der Datei ist "\ProgramData\Symantec\Symantec Endpoint Protection\14.0.3876.1100.105\Data\SRTSP". Das Attribut des beschädigten Indexes ist ":$I30:$INDEX_ALLOCATION".

Ich habe gestern Abend dann noch zusätzlich wie unter https://kb.vmware.com/s/article/59216 beschrieben, “IO coalescing” auf dem Host deaktiviert, alle VMs heruntergefahren und neu gestartet. Wobei diese Einstellung eigentlich nur für die Datenpartition (>2TB) relevant sein sollte.

Wie soll ich hier am besten vorgehen? Und sind die Fehler besorgniserregend? "vssadmin list writers" meldet keinen Fehler, aber der Veeam VSS-Writer wird ja auch nach jedem Job wieder deinstalliert. "fsutil dirty query" sowie chkdsk ohne weitere Optionen haben bei der System- und Datenpartition keine Probleme entdeckt. Die Partition System-reserviert habe ich nicht überprüft.

Ich habe hier ESXi 5.5 3116895, Veeam B&R 9.5 Update 3 mit application-aware processing im Einsatz und der File-Server läuft unter Windows Server 2012 R2.

Danke im Voraus für eure Hilfe.

BG,
Lionel

Das sind (leichte) MFT-Fehler, die Windows mit einem "chkdsk /f x:" sehr wahrscheinlich selbst beheben kann.

Meinst du "chkdsk /f /x"? Muss ich der System-reservierten Partition temporär einen Buchstaben vergeben? Und kann es sein, dass durch die Behebung dieser MFT-Fehler die Dateien unbrauchbar sind oder das System nicht mehr bootfähig ist?

Nachtrag - ich könnte die Prozedur auf dem Replikationsserver ohne Netzwerkverbindung testen, falls es auf die Produktiv-VM übertragbar ist.

Nö - "x" steht für den Laufwerksbuchstaben.

Stimmt, du hattest ja auch "System-reserviert" erwähnt - diese Partition musste ich noch nie überprüfen/reparieren lassen. Du kannst versuchen, temporär einen Laufwerksbuchstaben zu vergeben.

Nach meinen Erfahrungen werden durch die Reparaturen die Dateien unter Umständen gelöscht (sie sind aber auch vor der Reparatur schon nicht mehr zu gebrauchen) oder in ein Verzeichnis "filechk.000" (oder so ähnlich) verschoben. Meist sind sie aber einfach vorhanden und enthalten keine korrekten Daten (wie vor der Reparatur auch schon).

Vollständig auszuschließen ist ein unbrauchbares System nach einer Reparatur nie - nach meinen Erfahrungen ist es aber eher umgekehrt (Bluescreen "Corrupt NTFS file system" -> chkdsk -> bootet wieder).

Ich erstelle vorsichtshalber manuelle Cold-Clones der Volumes vor der Reparatur.

Es MUSS nichts bedeuten, kann aber doch fuer Problemchen sorgen:
Eine Vergroesserung von 1,8 auf 2,1 TB (oder vielleicht doch TiB?) "der Datenpartition" kann eine Wandlung von MBR auf GPT notwendig machen...
Wer dann was vielleicht auch automatisch macht, ist bei der bisherigen aeusserst rudimentaeren Beschreibung dessen was verwendet und durchgefuehrt wurde (statt der diversen Meldungsbeispiele) auch nicht gerade leicht zu mutmassen.

Die Datenpartition ist bereits automatisch auf GPT. Der Datenträger mit den beiden Partitionen System-reserviert und System ist weiterhin auf MBR.

Ich habe eben "chkdsk /f" auf der System-reserviert-Partition durchgeführt - keine Fehler. Bei der System-Partition sieht es wie folgt aus:

...
Phase 1: Die Basisdatei-Systemstruktur wird untersucht...
201984 Datensätze verarbeitet. Dateiüberprüfung beendet.
9410 große Datensätze verarbeitet. 0 ungültige Datensätze verarbeitet.
Phase 2: Die Dateinamenverknüpfung wird untersucht...
285890 Indexeinträge verarbeitet. Indexüberprüfung beendet.
0 nicht indizierte Dateien überprüft. 0 nicht indizierte Dateien wiederhergestellt.
Phase 3: Sicherheitsbeschreibungen werden untersucht...
242 nicht verwendete Indexeinträge aus Index $SII der Datei 0x9 werden aufgeräumt.
242 nicht verwendete Indexeinträge aus Index $SDH der Datei 0x9 werden aufgeräumt.
242 nicht verwendete Sicherheitsbeschreibungen werden aufgeräumt.
Überprüfung der Sicherheitsbeschreibungen beendet.
41954 Datendateien verarbeitet. CHKDSK überprüft USN-Journal...
35063352 USN-Bytes verarbeitet. Die Überprüfung von USN-Journal ist abgeschlossen.
CHKDSK hat freien Speicher gefunden, der in der Volumebitmap als
zugeordnet gekennzeichnet ist.

Es wurden Korrekturen am Dateisystem vorgenommen.
Es sind keine weiteren Aktionen erforderlich.

41582591 KB Speicherplatz auf dem Datenträger insgesamt
12907980 KB in 128512 Dateien
122544 KB in 41955 Indizes
0 KB in fehlerhaften Sektoren
294791 KB vom System benutzt
55568 KB von der Protokolldatei belegt
28257276 KB auf dem Datenträger verfügbar

4096 Bytes in jeder Zuordnungseinheit
10395647 Zuordnungseinheiten auf dem Datenträger insgesamt
7064319 Zuordnungseinheiten auf dem Datenträger verfügbar
...

Der erste Replikationsjob lief fehlerfrei durch. Mal sehen, wie's weitergeht.

Danke nochmal für euren Input.

Schönen Restsonntag,
Lionel

https://kb.vmware.com/kb/2006849

Ich gehe mal davon aus das die "Fehler" Meldungen schon vorher da waren oder? Lass dir mal im Eventlog nur Fehler und Warnungen anzeigen und pruefe ob die schon vor deiner Vergroesserung da waren.

Gruss
Joerg

Nachdem ich mir alles noch ein paar Male durchgelesen habe, meine ich erkannt zu haben, dass die vergroesserte "Datenpartition" ueberhaupt nix mit den Fehlermeldungen zu tun hat
Sowohl die "system-reserved" als auch die "system" liegen ja auf einem anderen Datentraeger; mithin einer anderen vmdk...
Es koennte hoechstens noch die "??" Partition gemeint sein, aber auch da liegen wir wieder im Bereich der Vermutungen. Genauso gut koennte Windows auch irgendwas anderes damit meinen.

Ich glaube auch das es da keinen Zusammenhang gibt.

Gruss
Joerg

Nein, die Fehler (Ntfs 55 und VSS 12289) sowie Warnungen (Ntfs 50) treten tatsächlich erst seit der Vergrößerung der Partition auf.

Der "VSS 12289" Fehler hat folgende Details:


Zu dem Fehlercode 0x80070013 habe ich leider nichts brauchbares gefunden.

Der Veeam-Job versucht es bei Fehlern jeweils nochmal und da hat es interessanterweise bis jetzt immer geklappt.

Ich konnte eben zwischen dem Fehl- sowie dem Zweitversuch "vssadmin list writers" eingeben und folgende Writer zeigten Zeitüberschreitung an:

Verwendet dein Veeam das Quiescing von VMware oder hast du das Veeam eigene im Einsatz? Letzeres ist unter "Appliacation Guest processing" zufinden.

Gruss
Joerg

Ist beides standardmäßig im Veeam-Job aktiviert und in diesem Fall sticht immer application-aware processing. Und VSS success required ist für diese VM ebenfalls ausgewählt.

Die Fehler sind leider wieder da.

Der Veeam-Job hat bei 8 Durchläufen 4x einen zweiten Anlauf benötigt, um den File-Server zu sichern. Die "Ntfs 55" Fehler sind auch 4x aufgetreten, jedoch nicht immer deckungsgleich mit dem ersten Fehler. Im Replikationsjob betrifft es Volume "??" und im Backupjob Volume "System-reserviert". Ich nehme an, es geht hier um die gleiche Partition?

Ich werde erstmal ein Ticket bei Veeam erstellen. Mal sehen, was sie dazu meinen.

Hat jemand noch eine Idee?

Ausgehend von https://www.ugg.li/vsphere-erzeugt-beim-snapshots-erstellen-ntfs-fehler-auf-windows-servern-event-5057137/ ist der Fehler bekannt. Die Lösung besteht darin das Quiescing in den Tools abzuschalten, bis M$ das Problem wirklich löst.

Danke, den Beitrag habe ich gestern bereits gelesen. Ist es wirklich ratsam auf applikationskonsistente Snapshots zu verzichten? Und können bei der Snapshoterstellung tatsächlich Daten kaputt gehen?

Ausgehend vom Link betrifft es anscheinend nur die SRP, aber willst du bei jedem Backup diese Fehlermeldungen kassieren und nach einer Replikation von einem BSOD gefolgt von einem entsprechend langen FDISK-Lauf empfangen werden?
Wenn du das Backup wirklich mal brauchst, hast du bestimmt andere Dinge im Kopf, als dich erst noch damit zu beschäftigen.

Ich habe heute das Quiescing abgeschaltet. Wie berichtet, werden keine Ntfs oder VSS Fehler/Warnungen mehr geloggt.

Es gibt jedoch ein weiteres Problem, das seit der Partitionsvergrößerung auftritt. Hier sind auch die UPDs für den Terminal Server gespeichert. Wenn sich ein Benutzer am Terminal Server während des Schattenkopiezeitraums (Replikation/Backup) am Terminal Server ausloggt, ist die VHDX-Datei anschließend defekt und am TS werden für diese eingehängte User-Festplatte Ntfs-Fehlermeldungen geschrieben. Das ist auch bereits vor der heutigen Quiescing-Abschaltung und nach der Deaktivierung von SEspare IO coalescing am Samstag Abend aufgetreten.

Den M$-Server hattest du aber mal durchgebootet nach der Partitionsänderung?
Was sagt Veeam zu dem Problem?