datmox 26 Geschrieben 17. März 2014 Melden Geschrieben 17. März 2014 Guten Morgen, ich hab soeben die Ereignislogs von meinen Servern überprüft. Beim Windows Server 2012 Standard (gehostet auf ESXi 5.1.0, Dell R720xd) fielen mir mehrere NTFS Fehler auf Volumes auf, welche es auf dem Server garnicht gibt...! Volume "G:" (\Device\HarddiskVolume128) muss offline geschaltet werden, um eine vollständige chkdsk-Prüfung auszuführen. Führen Sie "CHKDSK /F" lokal über die Befehlszeile oder "REPAIR-VOLUME <Laufwerk:>" lokal oder remote über PowerShell aus. danach kommt: In der Dateisystemstruktur auf Volume "G:" wurde eine Beschädigung erkannt.Die genaue Art der Beschädigung ist unbekannt. Die Dateisystemstrukturen müssen offline überprüft und repariert werden. Wie gesagt gibt es auf diesem Server nur eine C: Partition... Es sind auch keine Netzlaufwerke verbunden! Gestern taucht folgender Fehler auf: In der Dateisystemstruktur auf Volume "F:" wurde eine Beschädigung erkannt.In einer Indexstruktur des Dateisystems wurde eine Beschädigung gefunden. Die Dateireferenznummer ist 0x40000000004c4. Der Name der Datei ist "\$Extend\$RmMetadata\$TxfLog". Das Attribut des beschädigten Indexes ist ":$I30:$INDEX_ALLOCATION". Was läuft hier schief? Im Vsphere Client seh ich keinerlei Fehler für den kompletten ESXi Host. Der 2012er dient nur als secondary DC und Spiceworks Server... Zitieren
datmox 26 Geschrieben 24. März 2014 Autor Melden Geschrieben 24. März 2014 Hat keiner ne Idee? Hab gerade einen chkdsk auf Volume C: ausgeführt. Wie vermutet, keine Fehler...! Zitieren
zahni 566 Geschrieben 24. März 2014 Melden Geschrieben 24. März 2014 Was sagt Dir diskpart -> list volume Zitieren
h-d.neuenfeldt 21 Geschrieben 27. März 2014 Melden Geschrieben 27. März 2014 Guck mal in der Registry nach dem Schlüssel MountPoints bzw MountPoints2 ob da noch ein Laufwerk G eingetragen ist, vielleicht hat sich ja eine mal angeschlossene USB-Platte nicht richtig "verabschiedet" Zitieren
datmox 26 Geschrieben 27. März 2014 Autor Melden Geschrieben 27. März 2014 Mhmmm... da sind in der Tat ein paar Mountpoints drin...! Problemserver: Funktionierender Server: Zitieren
h-d.neuenfeldt 21 Geschrieben 27. März 2014 Melden Geschrieben 27. März 2014 bei einer fehlerhaften USB-Abmeldung würde da aber definitv der Laufwerksbuchstabe stehen ... Zitieren
zahni 566 Geschrieben 27. März 2014 Melden Geschrieben 27. März 2014 Reines Raten, Du kannst aber mal gefahrlos prüfen: Sind im ESXi alle Updates installiert ? Das geht bei der kostenlosen Version leider nur per Remote CLI Dann die VMWare-Tools in der VM updaten. Sämtlich Snapshots "löschen" Eine VM sollte keine dauerhaften Snapshots besitzen, schon gar keine kaskadierten Zitieren
datmox 26 Geschrieben 2. April 2014 Autor Melden Geschrieben 2. April 2014 (bearbeitet) Snapshots waren wie gesagt keine vorhanden. ESXi dank VCenter soweit Up2date. Ich hab jetzt einfach mal eine Sicherung erstellt und den kompletten "Mountpoints2" Schlüssel gelöscht und neugestartet. Bis jetzt läuft alles so wie es soll! bearbeitet 2. April 2014 von datmox Zitieren
datmox 26 Geschrieben 3. April 2014 Autor Melden Geschrieben 3. April 2014 (bearbeitet) Ich hab gerade erfahren, dass der betroffene Server auch als Backupproxy für Veeam genutzt wird. Die Mountpoints sind übrigens wieder da... Die Fehler entstehen dann wohl in Verbindung mit Veeam (gleiche Symptome auf unserem Veeam Server (fungiert auch als Veeam Proxy), ich denke, dass ich am besten mal den Veeam Support kontaktieren werde...!? Danke! bearbeitet 3. April 2014 von datmox Zitieren
zahni 566 Geschrieben 3. April 2014 Melden Geschrieben 3. April 2014 Ich kenne Veeam zwar nicht, aber ich könnte mir vorstellen, dass Veeam die VMDK während der Sicherung mounted. Gibt mal (wirklich nur in Blaue geraten) in einer Admin-CMD ein: "diskpart automount disable" . Dann verteilt Windows nicht automatisch Laufwerksbuchstaben... Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.