Chkdsk auf DC (SBS 2008)

[Ste83 10]

Hallo,

 

mein SBS 2008 (der im Rahmen der einer Auflösung steht - die aber aufgrund anderer Probleme etwas dauern kann) zeigt seit dem letzten Neustart im Ereignisprotokoll an, das die das Dateisystem auf Laufwerk C beschädigt und unbrauchbar ist (manchmal auch das auf \device\harddiskvolume1)

 

Es funktioniert soweit ich sehen kann alles. Der Server ist virtualisiert und andere Maschinen haben keine weiteren Probleme. Denke also es ist kein Hardwarefehler und das NTFS einfach irgendwo was abbekommen hat.

 

Wenn ich chkdsk ausführe findet er verwaiste Datensatzsegmente usw. ich soll es mit dem Parameter /F versuchen.

mach ich das sagt er erst beim nächsten Neustart. Mach ich das führt er chkdsk leider nicht aus, es kommt manchmal kurz ein Hinweis, dass er keinen Zugriff bekommt. Im Abgesicherten Modus ist ebenso.

 

Wie schaff ich es das Dateisystem zu reparieren? Mit einem Start von einer Windows CD? Ist das supportet bei DCs? Kann es irgendeine sein, oder sollte es eine Win2008 Server CD sein?

 

Danke.

[blub 115]

Denke also es ist kein Hardwarefehler und das NTFS einfach irgendwo was abbekommen hat.

Dass NTFS "einfach mal was abbekommt", ist heutzutage schon sehr, sehr selten.

Chkdsk ist ein Tool aus den Tagen, als jeder Rechner seine eigene, physikalische Festplatte ohne RAID hatte.

Kann man beim SBS einen zweiten,zusätzlichen DC  installieren und nach der Replikation den ersten DC entfernen? Ansonsten recovery.  Den jetzigen Zustand mit den Fehlermeldungen am DC akzeptieren würde ich auch nicht.

[Dunkelmann 96]

Moin,

 

mit NTFS Fehlern ist i.d.R. nicht zu Spaßen.

 

In einer virtuellen Umgebung muss der Fehler nicht zwangsläufig in der VM liegen, es kann auch ein Problem des Hypervisors oder des Storage sein. Dass andere VMs augenscheinlich nicht betroffen sind, hat wenig bis keine Aussagekraft.

 

Gibt es ein wiederherstellbares Backup?

Hast Du schon Storage und Hypervisor geprüft?

Eventuell sollte die Störung als "Migrationsbeschleuniger" betrachtet werden.

 

@bulb:

Ein SBS ist der Chef im Ring bzw. im AD. Einen zweiten DC zu installieren ist kein Problem. Einen SBS herunterzustufen schon; außer im Rahmen einer kontrollierten Migration.

[Ste83 10]

Es gibt schon weitere DCs. Auch der Exchange, WSUS und Sharepoint sind umgezogen. Der Grund warum es nicht weitergeht, ist das alte und wichtige Maschinen noch auf Ihn verweisen (für Programme abholen). Das wurde damals häufig sogar unter der IP Adresse eingerichtet. Und um das umzustellen, braucht es die Maschinenhersteller und auch ne entsprechende Downtime. Aber da muss ich nun wohl mehr dran bleiben.

 

Backup gibt es schon (Veeam). Aber leider habe ich den Fehler zu spät bemerkt. Entweder schon älter oder eben mit Fehler.

Weis auch nicht ob ich mir damit nicht mehr ärger einhandel.

Lieber wäre mir die Migration zu beschleunigen oder den Fehler zu fixen.

 

Mit Client PCs habe ich bei chkdsk bisher gute Erfahrungen gemacht. Natürlich ging es da auch immer ohne Bootdisk.

 

Warum würdet ihr es bei einem Server / DC nicht machen?

[Weingeist 157]

Hatte das schon öfter auf nem SBS 2008. Ursachen gibts da einige. Die häufigste die ich sah waren Fehler mit den Journaling. Dazu müsste es aber eigentlich auch Logs geben. Wenn dem so ist, ist das mitunter ziemlich lästig weil man es nicht so richtig reparieren kann auf einem DC und zwar weil die Replikation davon abhängt. Sprich löscht man den Kram und lässt ihn neu erstellen, hast Du mächtig Ärger mit den anderen DC's.

 

Mögliche Ursachen:

- Harte Shutdowns z.B. durch Stromausfälle

- Manipulation von Last-Access Bit der Files

- Bei VM's aber auch Time-Out von Festplatten-Writes (sollte erhöht werden bei 2008 auf ca. 200 --> Registry)

 

Insofern kann man eigentlich nur sagen, dass man solche DC's möglichst aus dem Dienst stellen sollte. Vorher unbedingt alle GPO's sichern! Möglich, dass die auf den anderen DC's nicht (sauber) repliziert wurden, vom Client aber immer vom SBS gezogen wurde.

 

Mein Vorgehen wäre SBS DC Herunterstufen, SBS-Relevante Tasks und Dienste abdrehen und nach und nach alles deinstallieren was migriert wurde.

Da Exchange anwesend ist, wäre es sinnvoll diesen vorher herunterzufahren damit der AD-Stand exakt der selbe ist vor und nach den Mutationen und allfälligen Recovery des SBS als DC.

Ich persönlich fahre jeweils alle DC's herunter und ziehe nen Cold-Clone des SBS sowie der DC's die sonst noch rumschwirren + Exchange, dann kann ich zurück zum Start ohne Risiko eines AD-Rollbacks.

Oder falls nicht möglich, alle zweit DC's vor den Manipulationen herunterstufen, dann nen Cold-Clone vom SBS damit man zum sauberen AD-Stand zurück kommt und keine anderen DC's rumschwirren können bei nem Recovery. In deinem Fall wo der SBS nen Knacks hat, würde ich aber eher ersten Weg wählen.

 

 

Zum Schluss soll noch gesagt sein: Um das sinnvollste Vorgehen einigermassen exakt zu bestimmen, müssen wirklich alle Fakten auf den Tisch. Also was wollen die Maschinen vom SBS haben, sind das nur Freigaben oder auch sonstigen Kram. Können die installer-Pakete auch sonst realisiert werden usw.

 

Warum nicht Chkdsk: Weil das eigentlich nie repariert sondern höchstens verschlimmbessert. Wenn dann nur prüfen ohne jegliche Reparatutur, dann sind auch Erfolge mit Recovery Tools wahrscheinlicher.